Look, I've seen a lot of experienced devs get blindsided by this lately. There's a very common assumption that goes something like this: "My app doesn't track the user, I don't have an analytics SDK, and I'm not uploading any personal data to a server, so I can completely ignore the Privacy Manifest requirements."

That is a dangerous assumption. If you're relying on that logic, you're likely going to get a warning email from App Store Connect—or worse, a rejection—the moment you submit your next build.

"I don't collect data, so I don't need a manifest"

The mistake here is thinking that the Privacy Manifest is only about data collection (the stuff you see in the "App Privacy" nutrition labels on the App Store). While that is a part of it, the manifest is also about API usage.

Apple has identified a set of "Required Reason APIs." These are common APIs that could potentially be used for "fingerprinting" a device to track a user across different apps and websites. The kicker? Many of these are things you use every single day. For example, if you use UserDefaults to save a simple boolean like hasSeenOnboarding, you are using a Required Reason API. It doesn't matter that you aren't "collecting" that data for a marketing firm; the mere act of accessing the user's defaults requires a declared reason in your manifest.

API usage is a separate obligation from data collection

To handle this, you need a PrivacyInfo.xcprivacy file in your project. This is essentially a property list (plist) where you explicitly tell Apple why you're using specific system APIs. I usually recommend adding this file the moment you start a project, just so you don't forget about it during the frantic hours before a release.

The manifest is split into a few key sections. The most critical one for most of us is NSPrivacyAccessedAPITypes. When you add an entry here, you have to provide the API type and a "Reason Code."

<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string> 
        </array>
    </dict>
</array>

In the example above, CA92.1 is the official code for "Accessing user defaults to store app preferences." You can't just make up a sentence; you have to use the specific codes Apple provides in their documentation. It's a bit tedious, but it's the only way to satisfy the automated checks.

If you're building a framework or an SDK that other people use, this is even more critical. Apple now requires SDKs to provide their own privacy manifests. If your SDK uses systemBootTime to measure performance but doesn't declare it, the app developer using your SDK will get the warning, and they'll be knocking on your door asking why your library is breaking their App Store submission.

Just remember: the manifest isn't a "privacy policy" for humans; it's a technical declaration for Apple's auditors. If you use UserDefaults, fileModificationDate, or systemBootTime, you're on the hook for a declaration, regardless of how "innocent" your use case is.

📋 Practical Task

Declaring UserDefaults Usage in a Privacy Manifest

Imagine you are maintaining a small utility app that uses UserDefaults to remember the user's preferred theme (Light vs. Dark). You've just realized you don't have a Privacy Manifest, and you want to avoid any App Store Connect warnings.

Your Goal: Create a PrivacyInfo.xcprivacy file (represented as an XML property list) that correctly declares the use of UserDefaults for the purpose of storing app preferences.

Requirements:

• The root element must be a dictionary.
• You must include the key NSPrivacyAccessedAPITypes.
• Within that array, create a dictionary specifying the category NSPrivacyAccessedAPICategoryUserDefaults.
• Assign the correct reason code CA92.1 to the NSPrivacyAccessedAPITypeReasons array.