iOS 14 Updates

iOS 14 comes with new features and a new focus on user privacy. It introduces a new way of dealing with IDFA identifiers and tracking of users across sessions and apps.
Important changes:

• User privacy changes
  • App Tracking Transparency framework
  • IDFA changes
• Location tracking and permission changes
• Data collection description

A full preview of all iOS 14 changes can be read on Apple's official page.

Summary

On a high-level you should:

• Revisit which user identifier are you utilizing. Good news: the one that Leanplum uses by default is not affected by the changes, but you might have chosen another one explicitly.
  • If you have chosen IDFA, you will have to ask users for a specific app tracking permission.
• Check if you need to target users based on precise contextual location in your campaigns - if yes, make sure you understand the consequences of the latest Apple policy, for some of your users you might get less precision than before.

User privacy changes

📘

UPDATE January 28, 2021

With iOS 14.5 Apple will start to enforce the new privacy rules that are announced in the following article.

The requirement to use AppTrackingTransparency when requesting permission to track users and access device advertising identifiers will now go into effect. This will happen with the upcoming beta update of iOS 14 and will roll out to everyone in early spring with the upcoming release. More information can be found in the above article.

Further Update
Apple has added now the following information about the Identifier for Vendors (IDFV):
The ID for Vendors (IDFV), may be used for analytics across apps from the same content provider. The IDFV may not be combined with other data to track a user across apps and websites owned by other companies unless you have been granted permission to track by the user.

The IDFV will still be a valid identifier even without requesting permission to track. However, you still need to request tracking, if you use the IDFV to track users across other apps and websites not owned by your company.

📘

Apple announced that the privacy changes will be delayed until 2021. The IDFA can still be used without the prompt to the user.

Apple introduced significant changes to how IDFA identifiers are granted. In iOS 14, users must be asked whether they want to grant access to the IDFA identifier and allow the app to track them through the App Tracking Transparency framework. If permission is declined, IDFA identifier will be all zeros (empty UUID), rendering our ability to track them invalid.

📘

Leanplum SDK uses IDFV by default (identifier for vendor), which is a unique UUID shared across all apps from the same vendor.

We support setting Device ID to IDFA by calling LEANPLUM_USE_ADVERTISING_ID macro which will get the IDFA identifier.
Note that this macro will be deprecated starting from iOS 14 and it will not work as expected. The previous method for checking if the Ad Targeting is enabled no longer works and is deprecated by Apple - isAdvertisingTrackingEnabled.
Using the macro will not call the method to set the deviceId. In this case, the device id will fallback to IDFV.

If you have previously used the LEANPLUM_USE_ADVERTISING_ID macro, you need to change your app code.
You need to request access first and then set the device id using the setDeviceId method. The IDFA is still accessed through the ASIdentifierManager.

If you request advertising authorization, you must add the NSUserTrackingUsageDescription (Privacy - Tracking Usage Description) key in your Info.plist file describing why you need access to this tracking. The description entered there will also be shown in the prompt displayed to the user.

<key>NSUserTrackingUsageDescription</key>
<string>Test iOS 14</string>

#import <AdSupport/AdSupport.h>
#import <AppTrackingTransparency/AppTrackingTransparency.h>

[ATTrackingManager requestTrackingAuthorizationWithCompletionHandler:^(ATTrackingManagerAuthorizationStatus status) {
            switch (status) {
                case ATTrackingManagerAuthorizationStatusAuthorized:
                    NSLog(@"Authorized");
                    NSLog(@"%@", [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString]);
                    break;
                    
                case ATTrackingManagerAuthorizationStatusNotDetermined:
                    NSLog(@"NotDetermined");
                    break;
                    
                case ATTrackingManagerAuthorizationStatusRestricted:
                    NSLog(@"Restricted");
                    break;
                    
                case ATTrackingManagerAuthorizationStatusDenied:
                    NSLog(@"Denied");
                    break;
                    
                default:
                    NSLog(@"Unknown");
                    break;
            }
        }];

Documentation on the Request Tracking Authorization can be found here: requestTrackingAuthorization.

🚧

You can request the tracking authorization prompt only once - your app will not be allowed to show the prompt to the user again unless the user re-installs the app.

If the user has previously used the IDFA but now declines access, the device id will now use IDFV since the IDFA will be an empty UUID (00000000-0000-0000-0000-000000000000).
This will result in a new device under the user profile. The push notification token will be moved to this new device and removed from the previous one.

With the recent changes in mind, we do not recommend using the IDFA as the main device identifier - you can use the SDK default mechanism (IDFV with fallback to md5 of MAC address) or your own UUID. You can still send Leanplum the IDFA and track it.
Since the user can decline the advertising request or accept it, later on, it is not a stable device identifier.

Since you can request authorization only once per app install, you can create a custom message similar to the Push Pre-Permission to soft ask the user for ads consent. You can provide information about what and why is tracked and what the benefits are - further personalized experience and personalized ads etc. depending on the app.

Location Changes

Apple introduces new location settings - precise location. The user can now enable or disable Precise Location tracking. Apps should consider what accuracy they need based on individual use cases. Turn by turn Navigation apps make sense to require precise location (full accuracy) and social apps could in general only need reduced accuracy location.

This WWDC Video explains these changes in detail and provides examples of the different use cases.

📘

Users who have already granted location access will continue to provide precise location after upgrading.

Example with reduced and precise location - if we are in the Apple park, precision location will give us the exact location - Apple park, whereas reduced location will provide us with just Cupertino.

Reduced location can provide a radius of few kilometers to even up to 12km (the location horizontal accuracy). In our tests, it varied from 3600 meters to 7000.

🚧

Region monitoring now requires full accuracy. Beacons and regions - region entry and exit notifications will not be delivered for apps that are not authorized for full accuracy. You will need to get full accuracy to use this feature.

The type of accuracy is accessed through the Accuracy Authorization.
Apps can request temporary full accuracy authorization if needed, depending on the specific feature the user wants to use - requestTemporaryFullAccuracyAuth.

- (void)locationManagerDidChangeAuthorization:(CLLocationManager *)manager
{
    if (@available(iOS 14.0, *)) {
        CLAccuracyAuthorization accuracyAuthorization = manager.accuracyAuthorization;
        switch (accuracyAuthorization) {
            case CLAccuracyAuthorizationFullAccuracy: {
                NSLog(@"FullAccuracy");
                break;
            }
            case CLAccuracyAuthorizationReducedAccuracy: {
                NSLog(@"ReducedAccuracy");
                // Request temporary full accuracy
                [manager requestTemporaryFullAccuracyAuthorizationWithPurposeKey:@"ForBeacons"];
                // Or go to settings
                NSURL *url = [NSURL URLWithString:UIApplicationOpenSettingsURLString];
                [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:nil];
                break;
            }
            default: {
                break;
            }
        }
    }
}

Note that the purpose key must be defined in the Info.plist under the NSLocationTemporaryUsageDescriptionDictionary (Privacy - Location Temporary Usage Description Dictionary).

<key>NSLocationTemporaryUsageDescriptionDictionary</key>
	<dict>
		<key>ForBeacons</key>
		<string>Description for beacons key</string>
	</dict>

If temporary allowed, precise location can be used until the user closes the app.

You can also explicitly set the default accuracy through the NSLocationDefaultAccuracyReduced key.

Data collection description

App Store will require each app to describe what user's data it collects and how it uses that information. The App Privacy information should also contain a description of data collection from third-party code including advertising or analytics SDKs.

More information can be found in the User Privacy page.

Apple has not disclosed more information on this yet and the time frame stated so far is later this year.
We will be monitoring for more information and update this article accordingly.