Apple's three paperwork blockers

Three pieces of App Store paperwork will stop a release cold: the privacy manifest, the App Privacy label, and the age-rating questionnaire that has blocked updates since January. What each one is, and which parts nobody can fill in for you.

September 2, 2026 · 8 min read

Need a Mac for this? NoMac gives your agent full macOS with Xcode for $0.80 an hour, billed by the minute. Start now →

Most first submissions are not rejected on the idea. They are stopped by paperwork — three artefacts in particular, each of which blocks a release completely, and none of which are mentioned anywhere in the code you wrote. Two can be largely generated. The third cannot, for a reason worth understanding.

1. The privacy manifest

A PrivacyInfo.xcprivacy file inside your app bundle, required since 1 May 2024. A missing or incorrect one is an automated rejection at upload — no human, no queue, just an email.

It declares two things:

• ·Required-reason API usage. Apple designated a set of APIs that are commonly abused for fingerprinting — file timestamps, UserDefaults, system boot time, available disk space — and you must declare a reason code for each one you call.
• ·Data collection and tracking. What your app collects, and whether it is linked to identity or used for tracking.

The trap is third-party SDKs. Any commonly-used SDK must ship its own manifest and a signature, and your app's effective privacy report is the union of yours and theirs. An analytics library three versions out of date can fail your upload while your own code is clean.

<!-- the shape of it -->
<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array><string>CA92.1</string></array>
  </dict>
</array>

This one is mechanical, which means it is automatable: scan the code for required-reason API calls and bundled SDKs, write the manifest, then archive the app and check that every framework inside it carries its own PrivacyInfo.xcprivacy. An agent with a Mac can do all of that before the upload rather than after the rejection email.

2. The App Privacy label

The “nutrition label” on your store listing. Different from the manifest, confusingly adjacent to it: the manifest is a file in the binary, the label is a questionnaire in App Store Connect, and they must agree.

A tool can infer a good draft — the SDKs you bundle and the entitlements you request say a lot about what you collect. What a tool cannot do is attest. This is a legal statement about your data practices, made by you, and Apple treats a false one as grounds for removal. Anyone offering to fill it in automatically is offering to lie on your behalf.

3. The age-rating questionnaire

The one that surprises people in 2026. Apple replaced the age-rating questionnaire and made answering it mandatory from 31 January 2026. Until it is answered, App Store Connect blocks all updates — not just new apps. Existing apps that had a rating under the old scheme still need the new answers.

It now asks about in-app controls, capabilities, medical and wellness content, and violence in more detail than before. It takes ten minutes if you know it exists, and it costs a release cycle if you discover it while trying to ship a hotfix.

The fourth one, if you sell in the EU

Trader status under the Digital Services Act. Apple asks for a trader declaration on new submissions, and verified trader contact details are required to distribute — or keep updating — an app in the EU. If your app is available in the EU and you have not declared, that is a hard stop at exactly the wrong moment.

Why this list keeps growing

Every item here exists because a regulator or a platform decided a claim needed an owner: privacy declarations, age suitability, trader identity. That trend is not reversing, and the mechanical burden lands hardest on solo developers who do not have someone reading policy email.

The split that holds up:

• ·Generate what is derivable. Privacy manifest, permission usage strings, icon and launch assets. All facts about the binary.
• ·Pre-fill what is inferable. Privacy label, content rating — draft it, show the evidence, ask.
• ·Never fake an attestation. Export compliance, age rating, trader status, data practices. The human signs.

A pre-submission check that runs the first two and stops at the third is the difference between a release and a rejection round-trip. On NoMac, publish without confirm stages the version and returns Apple's own list of blockers without submitting, so missing paperwork shows up before review, not as a rejection after it.

Apple's current requirements live at the privacy manifest documentation. Dates and question sets change; check the source.