Privacy

How do I fix ITMS-91053 for the UserDefaults API?

You uploaded a build to App Store Connect, the processing email landed within minutes, and the body referenced ITMS-91053 with NSPrivacyAccessedAPICategoryUserDefaults flagged. The app archives in Xcode, the previous TestFlight build was fine, but today the upload is held with the status Invalid Binary. The question is what that one line in the email is really pointing at, which call inside the binary is responsible, and the smallest plist change that lets the next upload process cleanly.

Short answer

App Store Connect rejects builds that read or write user defaults without declaring those calls in a PrivacyInfo.xcprivacy file. The fix is a privacy manifest entry with NSPrivacyAccessedAPICategoryUserDefaults paired with an approved reason code: CA92.1 for defaults used only within the app, 1C8F.1 for defaults shared across an App Group, or C56D.1 for third-party SDKs that wrap the UserDefaults API behind a function the host app calls. Apple has enforced this rule for new submissions since 1 May 2024, per the Apple Developer privacy manifest documentation.

What you should know

• ITMS-91053 is a privacy manifest error, not a code-signing or entitlement error. App Store Connect scans the binary for symbols associated with required reason APIs and refuses to process the build when no matching manifest entry is present.
• NSPrivacyAccessedAPICategoryUserDefaults is one of four required reason API categories. The others are file timestamp, disk space, and system boot time. User defaults is the category most often raised on apps that store settings or feature flags.
• Apple publishes exactly three approved reason codes for this category. CA92.1, 1C8F.1, and C56D.1. Picking the wrong one is rare; picking none is the usual error.
• The manifest belongs to whichever target calls the API. If the app code reads UserDefaults.standard, the app target carries the entry. If a vendor framework reads a preference at startup, that framework needs its own manifest.
• The rule started as a warning in March 2024 and became a hard block on 1 May 2024. Before the cutover, builds without manifests still uploaded and the email was informational. Today the binary is held in App Store Connect and a new build is required.
• A correct manifest is roughly twelve lines of plist and adds no runtime behaviour. It is metadata read during ingestion and surfaced in the Privacy Nutrition Label on the App Store listing.

Why does App Store Connect return ITMS-91053 for UserDefaults?

The short answer is that Apple now scans every uploaded binary for symbols associated with a defined set of required reason APIs, and it refuses to process a build that references one of those symbols without a matching declaration in a privacy manifest. The user defaults group covers the NSUserDefaults class in Objective-C, the Swift UserDefaults wrapper, the +standardUserDefaults singleton, and any per-suite initializer like initWithSuiteName.

The scan does not read your Swift or Objective-C source. It reads the compiled Mach-O. A project that builds and runs cleanly can still fail on upload because a linked framework reads a preference at startup and the symbol survived stripping. Apple's TN3183 technote describes the rule as an audit of API usage, not a behavioural check, which is why the diagnostic appears during ingestion rather than at runtime.

Which reason code should I pick for user defaults?

Apple publishes three approved reasons under NSPrivacyAccessedAPICategoryUserDefaults. Each one matches a different real-world usage pattern, and a single manifest entry can list more than one when the app legitimately spans cases.

The most common reason is CA92.1. It covers reading and writing user defaults that are accessible only to the app itself. A login flag stored under UserDefaults.standard, a feature toggle behind a key like has_seen_onboarding, or a saved theme preference all sit here.

1C8F.1 covers user defaults shared inside an App Group. When the iOS app and a widget, watch extension, or App Clip read the same NSUserDefaults instance through an initializer like initWithSuiteName('group.com.example.shared'), this is the correct code. Apple's Describing use of required reason API page lists this as the distinguishing case for cross-process access.

C56D.1 is restricted to third-party SDKs that wrap the user defaults API behind a function the host app calls. The SDK ships this declaration in its own manifest, and the derived information cannot be used for the SDK's own purposes. An app developer does not use C56D.1 for first-party code.

Cases reported by developers show that submitting CA92.1 when 1C8F.1 would have been more accurate does not block the upload. App Store Connect does not police the alignment between the description and the call at ingestion. The audit only checks that one approved reason is present for the category. Picking the reason that genuinely matches the call is still the safer practice, because a later human review pass can ask about it.

How do I add the entry to PrivacyInfo.xcprivacy?

The file goes into the bundle of the target that calls the API. For a plain iOS app with no embedded frameworks, that is the app target, and PrivacyInfo.xcprivacy sits at the root of the .app folder. Add it via File, New, File from Template, App Privacy under the Resource section. Xcode generates an empty plist and registers it with the current target.

The one step developers miss is target membership. Open the File Inspector on the new manifest, scroll to Target Membership, and confirm the app target box is ticked. A manifest in the project navigator but outside target membership never reaches the .app bundle, and ITMS-91053 returns on the next upload.

The smallest valid entry for a user-defaults-only fix is one dictionary inside the NSPrivacyAccessedAPITypes array, with NSPrivacyAccessedAPIType set to NSPrivacyAccessedAPICategoryUserDefaults and NSPrivacyAccessedAPITypeReasons set to an array containing one or more reason strings.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>CA92.1</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

If the same target also reads disk space, file timestamps, or system boot time, those go in as sibling dictionaries inside the same NSPrivacyAccessedAPITypes array. After editing the plist, archive the project, right-click the .ipa in Finder and Show Package Contents, and confirm PrivacyInfo.xcprivacy sits at the top level of the .app folder before the next upload.

How do I find which framework calls UserDefaults?

A build that compiles fine but fails on upload usually carries the call inside a CocoaPods, Swift Package Manager, or vendored .xcframework dependency. There are three reliable paths to identify the responsible SDK.

The second is the SDK's own changelog. Most major vendors began shipping privacy manifests in spring 2024. Firebase, Google Mobile Ads, AppsFlyer, Adjust, Sentry, Branch, and Lottie all published manifest-bearing releases by mid-2024. The Firebase team tracked the rollout publicly in issue 12557 on the firebase-ios-sdk repository. If the Podfile or Package.resolved is pinned to a pre-April 2024 version, bumping to a current release usually clears the rejection without manual plist work.

The third is process of elimination. Comment out a suspect SDK initialization, archive, and upload to a separate test app record. If the rejection disappears, that SDK is the source. The approach is slow but useful for closed-source dependencies without a public changelog.

Which UserDefaults APIs trigger the scan?

The table below collects the most common entry points that App Store Connect's scanner flags under NSPrivacyAccessedAPICategoryUserDefaults, based on Apple's published reason API list.

Apple groups every entry above under a single category, so one reason code on a single dictionary entry covers any combination of these calls. There is no separate code per symbol.

What to watch out for

• A manifest in the wrong target. Adding PrivacyInfo.xcprivacy to the project but leaving the app target unchecked produces a build with no manifest in the .app bundle. App Store Connect sees nothing and continues to reject. Verify by unzipping the .ipa.
• A vendor SDK that ships its own manifest, but a stale version. Vendors sometimes correct an incomplete reason list in a later release. A locked Podfile may still ship the older, incomplete manifest from the framework, and ITMS-91053 returns.
• Reusing the same build number. App Store Connect deduplicates by version plus build number. After fixing the manifest, increment CFBundleVersion before uploading. Otherwise Transporter may succeed at the network layer while the binary is silently ignored.
• Confusing this rule with App Tracking Transparency. ATT and the privacy manifest are separate systems. An app can have a clean ATT setup and still fail ITMS-91053. They share the word privacy and nothing else.
• Treating the privacy manifest as a substitute for a security review. The manifest is a disclosure of API usage. It does not check whether secrets are hardcoded in the binary, whether SDK initializers leak API keys at first launch, or whether storage paths sit unencrypted on disk. Those checks live in a separate pass against OWASP MASVS. For builders who want an external read of the compiled IPA before submission, PTKD.com (https://ptkd.com) is one platform focused specifically on pre-submission scanning of iOS and Android binaries for OWASP MASVS controls.

Key takeaways

• ITMS-91053 with NSPrivacyAccessedAPICategoryUserDefaults is a missing privacy manifest entry, not a code defect. Add the PrivacyInfo.xcprivacy file with the right reason code and the upload will process.
• Pick the reason code that matches the real call: CA92.1 for app-only defaults, 1C8F.1 for App Group sharing, C56D.1 only for third-party SDK wrappers.
• Confirm the file is in the right target and actually shipped inside the .app bundle. The most common repeat-rejection cause is a manifest outside target membership.
• If first-party code does not read user defaults, look at third-party SDKs. Bump them to a release dated after April 2024, when most major vendors began shipping their own manifests, before writing manual plist entries.
• Increment the build number after every fix. App Store Connect deduplicates by version plus build, and reusing the same value can hide a corrected build behind the previous rejected one.
• The privacy manifest is a disclosure, not an audit. For developers who want an independent read of the compiled binary against OWASP MASVS before submission, platforms like PTKD.com (https://ptkd.com) run that check on the IPA itself and flag manifest gaps along with secret storage and network issues.

• #itms-91053
• #privacy manifest
• #ios
• #app store connect
• #userdefaults
• #required reason api