iOS 17 privacy manifests announced at WWDC 2023: here’s how they work and when they’ll be required

Apple announced new privacy manifests for SDKs as well as apps today at WWDC 2023. It’s a move that will have massive privacy implications as well as massive app developing, publishing, and marketing implications.

I’m going to dive into what they are, how they work, and what they’ll require of app publishers as well as SDK developers.

Long story short:

• Everyone’s going to need to declare what their apps and SDKs do
• With certain particularly sensitive privacy-impacting SDKs, you’ll need to state why you’re using them
• You’ll have to state whether your app uses data for tracking
• Whether or not your app is tracking, you’ll need to select categories of data you are collecting
• Apple will block network requests to tracking domains if users have not granted permission via App Tracking Transparency

There’s a lot of nuance and detail around all of these things, so keep reading for more details and explanation …

New Apple requirements: privacy manifests

Everyone, both app developers and SDK makers, will have to create privacy manifests that Apple will aggregate together at the point of app publishing.

From Apple’s statement on privacy manifests:

“We’re introducing new privacy manifests — files that outline the privacy practices of the third-party code in an app, in a single standard format. When developers prepare to distribute their app, Xcode will combine the privacy manifests across all the third-party SDKs that a developer is using into a single, easy-to-use report.”

Apple is requiring this from SDK makers because app developers who incorporate third-party SDKs into their apps are likely unaware of all the code and all the uses of those SDKs. Privacy manifests will help app developers understand the implications of including each SDK and provide them information they need to create their app’s specific Privacy Nutrition label.

Everyone must declare reasons for API uses

If you’re using APIs that collect information that might be used for fingerprinting, you’re going to have to declare why you need it.

If you’re a small flashlight utility app that for some reason needs the amount of free disk space … be prepared to get very creative. (By which I mean: good luck. You’re going to lose access to that API at some point during the App Store app submission process, and for good reason.)

Via Apple:

“Apps referencing APIs that could potentially be used for fingerprinting — a practice that is prohibited on the App Store — will now be required to select an allowed reason for usage of the API and declare that usage in the privacy manifest.”

There are many perfectly innocuous reasons for knowing device type, OS version, screen size, or other potentially privacy-threatening pieces of information. Just be sure that you’re using what you say you’re using, and you’re using what you say you’re using in the exact way you say you’re using it.

Apple will name & shame data-hungry SDKs

In order to put some teeth into these new requirements, Apple says it will publish a list of privacy-impacting SDKs at some point in 2023. While the public statement indicates that Apple will name names, behind the scenes it’s not 100% clear that the list will be made up of specific named SDKs or categories of SDKs.

For now, count on the former.

From Apple:

“We’ll publish additional information later this year, including:

• A list of privacy-impacting SDKs (third-party SDKs that have particularly high impact on user privacy)
• A list of “required reason” APIs for which an allowed reason must be declared
• A developer feedback form to suggest new reasons for calling covered APIs
• Additional documentation on the benefits of and details about signatures, privacy manifests, and when they will be required”

The list of required-reason APIs will be very informative, as it will be not only the APIs that Apple thinks are privacy-sensitive in general, but also the ones that Apple believes could be used for fingerprinting purposes. There’s good news if you use a required-reason API but for a purpose that isn’t tracking and isn’t suggested by Apple: you’ll be able to submit feedback on new reasons to add.

New privacy-focused processes are becoming part of the app submission process 

With privacy manifests, there are going to be a few new steps in the App Store submission process.

1. First, you’re going to need to make a privacy manifest

You’ll have to declare whether or not your app — or the third-party SDKs used in it — use data for tracking as defined by the App Tracking Transparency framework. If you are, you’ll have to set NSPrivacyTracking to true.

As a reminder, Apple defines tracking as linking data you collect with other user or device data collected by other companies.

Here’s the definition:

“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.”

Apple provides the following examples of tracking:

• Behavioral targeting of ads
• Sharing location or email with a data broker
• Creating and sharing audiences
• Device graph generation

And Apple provides a few examples of data collection that are not considered tracking:

• Data stays on-device
• Data used only for fraud detection/security
• Data used for credit score

Presumably there are many more types of data collection that are not defined as tracking, as long as you’re not linking data your app or SDKs collect with data from other companies, or selling your data to data brokers.

2. If you are tracking, you’ll have to list the data you are collecting in your privacy manifest

This starts by listing the domains that you’re sending data to via the NSPrivacyTrackingDomains array. That’s simply a list of URLs that your app or your SDKs connect to that aid in tracking.

Here’s an important point:

If you connect to a tracking domain but your users have not granted permission for tracking via App Tracking Transparency, Apple will block any calls to those URLs. Via Apple: “If the user has not granted tracking permission through the App Tracking Transparency framework, network requests to these domains fail and your app receives an error.”

Another important point:

Since you might collect some data that is tracking and some data that is not tracking, ensure that you or your measurement vendor has different endpoints for different purposes. In other words, skan.vendor.com and tracking.vendor.com. Apple will block tracking domains for apps in the same way it blocks tracking in Safari with ITP, Intelligent Tracking Prevention. But this ITP for apps, if you will, is intelligent enough to differentiate between virtual domains.

You’ll also have to list the types of data you are collecting, and you’ll have to do that according to a taxonomy defined by Apple.

3. Whether or not you are tracking as defined under ATT, you’ll have to list this data in privacy manifest

You’re declaring what data your app and any third-party SDKs collect. You’ll also have to list details about that data in your privacy information file using the NSPrivacyCollectedDataTypes array.

Apple will require that you include the following details:

• The type of data you’re collecting
• Whether it’s linked to your users’ identities 
• Whether it’s used to track by app or by SDK 
• And, the reason you collect the data

4. Whether or not you are tracking as defined under ATT, you’ll also have to report the categories of data your app and any third-party SDKs are collecting

That data will fall into any of these Apple-defined categories:

• Contact info
• Health & fitness data
• Financial info (credit card)
  • Note: not when a third party does it: “If your app uses a payment service, the payment information is entered outside your app, and you as the developer never have access to the payment information, it is not collected and does not need to be disclosed.”
• Location data
  • Fine
  • Coarse
• Sensitive information (ethnicity, disability, etc.)
• Contacts
  • Address book
• User content
  • Emails
  • Messages
  • Photos
  • Gameplay content
  • Audio data
• Browsing history
• Search history
• Identifiers
  • User ID (screen name, account ID, customer number)
  • Device ID
• Purchases
• Usage data
  • App engagement
  • Advertising data (what ads user has seen)
• Diagnostics
• Other data … “any other data types not mentioned”
  • I suspect this could be a fairly large catch-all category

5. Whether or not you are tracking as defined under ATT, you’ll have to report the reasons why your app and any third-party SDKs are collecting data

Those reasons could include:

• Third-party advertising
• First-party advertising
• Product personalization
• App functionality
• Any other purposes

6. Finally, you’ll create your privacy report

Or, to be more precise, Xcode will aggregate all of the above data from your app declarations and any privacy manifests in any third-party SDKs that your app references and use it to create your full privacy report.

Privacy manifests FAQ

Apple’s new privacy manifests raise a ton of questions. Here’s what we think we know so far about a few key ones, although this of course is subject to change as we learn more officially from Apple.

1. Does getting IDFV count as tracking?
   Yes
2. If you’re not tracking, but you are using a Required Reason API, do you still have to declare it in your privacy manifest?
   Yes
3. What are the privacy-impacting Required Reason APIs?
   Apple will publish a list later this year.
4. Will SDKs have their own SDK submission process like the app submission process?
   No
5. Are there specific APIs or methods that Apple considers to always impact privacy?
   Apple will provide more information later this year.
6. Should you fill out a privacy manifest for a framework that doesn’t access any data?
   It’s strongly recommended to, yes.
7. Is ATT changing at all in iOS 17?
   No
8. Does marketers’ deeplink management and measurement for their own web links to their own app change under iOS 17 and privacy manifests?
   No
9. Can apps manage how chatty their SDKs are now?
   Essentially yes, because any traffic to defined tracking domains will fail unless users have opted in to tracking via ATT.
10. When will all of this rollout?
    Apple will start sending out informational emails this fall, and enforcement will begin in spring of 2024.

There’s almost certainly more to learn and share, so we’ll keep this updated with any new information we hear or insights we find.