The following documentation provides a high-level overview to help you prepare and publish your Android and iOS applications that integrate the Situm SDK. Its goal is to simplify some of the most common steps and highlight key areas to consider when getting your app ready for publication.
This guide is intended as a practical companion to the official Android and iOS publishing documentation. It does not aim to be exhaustive, nor to replace the platform guidelines, but rather to offer helpful context and recommendations based on typical use cases with the Situm SDK.
For detailed and up-to-date requirements, we always recommend consulting the official documentation provided by Google and Apple:
- Android: https://developer.android.com/studio/publish
- iOS: https://developer.apple.com/app-store/submitting/
Who should publish the app? #
When an app provides indoor navigation or similar services inside a building, the question is often:
who should publish the app — the developer or the venue? The answer is not technical. App stores decide this based on who the user believes is providing the service.
Apple App Store #
Apple structures the App Store around who provides the service to the user, not around who built the software. Sections 5.2.1 and 4.2.6 of the App Store Review Guidelines are relevant.
In practical terms:
- The publisher account should correspond to the organization that holds the Intellectual Property (names, logos, etc.) or to the organization the user believes they are interacting with. If an app represents a specific business or venue, Apple generally expects that business to be the publisher. A software provider cannot normally publish many separate client-specific apps from its own account.
- In some cases, Apple does allow a different approach: the provider may publish a single application that acts as a platform containing multiple customers or locations within it (for example, one app where users choose among different venues).
Google Play Store #
Google’s main concern is preventing impersonation. An app must not lead users to believe it is published or operated by another organization, nor use another organization’s identifying elements (such as names, logos, or venue information).
However, Google allows developers to proactively inform when publishing on behalf of a third party and provide supporting documentation. This means a developer may publish an app related to a specific venue if permission exists and the relationship is transparent.
However, even when technically allowed, the recommended approach remains the same as on Apple: each organization should publish its own apps whenever the app primarily represents that organization.
Alternative marketplaces and private distribution #
In alternative app stores (including iOS alternative marketplaces in the EU, direct web distribution, enterprise stores, and most third-party Android stores), the rules focus primarily on legal responsibility rather than marketplace identity.
Instead of requiring the publisher to match the organization the app represents, these channels generally allow a developer to distribute apps on behalf of multiple organizations, provided that:
- the developer has written authorization from the organization,
- the app does not falsely claim to be published by the organization,
- trademarks and content are used with permission,
- the operator of the service is clearly identifiable to users.
Typical publishing models #
- Official venue app. If the app is presented as the official mobile app of a specific venue (using its name, logo, and identity) or could reasonably be perceived as belonging to that venue (for example because it focuses on a single location, prominently features its identity, or exists solely for that organization), the safest approach in public app stores is for the venue to publish it in its own store accounts, while the developer manages development and updates as a collaborator. In alternative marketplaces or private distribution channels, the developer may be allowed to distribute the app on the venue’s behalf provided explicit written authorization exists and the relationship is transparent.
- Developer platform app (multi-venue). If the app is presented as a product or platform operated by the developer and usable across unrelated buildings, the developer can publish it directly. This model is generally acceptable both in public stores and alternative distribution channels (similar to a booking or delivery platform that serves multiple independent businesses within one application).
- Single-venue developer-operated app. An app operated by the developer but configured for a single venue may be accepted in public stores only when clearly presented as the developer’s own service rather than the venue’s app, but it carries higher rejection risk (especially on Apple) and typically requires written authorization from the venue. In alternative marketplaces and private distribution, this model is usually permitted as long as authorization and non-impersonation requirements are satisfied.
Required Documentation #
Having clarified this point, before reviewing the details of the app upload process to Google Play and the Apple App Store, there are aspects of the documentation that need to be reviewed to complete the process.
As we will see in the following paragraphs, some sections of this documentation are common to both Google Play and the Apple App Store. These sections will be discussed below, and then we will examine the specific documentation for each platform, as well as screenshots of the publishing process for each.
Privacy Policy #
Both Google Play and Apple App Store require apps to provide a Privacy Policy. The following information about Situm can be referenced when integrating the Situm SDK. This is for guidance only and does not constitute legal advice; developers must perform their own due diligence.
If you are new to app stores, don’t worry—these concepts will become clearer as you proceed, and the references below can be used directly when preparing your app submission:
- Privacy Policy: https://situm.com/en/privacy
- Master Subscription Agreement: https://situm.com/assets/docs/situm-masteragreement.pdf
- Security Info: https://situm.com/docs/hosting-data/
- Data Processed. Typically, it will be (more info here):
- Unique device identifier (pseudoanonimized)
- Device brand, model, and hardware/firmware version
- Operating system and version
- Sensor data (e.g., accelerometer, gyroscope)
- Nearby wireless elements (e.g., Wi-Fi access points, Bluetooth beacons)
- Device geolocation
- Building maps, points of interest, and navigation routes
- Network interaction data (e.g., IP address, crash logs, activity logs)
- Purpose of Processing. You should state the purpose of this data collection / processing.
- Typically, this data will be used exclusively to enable indoor positioning, navigation, and wayfinding features in the app. Sometimes, you may also use it to retrieve indoor analytics (e.g. knowing the most visited areas of a venue) or to track specific persons (e.g. for employee tracking apps).
- Example: “We use indoor positioning services powered by Situm to provide turn-by-turn navigation and contextual information based on your location within a building.”
- Hosting. Situm hosts data within the European Union. More info here.
- Use of subprocessors. Situm uses the subprocessors described in our Master Subscription Agreement, Annex II.
Google Play #
Google – Things to consider #
When uploading your app to Google Play, there are four areas within the App Content section of the Play Console that are directly related to Situm and will require your attention:
- Privacy Policy – Your app must include a privacy policy that reflects Situm’s data usage and complies with Google Play’s requirements.
- Foreground Permissions – You must explain why your app uses location data, including Foreground Service Permissions usage
- Data Safety – You’ll need to disclose what user data is collected and how it’s used. Situm may process location data and device identifiers, so you must declare this transparently.
- Data Security – You will need to answer questions related to data encryption.
AndroidManifest #
You need to explicitly add the ACCESS_FINE_LOCATION permission to your AndroidManifest.xml, as it is not provided by the SDK. In addition, this permission must be requested at runtime.
If your building is configured with BLE beacons, you must also request the BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions at runtime. If BLE beacons are not used in your building, these permissions are not required.
You may also optionally request the POST_NOTIFICATIONS permission in order to show the Situm foreground service notification to the user.
In any case, we recommend to review our specific documentation on this permissions point to clarify any aspect.
Foreground Service Permissions #
The Situm SDK includes a declaration for a foreground service in its Android manifest. As a result, any app integrating the SDK will be required to justify the use of this service when publishing to Google Play.
Specifically, Google Play mandates that developers:
- Declare the reason for using a foreground service. For Situm SDK, the appropriate reason is:
“Navigation”. - Provide a URL to a video demonstration showing the foreground service in use during actual navigation within your app.
- This video must clearly show that the service is being used to provide turn-by-turn or continuous navigation to the user, justifying the background location and foreground service usage.
- To this extent, you should compute a navigation and clearly show that the “Foreground Service Notification” is being shown to the user even when the app goes to background.
- Note: In some modern Android versions, this notification might not be 100% clear / visible if the user didn’t grant POST_NOTIFICATIONS permission. You might need to grant it to record the video.
- Here’s an example on how we did it in our of our apps, you may use it as inspiration when recording your video: Sample Video.
Data Safety #
The Situm SDK requires access to certain types of data in order to function properly.
Therefore, when publishing an app that integrates Situm, developers are required to complete the “Data Safety” section in the Google Play Console and declare all relevant data collection, sharing, and usage practices, as outlined by Google:
Data Types Collected #
- Location data: Situm collects precise location data to provide indoor positioning and navigation services.
- Collected: Yes
- Shared: No
- Purpose: App functionality
- User control: Users cannot disable this data collection, as it’s essential for the service to work.
- Device or other identifiers (e.g., a unique device pseudo ID): Situm processes a device pseudo identifier.
- Collected: Yes
- Shared: No
- Purpose: App functionality
- User control: Not user-configurable.
Data Security #
All data handled by the Situm SDK is encrypted in transit and at rest, which allows integrators to confidently answer “Yes” to the relevant data security questions in the Play Console.
Google Play – Publishing process #
Once we have reviewed the necessary documentation to finalize our application publishing process on Google Play, let’s look at the main steps to take on that platform.
The initial step involves choosing the Create App option, as shown in the following screenshot, and on that screen indicating basic concepts of our application, such as the name or the type of application (Game or App).
The first step is to select the “Create App” option, as shown in the following screenshot. On that screen, you’ll need to provide basic information about your application, such as its name and type (Game or App).
Once you’ve entered this initial information, the next step is to attach the documents we’ve seen throughout this page to your application submission request using the “Set up your app” option.
Once these aspects related to the application information are covered,the next step is to choose the application category, contact details, and market in which we want the application to be published.
Once we have filled in the requested information fields about our application, we can publish it through the Test and Release menu, specifically through the Create new release option.
This will take us to the next screen, where we can upload our application files.
The final step in this process is to select the countries/regions in which we want to publish our application
With this additional information, which we can see on the summary screen, we’ll be able to request pre-publication review from the Google team, a process that typically takes about a week.
Once that time has passed, and with Google’s approval received, the app will be ready for publication on the Google Play Store.
Apple Store #
Apple – Things to consider #
When submitting your app to the Apple App Store, there are several areas where Situm SDK’s use of location and device data must be declared. Below are the required steps to ensure compliance with Apple’s guidelines:
Info.plist #
You must add the appropriate permission keys in your Info.plist file to request user consent for location usage. Specifically, include:
NSLocationWhenInUseUsageDescriptionNSLocationAlwaysAndWhenInUseUsageDescription- (Optional)
NSMotionUsageDescription– Only if you will use the barometer sensor (only for indoor venues with multiple floors).
Reference: Situm Docs – Grant App Permissions (iOS)
App Privacy Questionnaire #
When uploading your app, Apple will ask some questions about the data processed.
- Click on Begin button to start the questionnaire.
- Select the “Yes, we collect data from this app.“ option. Click Next.
- Select “Exact location“ and “Coarse location“.
- Then, for each one of the options selected before:
- Check both “Analytics“ and “App Functionality” and click on Next.
- Select “No, precise location data collected from this app is not linked to the user’s identity”.
- Select “No, we do not use precise location data for tracking purposes“.
Privacy Report #
You are required to provide information about your app’s data usage via a Privacy Report, which includes any data access declared by Situm SDK.
To generate it:
- Open Xcode and archive your app.
- Select the archive → Right-click → Choose “Generate Privacy Report”.
This will export a PDF file showing your apps data accesses included those used by your depencencies. You may need to manually review the report and ensure the information related to Situm SDK is complete and accurate.
If you’re unsure about what Situm declares in its Privacy Manifest, here’s our Privacy Manifest:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyCollectedDataTypes</key>
<array>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>NSPrivacyCollectedDataTypePreciseLocation</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>NSPrivacyCollectedDataTypeDeviceID</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>NSPrivacyCollectedDataTypeProductInteraction</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>NSPrivacyCollectedDataTypeSearchHistory</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>NSPrivacyCollectedDataTypePerformanceData</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
<dict>
<key>NSPrivacyCollectedDataType</key>
<string>Other diagnostic data</string>
<key>NSPrivacyCollectedDataTypeLinked</key>
<false/>
<key>NSPrivacyCollectedDataTypeTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypePurposes</key>
<array>
<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
</array>
</dict>
</array>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>C617.1</string>
</array>
</dict>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategorySystemBootTime</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>35F9.1</string>
</array>
</dict>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>CA92.1</string>
</array>
</dict>
</array>
</dict>
</plist>
Apple Store – Publishing process #
We start the process of publishing our application to the Apple Store with the button shown in the following screenshot, and here we will enter basic data about our app.
The next step in documenting our app for submission to the Apple App Store is to add screenshots of our app, a brief description, and some basic information such as version, app category, age rating, etc.
Once we have completed the information requested by Apple to review the application before its publication in the Apple Store, from xCode we must build and upload the application, following the process shown in the following screenshots.
Finally, once the file upload process is complete, along with the rest of the information we have been discussing,we will be able to add the application for review prior to its publication in the Apple Store via the button shown in the following attached screenshot.
Once this review process by the Apple team is complete, our application will become available for download through the Apple Store.