Location Permissions

Colocator cannot work unless users agree to share their location (also known as opting in to location services). Specific levels of permissions are required.

What are location services permissions?

Any app that uses location must request location permissions from the user in order to receive any location data from the operating system. Typically this is done as part of an onboarding process when the app is first opened.

There are different levels of location services permissions as we shall see.

Why do you need them?

We need them because without them we don't get any data. It is mandatory under Apple and Google’s rules to obtain a positive opt-in to location services. Where such location data might constitute personal data (for example under GDPR or similar regulations) it is also a legal requirement.

What level of location services permissions are needed for Colocator?

There are differences between Apple’s mobile operating system (iOS, iPhones) and Google mobile operating system, Android (e.g. handsets from Google, Samsung, Huawei, Sony, LG, Nokia, etc).

For Apple iOS:

• Colocator requires persistent background location services permission, known as “Always Allow”.
• This enables the Colcoator SDK to receive location updates even when the app is not on the screen (i.e. running in the foreground), when the app is swiped closed or when the phone is in locked mode.
• Colocator does not receive sufficient data to operate where the user has given “Only While Using the App” level permission. However, Apple’s rules enable the app to request the user ‘upgrades’ their locations services to “Always” if “Only While Using” permission has previously been granted - this requires a secondary positive opt-in on behalf of the user.
• If the user selects “Don’t Allow”” Apple’s rules make it difficult for the app to ask that user to change their location permissions. Instead, the user would need to be directed to their iPhone’s Settings (Privacy > Location Services) to alter the level of location services permissions for that app.
• From iOS 13 onwards it is no longer possible to directly ask a user for “Always” permission during initial onboarding. The options are: “Allow when using the app”, “Allow Once”, “Don’t Allow”.
• If the user selects “Allow Once” iOS 13 will grant the app location permissions for a single session only. The user will continue to see the system prompt for location services permission every time they relaunch the app, if they continue to select this option.
• If the user selects “Allow when using the app”,, once the Colocator library has tried to gather location data in the background the user will then be asked via a system notification to “Keep Only While Using” or “Change to Always Allow” the next time they unlock their phone.
• In IOS13 the optimal permissions flow is therefore:
  • Initial onboarding / first launch app → Obtain “Allow While Using App” permission
  • Subsequently → Obtain “Always Allow”

For Android:

• On Android 9 and below has a simple “Yes” / “No” for location permission. The user must select “Yes” for Colocator to function.
• You can ask for location permission after the user has said “No” but on the second attempt a “Never Ask Again” checkbox may appear that will prevent further requests.
• On Android 10 and above the options change to “Allow all the time”, “Allow while using the app” and “Deny”. The “While in-use” option is not sufficient for Colocator to function.

Tips on how you might maximise opt-ins

There is no definitive best practice because each app is unique. However, we recommend the following, illustrated by the examples that follow.

• Carefully consider the explanation as to why the app needs “Always On” location (iOS) or location on (Android 9) or “Allow all the time” (Android 10 or above).
• This is a value exchange - if the user thinks the request is reasonable (e.g. for crowd safety, for an enhanced app experience) or fears missing out (e.g. on offers or relevant location-based communications) then opt-in rates will likely be higher.
• In any event, your app’s privacy policy will clearly articulate why and how your app is using any location data gathered (for compliance with GDPR or other data privacy regulations).
• In both iOS and Android there are mandatory operating system pop-ups for location services (just as there is for push messaging) but this can be supplemented with an in-app page setting out clearly and succinctly the benefits for the user to opting in to “always on” location services. See the examples below for more on this.
• In iOS while initially getting “While Using App” means location data will not be available to Colocator, it does keep open a clear upgrade path to getting “Always” (which is what is required). Getting “Never”/”Don’t Allow” makes it far more difficult.
• Consider a communications strategy designed to encourage opt-ins. Examples might include in-app notifications or push messages, links to settings from within the app, etc. Some examples on this follow below.

Examples

Festival X (iOS)

• This app contains a page during the onboarding process which provides a clear explanation of the benefits of location sharing in the app copy (fig 1a below). Because this copy is entirely in-app (rather than an operating system notification) it is entirely editable without restriction.
• In iOS there always follows the system notification screen (fig 1b below). Copy on this screen can be edited in part, but not the headline (“Allow to access your location”) or the order (and wording) of the options (“Only While Using App”, “Allow Once” “Don’t Allow”) cannot be changed.
• The text which starts “Only by selecting ‘While Using App’…” is entirely editable and should give clear signposting and explanation, and if relevant play on FOMO (fear of missing out)

Figure 1A

Figure 1B

Tile (iOS)

• The Tile app provides a good illustration of how guidance can be provided to the user through in-app messaging as to how to update their settings if “Always Allow” location has not been activated for the app.
• Tile helpfully includes a “Settings” button which opens the Settings page for the app (fig 2a). This in-app messaging can be displayed prominently if “Never” or “Only Once” or “Only while Using the App” was selected previously.
• Additionally Tile activates a splash page in the app if location services permissions are not correctly configured, with concise instructions. Again this directs the user to Settings page (fig 2b).
• Turning location services to “Never” also immediately activates an in-app notification warning (fig 2c). The text for this custom notification is governed by the app so is entirely editable.

Figure 2A

Figure 2B

Figure 2C