NoMacSign in
← Blog

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.

· 8 min read


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 binary for required-reason API usage and bundled SDKs, generate the manifest, diff it against what Xcode's own privacy report produces. NoMac does this before 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.

The honest split: pre-fill from evidence, then a human confirms. That is the most anyone should automate here, and it is what NoMac does — a draft with the reasoning attached, and one click that is yours to click.

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, export compliance, 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. Age rating, trader status, data practices. The human signs.

A pre-submission check that runs the first two and blocks on the third is the difference between a release and a rejection round-trip. The Android equivalents — Data Safety form, content rating, target API 36 — work the same way and are covered in the Google deadline post.

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

Ship it without a Mac.

Signed builds, TestFlight and App Store submission — driven by your agent.

Start shipping