WWDC23 (a.k.a., the annual “let’s all rewrite our roadmap week” for mobile) is over! And yes, Vision Pro seems really cool. No company in the world is better than Apple at product marketing.
But, back here in real life, there’s another important takeaway: as usual, WWDC also brought its annual collection of user privacy improvements. Apple clearly doesn’t want privacy headlines getting in the way of VR goggles, so these updates didn’t even earn a mention in the keynote. Don’t let that fool you, because they are still a pretty big deal.
Here’s the theme: Apple made no privacy policy changes this year, but they have come up with an array of new things that are designed to help developers more easily comply with the policies already in place…and prevent compliance “mistakes” (whether accidental or otherwise).
In other words, if you’ve already embraced the new world of privacy-centric measurement (for example, if you work with Branch), the next few months should be relatively straightforward for you (and — as always — our team will be here every step of the way to guide you through the process).
On the other hand, if you’ve been investing in workarounds for the last two years, your life just got waaaaay harder. It’s absolutely clear what Apple wants now. Perhaps there is still wiggle room to get away with ignoring the policies after this year’s changes, but the stakes are rising and the rewards are shrinking. The Privacy Engineering team at Apple operates on a timeframe of years, and they’re not giving up.
In this post, I’m going to share a summary of what we have learned so far. This is based on information from Apple’s public WWDC developer session videos, updated iOS documentation pages, and follow-up Q&A sessions with the Apple Privacy Engineering team.
First, a quick recap. The App Tracking Transparency (ATT) framework, which Apple introduced at WWDC in 2020, essentially does four things:
- It defines “tracking” as activity related to advertising and data brokers.*
- It gates IDFA access.
- It contains policy limitations against other forms of cross-company “tracking” (i.e., hashed email addresses) without user consent.
- It reiterates that policy prohibitions against fingerprinting (which have always been in the Apple Developer License Agreement) continue to apply, separate from restrictions on “tracking” and regardless of user consent.
* As defined on this page: “Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.”
The improvements this year seem designed to ensure that 3 and 4 are no longer just policy.
What’s new in privacy on the App Store this year?
Here are the main components of what Apple announced this week:
- Privacy Manifests. Standardized files that outline the privacy practices of an app or third-party framework (SDK).
- Privacy Report. An auto-generated reference doc, based on the details contained in all relevant Privacy Manifest files, designed to make it easier to fill out the Privacy Nutrition Label questionnaire during App Store submission.
- SDK Signing. A way for app developers to be confident that the third-party SDKs they use (such as Branch) are the original, validated versions and have not been tampered with.
- Privacy-impacting SDKs. A list of SDKs that Apple judges to have particularly high impact on user privacy. Any SDK on this list will be required to include a Privacy Manifest file, and be signed by the original developer (these steps are also recommended but not required for SDKs that are not on the list).
- Required Reason APIs. A limited selection of iOS functionality that could potentially be used for fingerprinting, for which an “allowed reason” for usage must be declared in the Privacy Manifest file. (Note that “API” in this context means things like accessing disk space, not service APIs the way we typically think of them in the world of mobile marketing).
- Tracking Domains. Internet domains that an app or SDK connects to that engage in “tracking.” These must be declared in the Privacy Manifest file, and network requests to these domains will fail until the user gives ATT consent.
- Domain Profiler in Instruments. Tooling in Xcode that developers can use to compare an app’s network requests against a list of internet domains the OS believes to be capable of “profiling” across multiple apps and websites.
- Link Tracking Protection and Safari Private Browsing Improvements. New functionality in Messages, Mail, and Safari Private Browsing to strip URL query parameters used to track users across websites, and block various other forms of cross-site tracking.
- SKAdNetwork 5.0. The new version will support re-engagement attribution (app opens), and is coming “later this year.” That is literally all we know so far.
We’ll go through each of these in more detail.
Privacy Manifests
The Privacy Manifest file is a centralized place to set privacy-related configuration items. An app can have one, and SDKs can also each have their own (for SDKs on the privacy-impacting list, this will be required).
There are four sub-sections in a Privacy Manifest file:
- NSPrivacyTracking. This is a Boolean that indicates whether an app or third-party SDK uses data for “tracking,” as defined under the ATT framework. While not officially confirmed, we suspect setting true for this value will trigger Apple to look for the ATT consent modal in the app during App Store Review.
- NSPrivacyTrackingDomains. An array of strings that lists the internet domains an app or third-party SDK connects to that engage in “tracking” (see Tracking Domains section below). If the user has not granted tracking permission through the ATT framework, network requests to these domains fail.
- NSPrivacyCollectedDataTypes. An array of dictionaries that describes the data types an app or third-party SDK collects. Xcode will use these values to generate a report (see Privacy Report section below) for easy reference when answering the Privacy Nutrition Labels questionnaire on App Store Connect.
- NSPrivacyAccessedAPITypes. An array of dictionaries that describe the iOS APIs an app or third-party SDK accesses that have been designated as APIs that require reasons to access (see Restricted APIs section below).
These files are created in Xcode, and look like this:
Source: Apple, Get started with privacy manifests
Privacy Report
The Privacy Report is a PDF generated in Xcode, based on the values reported in the Privacy Manifest files for the app and any included SDKs. These are the same values (data types and uses) that have existed in Privacy Nutrition Labels for several years, so this isn’t technically new. However, collecting this information for the app and any included SDKs has always been a bit of a pain.
Source: Apple, Get started with privacy manifests
Having a centralized reference report should simplify the process of answering the Privacy Nutrition Labels questionnaire on App Store Connect. But it’s important to know this won’t be a full solution: in follow-up Q&A this week, Apple has suggested that SDKs are expected to disclose everything that might be collected, and then provide additional guidance (outside of the Privacy Report) for developers to consider when determining what the final Nutrition Label questionnaire answers should be, depending on what SDK functionality the app developer has actually implemented.
SDK Signing
Xcode now checks to confirm that app dependencies (i.e., third-party SDKs from partners like Branch) come with a valid code signature. For SDKs on the privacy-impacting list, Apple will require the SDK to be signed by the original developer.
The security of the software supply chain is rarely an issue with reputable SDK partners (especially those that follow open-source best practices), but this change likely has an additional objective: requiring privacy-impacting SDKs to be signed by their original developers will drive accountability, and make it far more difficult to surreptitiously modify SDKs in order to bypass other privacy protections.
Privacy-impacting SDKs
This is a new list (not expected until later this year) of third-party SDKs that Apple considers to have particularly high impact on user privacy. SDKs on this list must include a Privacy Manifest file, and a code signature from the original SDK developer.
Some might consider inclusion on this list to be a significantly negative thing. But in reality, being included will simply require SDK developers to implement best practices that any reputable software vendor should be following anyway.
Apple has also confirmed in follow-up Q&A that this list will be available well in advance of any enforcement actions.
Required Reason APIs
Apple has identified “a small number” of platform APIs that enable valuable functionality, but also have a high potential for misuse (i.e., a liability for fingerprinting). While the actual list is not expected until later this year, Apple specifically clarifies that most apps likely use one or more of them.
Apps and SDKs that require these APIs will need to specify an approved reason for access. For example, one of the approved reasons for calling NSFileSystemFreeSize (which indicates the amount of free space on the file system) will be checking whether there is sufficient disk space before writing files to disk. Reasons will be specified through the Privacy Manifest file, and Apple will provide a feedback form to suggest new reasons for calling covered APIs.
Tracking Domains
We’ll let Apple’s highly-diplomatic language stand on its own:
“In cases when a user has not provided tracking permission, iOS 17 automatically blocks connections to tracking domains that have been specified in any privacy manifest included in your app. […] By preventing accidental connections, this feature helps to preserve your intention to not track users without their permission.”
In other words, ATT compliance is no longer just on the honor system. Yes, an unscrupulous actor could technically try to evade including all their tracking domains, or even set up a first-party proxy relay to do server-to-server fingerprinting, but Apple already knows how to detect that on the web. Who really wants to keep fighting an annual insurgency against an omnipotent adversary, whose desired outcome seems to be backed by both public opinion and regulatory momentum?
From a technical perspective, Apple specifically recommends separating traffic types into different domains, such as tracking.example.com and non-tracking.example.com. Apple also clarified in follow-up Q&A that user-initiated activities (for example, tapping on a link) will not be blocked, even if the link is on a tracking domain.
Domain Profiler in Instruments
To help detect unexpected tracking domains, Apple is giving developers new tooling to analyze their app’s network traffic. It lives in Xcode, and looks like this:
Source: Apple, Detecting when your app contacts domains that may be profiling users
Note the alert in the corner of the image: “Fault: www.example.com is not listed in your app’s NSPrivacyTrackingDomain key in any privacy manifest. It may be following users across multiple apps and websites to create a profile about users of apps that contact this domain”
In follow-up Q&A, Apple confirmed that this list of domains will be consistent for an OS version both on device and the simulator, suggesting that domains are not being classified locally on the device (unlike Intelligent Tracking Prevention in Safari).
It appears the output of this tool will be for informational purposes only, as Apple has also indicated in follow-up Q&A that it is not expected that every domain flagged in this tool is necessarily a “tracking domain” — rather, it’s simply a list of domains that the OS considers to be technically capable of tracking.
However, the documentation page states: “If you determine that the domains your app connects to are using data sent from your app to track people, declare them in your privacy manifest and ask for permission to track under the App Tracking Transparency framework.” It’s reasonable to expect that App Store Review will also have access to this data, and may ask pointed questions if they suspect a discrepancy.
Link Tracking Protection and Safari Private Browsing Improvements
Websites often use URL parameters for measurement and cross-domain tracking. iOS 17 will remove “known tracking query parameters”from links that users share in Messages and Mail, and Safari’s Private Browsing mode will get the same query parameter functionality, along with a number of additional upgrades to block web-based fingerprinting and other cross-site tracking techniques.
In the video describing these changes, Apple recommended Private Click Measurement (PCM) to replace URL parameters for web ad attribution, and we’ve already seen claims that this is “the end of UTM tracking.” That’s probably overblown at this stage, given the changes only apply to the Private Browsing mode of Safari and shared links in Messages and Mail, but it’s not difficult to see where the current trend eventually leads.
SKAdNetwork 5.0
We know SKAdNetwork (SKAN) 5.0 is coming, because Apple mentioned it for about 18 seconds. SKAN 5 will support attribution for app opens (not just installs), which was one of Branch’s wishlist items and counts as an incremental improvement. That’s literally all Apple said about it, so we’ll just have to stay tuned for “later this year.”
In reality, support for app opens may not seem like a huge improvement for two reasons:
- Major networks have already introduced aggregate attribution frameworks (for example, Facebook AEM and Google GBRAID) to solve a similar problem.
- Re-engagement ads often involve a direct deep link into the destination app. While proper policy compliance would still require ATT consent to attribute these conversions, many in the industry have chosen to ignore this restriction and simply pass a click ID through.
However, it’s likely the new Tracking Domain protections in iOS 17 will have at least some impact on both of these approaches, meaning SKAN support is necessary to fill the gap of re-engagement attribution for users who do not provide ATT consent.
What about deferred deep linking and owned/earned attribution?
Apple has taken great pains to emphasize that no policies have changed this year, particularly around what is considered to be “tracking.” In other words, they want to make compliance easier and don’t intend to cause significant disruption for anyone already following the spirit of the existing policies.
However, these are fairly substantial technical changes, and there is the possibility of collateral damage to other, policy-compliant functionality. We don’t currently anticipate any impact on Branch’s ability to continue delivering services like deferred deep linking or owned and earned attribution, but we’ll have more updates as Apple releases additional details.
How does it all work together, what happens next, and who is responsible for what?
That was a lot of detail. What do you actually need to DO?
Here’s a summary of the timeline Apple provided:
- Starting in fall 2023, App Store will check if new and updated apps include a privacy-impacting SDK. If the privacy-impacting SDK does not include a signature and Privacy Manifest, Apple will send an informational email to the app developer. Apple will also send informational emails for apps that access Required Reason APIs without declaring approved reasons.
- Starting in spring 2024, signatures and Privacy Manifests for privacy-impacting SDKs will be expected, and become part of App Review. You’ll need to address any issues before you submit new and updated apps to the App Store.
Your vendor partners (including Branch) will be responsible for most of the heavy lifting with these changes. This involves:
- Providing Privacy Manifests, including disclosing tracker domains and ensuring any uses of covered APIs are for permitted reasons.
- Signing SDKs.
- Updating SDKs and backend infrastructure to avoid any unintended collateral damage, now that Apple has articulated a clear distinction between “tracking” and “non-tracking” network traffic.
As an app developer or marketer, you’ll also be responsible for a few things:
- Confirm your vendor partners are aware of these changes. Apple didn’t mention anything in the keynote this year, and you don’t want to be caught unprepared in a few months.
- Schedule development time for SDK updates. As with most iOS privacy changes, these are inevitable.
- Prepare your own app’s Privacy Manifest. Apple says you don’t need to cover data collected by third-party SDKs, but you’ll still want to disclose everything related to your own functionality.
- Continue to answer the Nutrition Label questionnaire in App Store Connect. This will be simplified in some ways with the new Privacy Report, but will also still require conversations with your privacy and legal teams, and referencing outside resources.
- Use Instruments in Xcode to confirm your tracking domains. There will be false positives in this report, and Apple has indicated that it is not expected every domain flagged in this tool is a “tracking domain” so you’ll likely need to confirm things with your partners.
As always, your Branch team is here for you every step of the way. Don’t hesitate to reach out with any questions!