As an engineer working on the Pilgrim SDK, I help our partners enable unique location use cases, while maintaining the important privacy standards that our users expect. When Apple announced their iOS 14 privacy changes, the tightrope became a little tighter for location technologies: the changes are great for app users who want more control of their data, but at first glance, create some new technical challenges for partners that require Precise Location. So, I decided to take a closer look. Here are my takeaways and recommendations after reviewing the iOS 14 security and privacy changes on the Foursquare City Guide app.
Updated Location Permission Prompts
What’s New:
iOS 14 introduces an updated permission prompt which includes a map and an additional toggle in the top left-hand corner of the map. This toggle allows users to turn on or off the “Precise Location” authorization. When switching between the two, the user is presented with two different maps. When the toggle is “ON,” the map shows the user’s exact location via the traditional “blue dot.” When the toggle is “OFF,” the map shows a zoomed-out view with a larger blue circle spanning a few miles surrounding the user.
Precise Location Option
iOS already allows users to select when an app tracks your location (always; while the app is in use; once or never). iOS 14 takes this a step further by allowing users to specify the accuracy of the locations they share, choosing between an approximate region and a precise location coordinate. What we end up with is a further segmented permission matrix: all the old permission options about when the app may access location crossed with the new permission options about how accurate those locations should be.
Why it Matters:
If the user opts out of “Precise Location,” an app will receive low-frequency, imprecise data about the user’s location. These “approximate locations” will arrive 4 times an hour for as long as the app has permission to access location. The interesting thing about these locations is that the latitude and longitude won’t actually represent a GPS point collected by the phone. Instead, Apple has broken down the world into different-sized regions which appear to be anywhere from 3KM (1.8M) to 12KM (7.4M) in diameter. The coordinates of the location sent to an app are actually the center of the region that the user is inside of. The horizontal accuracy listed for the location represents the diameter of the region. If a user moves around inside this region without ever crossing its boundaries, the app will continue to receive the exact same latitude, longitude, and horizontal accuracy. For this reason, it is very important that an app identify when a user has opted out of “Precise Location”.
What you should do:
To address this, we should update our code to view these approximate locations as more akin to large geofences. When a user leaves one region and enters another we’ll be notified by way of receiving the new region’s center location. This will allow us to update our apps with valuable information about the new region that the user might be interested in.
In order to identify that a location is approximate, we can’t simply look at the CLLocation object. Instead, we have to access the accuracyAuthorization property on the CLLocationManager. From that property we can identify that our app has either reducedAccuracy or fullAccuracy permission enabled and infer that all locations collected are either approximate or precise.
Fast facts about approximate location:
- Approximate location regions range in size from 3KM (1.8M) to 12KM (7.4M).
- Approximate locations are updated 4 times an hour for as long as the app has permission to access location.
Temporary Precise Location Permission
What’s New:
Another important part of interfacing with the new accuracy permission is utilizing the requestTemporaryFullAccuracyAuthorization method. This method can be utilized when the user has consented to location permission but has opted out of the “Precise Location” option. If an app has an important feature that requires precise locations for a short period of time, this method allows the user to utilize individual features of an app without having to give up their precise location permanently. This micro-permissioning is further supplemented with the ability to add various “purpose strings.” Rather than simply showing its original location permission request copy, an app can now customize the copy to fit the location feature at hand.
Why it Matters:
Apple is betting that users who are wary of location collection might be happier giving permission on a feature-by-feature basis. Therefore, if an app that previously needed indefinite precise location can be subdivided into multiple short term location permission features, it would get many opportunities to request precise location. Apps that need continuous precise location can only prompt once – and only have that one chance to win over users. That said, a constant flow of permission dialogs is likely to exhaust users so the best solution may lie somewhere in between.
iOS 14 Permission Options Summary
| Precise Location | Approximate Location |
|---|---|
| Precise Always | Approximate Always (NEW) |
| Precise When In Use | Approximate When in Use (NEW) |
| Precise Once | Approximate Once (NEW) |
| Precise Temporary (NEW) |
Finally, users can always manage location permissions in the app settings, iOS 14 is adding an additional toggle to manage Precise Location.
Fast facts about the new precise and temporary location prompts:
- The Precise Location toggle is set to “on” by default.
- When a user upgrades to iOS 14, if any type of location permissions was granted to an app it is automatically given the Precise Location authorization.
- The developer can select to NOT allow Precise Location as an option. This removes the Precise switch from the map and will only deliver Approximate Locations to the app.
IDFA
Starting in iOS 10, access to a device’s IDFA was controlled with a single “Limit Ad Tracking” switch in the Privacy section of Settings. When the switch was enabled all apps on the device would receive an obscured IDFA set to all zeros rather than a real identifier. With iOS 14, Apple has continued its trend towards locking down a device’s IDFA by increasing the granularity of the permission and making it opt-in rather than opt-out.
What’s New:
In the new IDFA flow, an app can request access to the IDFA via a prompt to the user. If the user opts to allow tracking the app will be able to access the IDFA via the same method as before. The user also has a global “Allow Apps to Request to Track” switch which they can toggle to suppress all IDFA prompts moving forward.
With the removal of the “Limit Ad Tracking” switch, Apple has also deprecated the isAdvertisingTrackingEnabled method which allowed developers to check if the IDFA was available to collect. Developers will now need to switch over to the new AppTrackingTransparency framework’s trackingAuthorizationStatus method to see the permission state of the IDFA. They will then use the requestTrackingAuthorization method to prompt for permission to collect the IDFA.
Why It Matters:
Apple is again making the bet that permission granularity will allow users who might otherwise opt-out of all tracking to opt into tracking by some apps. While this change does likely mean less IDFA availability overall, it also creates an opportunity to convince users of the value of sharing their data. For those users who don’t choose to disable the “Allow Apps to Request to Track” switch we have a chance to present our case for collecting IDFA and controlling when and how exactly we make that case.
Fast Facts about the new IDFA prompt:
- When a user upgrades to iOS 14, the “Allow Apps to Request to Track” switch is set to “on” by default.
- Until an app obtains permission from the user to collect the IDFA, it remains obscured.
- If a user declines the Cross-App Tracking permission, developers from within the app can still push users directly to the app settings section to turn ON or OFF “Allow Apps to Request to Track”.
Apple’s Privacy-Focused ‘Nutrition Labels’ for Mobile Apps
During the WWDC presentation, Katie Skinner, Apple’s manager of user privacy software, highlighted the difficulty for users when reading through lengthy complicated app privacy policies on a mobile device.
Apple’s goal with this new privacy feature is to help users understand easily what data app publishers are collecting and sharing. On stage she explained, “You can see if the developer is collecting a little bit of data on you, or a lot of data, or if they’re sharing data with other companies to track you, we will show you what they tell us.”
What’s New:
Moving forward, Apple will display a summary of apps’ data collection practices on the App Store pages. This will help users identify what kind of data they might be handing over before downloading an app.
Erik Neuenschwander, Apple’s director of user privacy, stated that, “Apple is going to require each developer to self-report their practices”. For now, the Privacy Card information is entirely self-reported. This is an opportunity for developers to be more transparent about their user data usage.
Conclusion
iOS 14 is inline with Apple’s focus on security and privacy and is going a step further along since iOS13 to help users manage their personal data.
To be prepared for the iOS 14 roll out in September, here are my 2 top recommendations:
1. Transparency
Be transparent with your users, explain and upsell the value exchange of data. What will they get in return for granting you access to their personal data? Review each feature that leverages location services and IDFA sharing and think about how the user benefits. Translate those benefits into copy in your onboarding flows and permission dialogs.
After the iOS13 release last year, we ran several location permission onboarding experiments on the Foursquare City Guide. We took advantage of the app onboarding flow and the new location permission prompts to clearly state to users why we were collecting location data and how we were using that data. The new visuals and copy led to a 51% increase in users enabling location services and a 34% increase in app install retention globally. iOS 14 is pushing privacy and transparency even further; embrace it by starting a direct and sincere conversation with users about data collection in your app.
2. Remove friction
Another experiment we ran on the Swarm app was adding a “skip” button on the first onboarding screen rather than requesting location permission right off the bat. We only prompted users for location permission when they attempted to use a feature that required it, such as search or check-ins. This change resulted in a 25% increase in our location permission conversion rate. Consider reframing the permission requests so that they are presented at a time when users are engaging with a feature powered by location services.
The introduction of precise/approximate location in iOS 14 gives users even more ways to dip their toes into location permission. For developers, this means many decisions about when and how you present the “temporary precise location request” dialog. This micro-permissioning and its corresponding ability to add various “purpose strings” allows an app to customize the dialog’s timing and copy to fit the location feature at hand. Once the user has experienced a feature’s value, you can suggest they update the precise location permission in Settings rather than being bombarded by request dialogs each time.
Stay tuned for iOS 14: Foursquare Mobile Engineering Take 2. We will take a deeper look at the long term impact of iOS 14 on our mobile apps, specifically IDFA and prompt behaviors, and share our learnings with you.
