When it launches this fall, iOS 14 will bring several new permission changes for requesting access to the user’s location, advertising id, photos, and local network. This blog breaks down the upcoming changes and provides recommendations on how best to handle these new privacy-related permission prompts.
Location Permission Changes
Apple is continuing with its commitment to give app users more control over their data and privacy. Last year, with the release of iOS 13, Apple gave users the option to decide if the app should have access to their location only once, only while using the app, or always.
This year, with the release of iOS 14, Apple will build upon that and allow users also to decide if the app should have access to their precise location or just their approximate location.
New: Precise Location Toggle
When an app requests the user’s location, the user will be presented with a permission prompt asking for location access with the same options as iOS 13: Allow Once, Allow While Using App, or Don’t Allow.
Like with previous versions of iOS, the title of the permission prompt is controlled by Apple, but the app developer configures the subtext. The subtext is intended to provide the user with an explanation of why the app is requesting this permission.
What’s new in iOS 14 is the user’s ability to toggle precise location on and off. The precise setting is enabled by default, which means the app will get the user’s fine location. If the user disables this, then the app will only get the user’s approximate location. In our tests, the approximate location may return location coordinates for a user up to 2 miles away.
New: Temporary Request for Precise Location
Another change is the app’s ability to temporarily request precise location if the user previously only allowed approximate accuracy. This is a one-time permission request that, if granted, only lasts during the duration of the app session. According to Apple, “This approach to expiration allows apps to provide experiences that require full accuracy, such as fitness and navigation apps, even if the user doesn’t grant persistent access for full accuracy.”
Background Location Permission
App developers may need the user’s location in the background to support features such as Geofence notifications. Same as in iOS 13, Apple doesn’t allow this option on the first request but instead allows the app developer to request this permission at a later time. If your app requested Always Allow permission, then this prompt will be displayed automatically the next time the user launches the app, but typically not the same day the initial prompt was displayed.
Once an app has received the user’s location in the background a significant number of times, Apple will inform the user and ask them if they want to continue allowing this. This is also unchanged from iOS 13.
New: Updated Location Settings
Users can adjust their location settings in the iOS Settings app by navigating to Privacy → Location Services → App Name.
Users will have the option to adjust their location access to Never, Ask Next Time, While Using the App, or Always.
If a user receives a location permission prompt and selects Allow Once, their location setting will be Ask Next Time, prompting them to make a selection again the next time the app requests their location.
What’s new in iOS 14 is the Precise Location toggle, which allows users to switch between precise and approximate location.
Impact
The most significant impact of these changes will be on apps that require a precise location, such as navigation apps or apps that use geofence notifications. Given that an approximate location could put the user miles away, the precise location option is required for these apps.
As mentioned earlier, the app has the option to temporarily request precise location from a user who has previously only granted approximate location. This request can be triggered when the user begins a task that requires fine location, such as wayfinding.
However, there isn’t an explicit user action to trigger this temporary permission request when it comes to geofence notifications, so the temporary precise location prompt won’t help us here.
In addition, geofence notifications require the Always Allow background location selection, so apps that promote this feature will feel the impact most.
Recommendations
- Don’t request the user’s location until you need it.
- Include a usage description clearly explaining why you need the user’s location.
- Don’t request Always Allow permission unless you have a feature that requires the user’s location when the app is closed or backgrounded.
- If you require precise location, but the user has only granted approximate location, use a one-time temporary precise location request.
- If you require Always Allow + Precise location settings for Geofences, but the user hasn’t granted this, then to increase user acceptance, include a custom alert or screen informing the user the benefit of allowing this and provide instructions on how they can change this in iOS Settings, with a button that deep links them there.
- Remember, if the user chooses Don’t Allow, you won’t be able to request this permission again.
IDFA Permission Changes
The IDFA, or Identifier for Advertisers, is going to change as we know it. Ad agencies have relied on this device identifier for years to track users across apps and websites to learn their habits and interests so that they can target them with relevant ads.
This was made more difficult with the release of iOS 10 when users could enable a Limit Ad Tracking setting, which would return all zeroes for this identifier. Before that, the only thing a user could do is reset their identifier value, but this was seldom used.
New: IDFA Prompt
iOS 14 brings the strongest changes to the IDFA yet, which may effectively kill it as the primary way advertisers track users. Rather than defaulting to having the IDFA available, developers will now have to prompt the user to allow access to the IDFA.
The wording in the permission prompt will undoubtedly lead to a majority of users declining this permission: “App would like permission to track you across apps and websites owned by other companies.“
Like the Location Permission prompt, the IDFA prompt’s title is controlled by Apple, but the app developer configures the subtext. Developers will have to come up with a usage description convincing enough to persuade users to allow themselves to be tracked.
According to Apple, “The App Tracking Transparency framework is only available in the iOS 14 SDK. This means that if you haven’t built your app against iOS 14, the IDFA will not be available and the API will return all zeros.”
However, on September 3, 2020, Apple extended the deadline to 2021, by stating, “To give developers time to make necessary changes, apps will be required to obtain permission to track users starting early next year.“
New: Updated IDFA Settings
Also new in iOS 14 is a toggle in iOS Settings that, when disabled, prevents app developers from ever prompting the user for permission to use their IDFA. A user can find this in the iOS Settings app under Privacy → Tracking and applies globally to all apps.
Impact
The most significant impact will be on the ad industry. Without a guaranteed way of tracking users across apps and websites, advertisers will need to rely on less tracking users’ ways of tracking. Since getting the user’s IDFA was never guaranteed, advertisers already have fallbacks methods for tracking users. Such methods include fingerprinting, where a collection of other information about the user, such as IP address, device model, and rough location, is used to verify that they are the same user. Another option is to use sampling since there will still be some users who allow themselves to be tracked. For example, if 5% of tracked users installed the app through a particular install ad, one can presume that about 5% of all users can be attributed to that campaign.
Recommendations
- Don’t request the user’s IDFA if your use case can be satisfied with the IDFV (Identifier for Vendor) instead. The IDFV is similar to the IDFA in the sense that it’s a unique identifier for the user. However, each app developer will be assigned a different IDFV per user, so this doesn’t help in tracking users across apps and websites by other developers. Since there are no privacy concerns, there is no permission prompt needed to obtain the IDFV and the user has no way to disable this.
- Include a usage description clearly explaining why you’d like to track the user across apps and websites
- Consider a custom prompt in advance of the official IDFA permission prompt to provide your users with more context before the scary system prompt is presented.
- If a user declines the IDFA permission and you need to track them outside your app, use probabilistic methods such as fingerprinting or sampling.
- Remember that if the user chooses Ask App Not to Track or if they disable the ability to prompt for this permission in Settings, then you won’t be able to request this permission. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there.
Photo Permission Changes
Apple has required users to grant permission to their cameras or photos since iOS 8. However, this was an all-or-nothing permission, giving the developer access to all Photos. New in iOS 14 is the ability for users to choose if they want to grant access to all photos or only specific photos.
New: Select Specific Photos
The initial photo permission prompt will ask the user if they would like to grant access to one or more specific photos, grant access to all photos, or decline this permission. A user who is simply trying to upload one specific photo may choose only to grant access to that photo.
If a user only grants access to specific photos, the next time the app requests the photo permission, the user will receive a slightly different permission prompt. The new prompt will ask them if they would like to allow access to more photos or keep the current selection of photos they’ve previously allowed.
New: Updated Photo Settings
Users can adjust their location settings in the iOS Settings app by navigating to Privacy → Photos → App Name. Users can choose from the following options: Selected Photos, All Photos, or None.
If Selected Photos is chosen, then an option to Edit Selected Photos appears. Tapping this presents a Photo Picker, which includes search functionality, the ability to view albums, and the ability to view previously selected photos.
Note: The permission prompts and settings options only refer to photos. However, the same applies to videos.
Impact
This new privacy change should have minimal impact on apps that require the user to grant permission in order to upload specific photos or videos. The biggest impact will be on apps requiring permission to the entire camera roll, such as Google Photos.
Recommendations
- Don’t request photo access until the user is performing an action that requires this, such as uploading a photo or video.
- Include a usage description clearly explaining why your app requires this permission.
- Remember that these permission changes apply to videos as well.
- Remember that if the user chooses Don’t Allow, you won’t request this permission again. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there.
Local Network Permission Changes
There are many legitimate reasons an app might need to use the local network. For example, it may connect to a printer, search for nearby players for a game, or control the lights in a home.
At the same time, there are also less legitimate reasons that apps use the local network. They could be collecting information about the devices on the local network to create a “fingerprint,” which allows them to infer that a user is at home, even if without granting location permission.
In iOS 13, Apple required apps to request permission for access to Bluetooth. Now in iOS 14, they are doing the same for the local network. If your app communicates to devices over your home WiFi, for example, then it is operating over the local network and will trigger this new permission prompt.
There are exceptions to system-provided services such as AirPrint, AirPlay, AirDrop, or HomeKit. These system services handle device discovery without exposing the full list of devices to the app, so they are exempt from triggering this permission prompt.
Any other network connections outside the local network (e.g., Web Services, APIs, or other connections to the internet) are not impacted and do not require permission.
New: Local Network Prompt
When an app tries to connect to the local network, it will trigger a Local Network Permission Prompt even if only to view available devices.
Impact
Many applications use the local network for use cases other than the system services previously mentioned. We’ve found that most streaming apps trigger this permission prompt upon launch, likely because they support Google Cast. There may be apps that have Analytics SDKs that collect this type of information. Those apps will also display this prompt upon app launch.
Recommendations
- Add logic to defer this permission prompt until the user performs an action that requires it, such as searching for nearby players or casting a video.
- Include a usage description clearly explaining why your app needs to use the local network.
- Remember that if you change nothing before iOS 14 release date and your app uses the local network, this permission prompt will be one of the first things the users see when they launch your app on iOS 14.
- Remember that if the user chooses Don’t Allow, you won’t request this permission again. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there.
Other Privacy Changes
New: Microphone/Camera Indicator
iOS 14 will display a colored dot in the status bar, indicating the current app is actively using the microphone or camera. Be careful not to use any low-level camera/microphone APIs unless the user is performing an action to capture audio or video.
New: Pasteboard Alerts
iOS 14 will display a banner at the top of the screen, indicating the current app has just extracted the contents of the user’s Pasteboard (also known as clipboard). Some apps use the pasteboard to detect copied URLs to surface the right information when the user moves to their native app.
Be careful with any Analytics SDKs you include in your app that may be collecting this user data.
More Info
For a quick and easy reference to the iOS 14 permission changes discussed in this blog, download our Location Cheat Sheet:
Download The Location Cheat Sheet
WWDC 2020 Videos
- Build trust through better privacy
- Design for location privacy
- Support local network privacy in your app
At Phunware, our Engineering team is dedicated to staying up-to-date with the latest changes from Apple WWDC and Google I/O. If you’re a Product Manager looking for a Location or Analytics SDK built by a team that understands these privacy-related changes, then visit our Products page for a complete list of our software products, solutions, and services.
