App Store Compliance

Preparing your PrivacyInfo.xcprivacy for iOS 27

An evergreen pre-WWDC checklist for iOS 27 privacy manifest readiness — auditing existing reason codes, vendoring third-party SDK manifests, and the process you'll need in place to ship a new required-reason category within a week of Apple announcing it.

By · · 7 min read

Apple has added new Required Reason API categories at every WWDC since 2024. WWDC 26 (June 8, 2026) is the next scheduled add. The teams that handle Apple’s privacy-manifest evolution well aren’t the ones who hear the announcement faster — they’re the ones who already have a clean baseline and a process for updating in a week.

This post is the two-week pre-WWDC readiness checklist. None of it depends on what Apple announces. All of it makes your apps faster to update whatever Apple announces.

For the line-by-line spec of the current required-reason categories, see the complete Required Reason API reference. For how Apple’s compliance surface has evolved year over year, see what WWDC 26 could change for iOS app web requirements.

A 60-second recap of where things stand

  • The privacy manifest is a property-list file named PrivacyInfo.xcprivacy that must be bundled in your app and in any third-party SDK using a Required Reason API.
  • Apple started enforcing manifests on May 1, 2024 (Apple announcement). New apps and updates without a manifest fail upload with ITMS-91053 (resolution guide).
  • Apple has added Required Reason API categories every WWDC since the 2023 preview. The category list is not closed.

If you submitted an app in the last 18 months, your manifest is probably mostly current. “Probably mostly” is exactly what you don’t want carrying you into WWDC week.

The pre-WWDC audit (do this in the next two weeks)

1. Verify your PrivacyInfo.xcprivacy actually shipped

The file has to be in the app bundle, not just in your repo. After your last archive, open the .ipa or check Xcode’s Show Build Folder in Finder → Products and confirm PrivacyInfo.xcprivacy is present at the bundle root. If you use SPM or CocoaPods, check that each privacy-impacting dependency shipped its own manifest inside its framework. Apple’s enforcement is per-bundle — a missing dependency-side manifest fails the upload even if your app’s is correct.

2. Cross-reference every Required Reason API your code calls

Walk through every API in Apple’s required-reason list:

  • NSPrivacyAccessedAPICategoryUserDefaults
  • NSPrivacyAccessedAPICategoryFileTimestamp
  • NSPrivacyAccessedAPICategorySystemBootTime
  • NSPrivacyAccessedAPICategoryDiskSpace
  • NSPrivacyAccessedAPICategoryActiveKeyboards

For each, search your codebase (and your dependencies) for the API calls in that category. If you find a call but your manifest doesn’t declare it, you have a gap today, before WWDC 26 adds anything new. The full mapping of reason codes to use-cases is in the Required Reason API reference.

3. Confirm your third-party SDKs are current

Apple’s separate enforcement from February 12, 2025 requires that any privacy-impacting SDK ship a manifest. If an SDK you depend on hasn’t updated, your upload fails. Check each SDK’s release notes for “privacy manifest” or “PrivacyInfo.xcprivacy” mentions, and update to the latest version that ships one. If a small SDK hasn’t shipped a manifest by WWDC 26, treat that as a risk and find a replacement or fork.

4. Reconcile manifest ↔ nutrition labels ↔ privacy policy

These three must tell the same story. A manifest that declares analytics data collection while your App Privacy nutrition labels say “Data Not Collected” gets caught by App Review. Same for a privacy policy that doesn’t disclose what the manifest declares. The trap is usually a vendored analytics SDK collecting data your own code doesn’t touch — covered in the “we noticed your app collects data” email decoded.

5. Document your process for adding a new category

The single highest-leverage prep: write down — actually write down — the steps for adding a new Required Reason API category to your apps. Something like:

  1. Add the new NSPrivacyAccessedAPICategory* block to PrivacyInfo.xcprivacy
  2. Update the corresponding entry in App Store Connect’s App Privacy questionnaire
  3. Add a paragraph to the hosted privacy policy disclosing the new collection (if applicable)
  4. Update internal documentation / changelog
  5. Submit a no-binary App Store Connect metadata update or a fresh build, depending on the change

If you don’t have this written down, when Apple announces the new category at the State of the Union on June 8 you’ll be debugging the process instead of executing it.

What WWDC 26 is likely to add (and what it means for you)

Per Apple’s four-year cadence (WWDC 26 prediction post):

  • At least one new NSPrivacyAccessedAPICategory. Most likely tied to an Apple Intelligence or on-device-inference API.
  • At least one new “data type” or “purpose” category in App Privacy / nutrition labels — also likely tied to generative or inference data.
  • Lower probability: a new key in the top-level PrivacyInfo.xcprivacy schema. Schema additions are rarer than category additions but have happened (NSPrivacyTrackingDomains arrived this way).

The pattern is consistent enough that you can prepare the shape of your response even without the specifics:

  • A new category → add a block to the manifest, update App Privacy, update the privacy policy.
  • A new top-level key → add the key to the manifest, possibly add a hosted file (if it’s URL-based), update the privacy policy.
  • A new App Store Connect URL field → add the URL, ensure it serves 200 with the correct content.

All three are absorbable in a day if your manifest is clean going in. They turn into a week if it isn’t.

Where OrbitKit fits

OrbitKit hosts the privacy policy, the data-deletion page, the support page, and the well-known files Apple validates against. When WWDC 26 adds a category, we update the manifest scaffold and policy templates within 48 hours — and subscribers’ apps stay aligned without code changes on their side. The OrbitKit CLI regenerates a fresh manifest scaffold from your current data-collection answers in a single command; pair it with our MCP server and your AI tools can update the manifest from a single prompt.

The point isn’t that OrbitKit eliminates the work. It’s that the work happens at our layer, not yours, and your code ships unchanged when Apple’s requirements change underneath it.

The two-week timeline, condensed

  • Days 1-7 (now → May 31): Audit (#1-#4 above). Find every gap that already exists today.
  • Days 8-13 (June 1 → June 7): Close the gaps. Update SDKs. Write the process doc.
  • Day 14 (June 8, keynote day): Watch the State of the Union. When the new category drops, execute the process you already wrote.

Teams that walk in with a clean baseline ship the WWDC 26 manifest update by Tuesday afternoon. Teams that don’t are still debugging the Friday after. The work is the same either way — only the order changes.