How do I fix 'Missing API declaration' for disk_space in 2025?

The rejection email arrives within minutes of a successful Xcode archive upload. App Store Connect lists ITMS-91053, Missing API declaration, and names NSPrivacyAccessedAPICategoryDiskSpace. In 2025 this message stings more than it did in 2024, because the fix you applied two years ago to your own code may no longer cover what a third-party SDK has quietly started shipping with your latest update.

Short answer

The ITMS-91053 rejection for disk_space happens when the compiled iOS, iPadOS, watchOS, tvOS, or visionOS binary references a disk-space API and no PrivacyInfo.xcprivacy file inside the bundle declares NSPrivacyAccessedAPICategoryDiskSpace with an approved reason. The five-minute fix is to add a manifest entry pairing the category with reason code E174.1, increment the build number, and re-upload through Xcode or Transporter. Per Apple's required reason API reference, E174.1 covers code that checks free space before writing files or low-space cleanup logic. A separate 2025 change made third-party SDKs the most common culprit.

What you should know

• The rejection is an ingestion check, not an App Review decision. App Store Connect runs it during binary processing and the build never reaches a human reviewer.
• Apple did not add or remove disk_space reason codes in 2025. E174.1 remains the only approved reason for the entire category.
• A second enforcement layer applies as of February 2025. App updates that add a new privacy-impacting SDK without a bundled manifest are blocked at upload.
• The manifest must live inside the right bundle. An app-level file does not cover symbols compiled into a vendor framework that ships its own binary.
• Incrementing CFBundleVersion is part of the fix. App Store Connect deduplicates by version plus build, so a re-upload using the same build number can appear to be ignored.
• The privacy manifest does not perform a security audit. It discloses API use to App Store Connect and does not scan for hardcoded keys, weak transport, or insecure storage.

What changed for disk_space rejections in 2025?

The headline change is the February 12, 2025 third-party SDK rule, which closed a gap that had let some teams pass review with stale dependencies. Before that date, an app update that added a new commonly used SDK without its own manifest would often slip through ingestion if the app target's own PrivacyInfo.xcprivacy declared the relevant categories. After February 2025, the ingestion service expects the SDK itself to ship a signed manifest when it appears on Apple's published commonly used list. If the SDK calls disk-space APIs and ships no manifest, ITMS-91053 returns even when your app's own manifest is complete.

The published list now sits around 89 SDKs, covering Firebase, Alamofire, AFNetworking, AppAuth, Capacitor, FBSDKCoreKit, Flutter, OneSignal, RealmSwift, Reachability, and a long tail of helpers used by React Native and Flutter projects. The specific symbols Apple scans for, the BSD statfs family and the NSURL volume capacity keys, are unchanged. What changed is who Apple expects to declare them.

Why does App Store Connect still reject builds for disk_space?

The mechanism has not moved. App Store Connect scans the compiled Mach-O binary inside the .ipa for symbols that belong to the four required reason categories: disk_space, file timestamp, system boot time, and user defaults. When a symbol from any category appears without a matching entry in either the app's PrivacyInfo.xcprivacy or in a framework's bundled manifest, the build status changes to Invalid Binary and the email goes out with ITMS-91053. The disk_space symbols Apple inspects include volumeAvailableCapacityKey, volumeAvailableCapacityForImportantUsageKey, volumeAvailableCapacityForOpportunisticUsageKey, volumeTotalCapacityKey, the BSD calls statfs, fstatfs, statvfs, and fstatvfs, and the older NSFileManager systemFreeSize and systemSize helpers.

In 2025 the visible difference for developers is that the rejection email almost always names a framework instead of the app target. Two years of SDK updates have closed the gap on the most popular libraries, so a fresh failure usually points at a vendored binary, an in-house framework, or a closed-source partner SDK whose maintainers never followed the documentation.

Which SDKs still trigger the disk_space rejection in 2025?

The remaining offenders fall into a handful of groups. The table below draws on the Apple commonly used SDKs list and on public issue trackers where developers post repeat ITMS-91053 reports.

The pattern in 2025 is that the long tail of open-source frameworks has caught up, while binary-only and in-house frameworks are where most live rejections come from. The Apple TN3183 technote describes the symbol audit workflow Apple recommends for identifying which framework triggered the rejection.

How do you write a valid PrivacyInfo.xcprivacy entry for disk_space?

The minimum valid entry is one dictionary inside the NSPrivacyAccessedAPITypes array. The key NSPrivacyAccessedAPIType holds the string NSPrivacyAccessedAPICategoryDiskSpace, and the key NSPrivacyAccessedAPITypeReasons holds a one-element 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>

In Xcode, add the file via File, New, File from Template, then pick App Privacy from the Resource section. Confirm that Target Membership shows the app target ticked in the File Inspector. After archiving, right click the .ipa in Finder, choose Show Package Contents, and verify that PrivacyInfo.xcprivacy sits at the root of the .app bundle. A manifest that lives in the project navigator but outside the target remains the most common cause of a second ITMS-91053 email after a developer is sure the fix has been applied. For frameworks you maintain, the same file goes inside the framework bundle, signed alongside the binary, per Apple's privacy manifest documentation.

What does a 2025 debug workflow look like for ITMS-91053?

The honest answer is that the workflow now starts by assuming the call is coming from a dependency, not your code. Three steps narrow the search quickly.

First, unzip the .ipa and run nm -u against each framework binary in the Frameworks directory. Any hit on statfs, fstatfs, or a volumeAvailableCapacity symbol isolates the suspect framework in seconds. Second, inspect the changelog for that framework. Major mobile vendors began shipping manifests in spring 2024 and the February 2025 rule pushed laggards to follow; if the framework's last release is older than April 2024, a version bump usually clears the rejection without manual plist work. Third, if a closed-source binary is the offender, request a manifest-bearing release from the vendor. The wait can be long, so some teams add a temporary wrapper manifest at the app level while the vendor catches up, then remove it on the next vendor release. Some teams also run the compiled IPA through PTKD.com (https://ptkd.com), which scans the binary against OWASP MASVS controls and lists missing required reason API declarations alongside storage and network findings that App Store Connect's ingestion does not touch.

What to watch out for

• Target membership left unticked. The manifest must be a member of the app target, not just present in the project tree. Verify by unzipping the archive.
• Reusing the same build number. App Store Connect deduplicates by version plus build. After fixing the manifest, increment CFBundleVersion or the previous rejected binary may sit in processing and look unchanged.
• Treating the manifest as a security audit. The plist discloses API use. It does not check for hardcoded keys, weak transport, or insecure storage, and the pass that surfaces those issues is a separate process.
• Confusing this rule with App Tracking Transparency. ATT prompts run at runtime. The privacy manifest is upload-time metadata read by App Store Connect.
• Assuming the 2024 manifest still covers everything. The February 2025 SDK rule changed who must declare what, so app-level declarations no longer paper over a stale dependency.

Key takeaways

• The Missing API declaration message for disk_space is a missing PrivacyInfo.xcprivacy entry. Add NSPrivacyAccessedAPICategoryDiskSpace with reason code E174.1, increment the build number, and resubmit.
• In 2025, the rejection almost always points at a third-party or in-house framework, not the app target. Bump dependencies to releases dated after April 2024 before writing manual plist entries.
• The February 12, 2025 rule changed enforcement for SDKs on Apple's published list. Stale binaries that escaped review in 2024 can fail in 2025 even when the app's own manifest is complete.
• Apple did not change the approved reason codes for disk_space. E174.1 is still the only one needed.
• The manifest discloses API use rather than auditing the binary. Some teams who want a separate read of the IPA against OWASP MASVS controls run their compiled build through PTKD.com (https://ptkd.com), which surfaces manifest gaps and storage or network issues in the same report.