How do I fix ITMS-91053 NSPrivacyDiskSpace in my iOS build?

You uploaded a build to App Store Connect, the processing email landed a few minutes later, and the body referenced ITMS-91053 with NSPrivacyAccessedAPICategoryDiskSpace flagged. The binary compiled, the app runs in the simulator, TestFlight had no complaint on the previous build. The only thing blocking submission today is that one line in the email. The question is what the message actually means, which line of code or vendor SDK is triggering it, and the smallest change that lets the next upload pass.

Short answer

App Store Connect rejects builds that call iOS disk-space APIs without declaring them in a PrivacyInfo.xcprivacy file. The fix is a privacy manifest containing NSPrivacyAccessedAPICategoryDiskSpace paired with the approved reason code E174.1, placed in the app target or in any third-party framework that calls those APIs. Apple has enforced this requirement 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 error. App Store Connect sees a disk-space API call in the binary, finds no matching entry in any PrivacyInfo.xcprivacy file shipped with the build, and rejects the upload during ingestion.
• NSPrivacyAccessedAPICategoryDiskSpace is one of four required reason API categories. The others are file timestamp, system boot time, and user defaults. Disk space is the category most often raised because so many SDKs check free storage before downloading assets.
• The approved reason code for the disk-space category is E174.1. Apple's Describing use of required reason API page lists it as the reason for apps that need free space to perform an operation.
• The manifest belongs to whichever target calls the API. If your code calls volumeAvailableCapacityForImportantUsageKey, your app target needs the entry. If a vendor framework calls statfs, that framework needs its own manifest, not yours.
• The rule started as a warning in March 2024 and became a hard block on 1 May 2024. Per Apple's enforcement schedule, builds without manifests still uploaded before the cutover, with the email recorded as informational. The current state is full rejection.
• A correct manifest is roughly fifteen lines of plist and adds no runtime behavior. It is metadata read by App Store Connect during ingestion and surfaced in the Privacy Nutrition Label on your App Store listing.

Why does App Store Connect return ITMS-91053 for disk space?

The short answer is that Apple now scans every uploaded binary for symbols associated with a set of so-called 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 disk-space group includes NSURL keys like volumeAvailableCapacityKey, volumeAvailableCapacityForImportantUsageKey, volumeAvailableCapacityForOpportunisticUsageKey, and volumeTotalCapacityKey, plus the BSD calls statfs, fstatfs, statvfs, fstatvfs, and the NSFileManager systemFreeSize family.

The scan does not look at your Swift source. It looks at the compiled Mach-O. That is why a project that builds cleanly on a Mac can still fail on upload: the developer never called those APIs directly, but a third-party framework linked into the IPA did, and the symbol survived stripping. Apple's TN3183 technote describes the rule as an audit of API usage, not a behavioral check, which is why the diagnostic message arrives during processing rather than at runtime.

Where exactly does PrivacyInfo.xcprivacy live in an Xcode project?

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 the file sits at the root of the app bundle. Add it via File, New, File from Template, then pick App Privacy from the Resource section. Xcode generates an empty plist named PrivacyInfo.xcprivacy and registers it with the current target.

The single non-obvious step is target membership. Open the File Inspector on the new manifest, scroll to Target Membership, and confirm the app target is ticked. A common cause of repeat ITMS-91053 emails is a manifest that lives in the project navigator but is not actually copied into the .app bundle because the target box was left unchecked. After fixing the membership, archive the project, inspect the .ipa in Finder (right click, Show Package Contents), and confirm PrivacyInfo.xcprivacy sits at the top level of the .app folder before you upload again.

What does the disk-space declaration look like as plist?

The smallest valid manifest for a disk-space-only fix is a single entry inside the NSPrivacyAccessedAPITypes array. The keys are NSPrivacyAccessedAPIType, set to NSPrivacyAccessedAPICategoryDiskSpace, and NSPrivacyAccessedAPITypeReasons, set to an array containing the string E174.1.

<?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>NSPrivacyAccessedAPICategoryDiskSpace</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>E174.1</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

If the app also touches user defaults, file timestamps, or system boot time, those go into the same NSPrivacyAccessedAPITypes array as sibling dictionaries. Apple's privacy manifest files reference lists the codes for each category. Keep the file flat and short. There is no benefit to adding speculative entries for APIs the binary does not actually call, and any code unused by your build can be removed from the manifest later if the audit shows it never linked.

How do I find which third-party SDK triggered ITMS-91053?

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 quick ways to identify the culprit.

The first is to grep the linked frameworks. After archiving, open the .ipa, navigate to Frameworks, and run nm -u on each binary to list undefined and used symbols. A match on statfs, fstatfs, or any volumeAvailableCapacity key narrows the suspect list quickly. Apple's documentation on TN3183 recommends this approach for finding the responsible SDK.

The second is the SDK's own changelog. Major vendors began shipping privacy manifests in early 2024. Firebase, Google Mobile Ads, AppsFlyer, Adjust, Sentry, and Branch all published manifest-bearing releases by April 2024. If your podfile is pinned to an older version, bumping to a release dated after April 2024 usually clears the rejection without any 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, the SDK is responsible. This is slow but useful for closed-source dependencies that lack a public changelog.

Which APIs sit inside the disk-space required-reason category?

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

Apple groups all of these under a single category in the manifest, so one E174.1 reason code covers any combination of them. There is no separate code per symbol.

What to watch out for

• A manifest in the wrong target. Adding PrivacyInfo.xcprivacy to your project but not ticking the app target in File Inspector leaves the bundle without the file. App Store Connect sees no manifest and continues to reject. Verify by unzipping the .ipa.
• A third-party SDK that ships its own manifest, but a stale version. Vendors sometimes correct an incomplete declaration in a later release. If your Pods are locked, you may 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 the Transporter call 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. 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 real security review. The manifest is a disclosure. It does not check whether the disk-space query is sensible, whether secrets are hardcoded, or whether the binary leaks API keys. Those live in a separate pass over the compiled artifact. For an external read of the IPA against OWASP MASVS before submission, PTKD.com (https://ptkd.com) is one platform focused specifically on pre-submission scanning of compiled iOS and Android builds.

Key takeaways

• ITMS-91053 with NSPrivacyAccessedAPICategoryDiskSpace is a missing privacy manifest entry, not a code defect. Add the PrivacyInfo.xcprivacy file with the E174.1 reason code and the upload will process.
• Confirm the file is in the right target and actually shipped inside the .app bundle. The most common repeat-rejection cause is a manifest in the project tree but outside the target membership.
• If your own code does not call disk-space APIs, look at third-party SDKs. Bump them to a release dated after April 2024, when 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 successful fix behind the previous rejected build.
• 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.