Apple’s SDK requirements: What each of the 86 privacy manifest requiring SDKs does

Apple just unveiled a list of 86 SDKs that will require privacy manifests starting in the spring of 2024. The SDKs cover a wide range of functionality, including networking, authentication, database management, UI development, and more. There’s a lot of Facebook and Google SDKs here, including at least 12 for Firebase alone and many for Flutter, Google’s open source cross-platform development package. The list includes a significant number of Meta SDKs as well, including one for AEM, Meta’s Aggregated Event Management that limits privacy-sensitive data transmission while enabling conversion and engagement measurement.

Organizations or maintainers with the most SDKs on the list:

• Google: 24
• Flutter community: 19
• Meta: 7
• OneSignal: 4

Some of the common capabilities of the SDKs on the privacy manifest list:

• Video and image tasks: 10
• Data management, storage, parsing: 9
• Network and networking tasks: 5
• Notifications: 5
• User login/authentication: 4
• Web views in apps: 3
• Sharing library: 3
• Encryption: 2

Here’s a list with all 86 iOS app development SDKs and libraries, along with brief overviews of what they do, and the companies, organizations, or maintainers behind each. More on what’s NOT on the list below …

All 86 privacy manifest requiring SDKs

(Note: this was partially created by ChatGPT. I’ve double-checked it and updated some data where there have been recent changes or there is confusion, but can’t guarantee it’s 100% accurate in all cases.)

Important note about Apple’s privacy manifest requiring SDKs

Apple says app developers will need to start including privacy manifests for any SDK listed. But there are some conditions on that requirement:

1. When you submit a new app
2. When you submit an app update that “adds one of the listed SDKs as part of the update”

I’ve added the emphasis on the “adds” above, because based on the plain language of Apple’s notification, you will not need to declare privacy manifests for these SDKs if you’re updating an old app that already includes one of these SDKs. In other words, there’s some grandfathering going on.

Of course, I’m not a lawyer: check with yours to be certain of your obligations.

Why these SDKs and not others?

Of course, we don’t know Apple’s motivation here, but we can speculate why Apple chose these SDKs and not others.

One reason might simply be scale. Any SDK with hundreds of thousands or millions of installs or inclusions in apps represents a broad risk if misused, so simple scale might be a factor here. 

Another is a focus on what they do. Any SDKs that offer remote configuration could change app behavior after its App Store submission and Apple’s review, which obviously adds risk. Any SDKs that are used for networking or user ID/authentication have potential for misuse as well, as does any SDK that gets and provides data on device-level hardware, software, or identifier information. We’ve just learned how governments have been using push notifications to surveil end users, so presumably companies or organizations could do the same, and that’s likely why we see some push notification SDKs on the list.

We don’t see MMP SDKs here, suggesting that Apple sees its own SKAdNetwork as a privacy-safe form of marketing measurement and marketing measurement companies that use it as allies in privacy. Given that all the significant players in the mobile measurement space have detailed obligations with the big self-attributing networks, this seems a safe call. Also, depending on what data each individual MMP’s SDK access, if an MMP wants any data from Apple’s other privacy list of required reason APIs, that will force the MMP’s reason to be declared in privacy manifests anyways.

Big picture: it’s a tough job to find all the potentially infringing SDKs, since pretty much any SDK that can run networking and collect data is a potential risk. Ultimately, we might see Apple adopt something like Google’s SDK Sandbox in Privacy Sandbox on Android, which will place SDKs in a specific environment that limits their access to extracurricular data.

More to come?

There is of course the possibility that there are more SDKs to come. Nothing is static in technology, especially in mobile, and as additional SDKs are created, Apple will want to monitor them. It’s worth noting that Apple is guarding against people simply renaming or repackaging SDKs to sidestep the requirements:

“Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included in the requirement,” Apple states.

In other words, you can’t weasel around the requirement.