How do I fix the 'Missing API declaration' for disk_space?

The rejection email lands a few minutes after Xcode finishes uploading the archive. The subject reads 'App Store Connect: Your app has one or more issues' and the body lists ITMS-91053 with the phrase Missing API declaration, followed by NSPrivacyAccessedAPICategoryDiskSpace. Your code compiles. TestFlight worked yesterday. The only thing keeping the build out of review is a missing plist entry, and Apple's ingestion pipeline will not negotiate the format.

Short answer

App Store Connect blocks any iOS, iPadOS, watchOS, or tvOS build whose compiled binary references a disk-space API but does not ship a PrivacyInfo.xcprivacy file declaring NSPrivacyAccessedAPICategoryDiskSpace with an approved reason code. The minimum fix is a five-line plist entry pairing the category with reason code E174.1, an incremented build number, and a fresh archive uploaded through Xcode or Transporter. Apple began rejecting non-compliant uploads on 1 May 2024, per the App Store privacy updates announcement, and the rule has not loosened in 2026.

What you should know

• The error is a manifest miss, not a code bug. Apple's ingestion service scans Mach-O symbols and rejects the upload during processing, before the build ever reaches App Review.
• Disk_space is one of four required reason categories. The others are file timestamp, system boot time, and user defaults. Each has its own approved-reason list.
• E174.1 is the approved reason for almost every legitimate disk-space check. It covers code that asks for free or total volume capacity to decide whether to write a file, per Apple's required reason API reference.
• The manifest belongs to whichever target calls the API. Your app target needs a manifest for your own code. Vendor frameworks need their own manifests, shipped inside the framework bundle.
• Apple began informational emails on 13 March 2024 and hard rejections on 1 May 2024. Any build uploaded after that date without a complete manifest is rejected at ingestion.
• The privacy manifest does not change runtime behavior. It is read by App Store Connect during processing and surfaced in the Privacy Nutrition Label on the listing page.

Why does App Store Connect flag disk_space at upload?

The short answer is that Apple decided in 2024 to audit four categories of API calls that historically served as fingerprinting vectors, and disk-space queries are one of those four. The audit runs on the compiled binary, not on your Swift source, which is why a project that builds cleanly on a Mac can still fail at upload. App Store Connect scans the Mach-O for symbols associated with NSURL volume keys (volumeAvailableCapacityKey, volumeAvailableCapacityForImportantUsageKey, volumeAvailableCapacityForOpportunisticUsageKey, volumeTotalCapacityKey), the BSD syscall family (statfs, fstatfs, statvfs, fstatvfs), and the legacy NSFileManager systemFreeSize helpers.

When the scanner finds any of those symbols and cannot locate a matching NSPrivacyAccessedAPICategoryDiskSpace entry in either the app's PrivacyInfo.xcprivacy or in a framework's bundled manifest, it returns ITMS-91053 with the literal phrase Missing API declaration. The build status in App Store Connect changes to Invalid Binary. The current rule, in force since 1 May 2024 per Apple's App Store privacy updates announcement, has not relaxed in 2026, and no informational mode is available for new submissions.

Which APIs sit inside the disk_space category?

Apple groups the disk-space symbols under one category in the manifest, so one entry covers any combination of the calls below. The table is drawn from Apple's Describing use of required reason API page.

A single NSPrivacyAccessedAPITypes entry with reason code E174.1 satisfies the rule for any of these symbols. There is no per-symbol code, and there is no benefit to adding a second copy of the entry with a different reason.

What does the correct PrivacyInfo.xcprivacy entry look like?

The minimum valid declaration 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. The template generates an empty PrivacyInfo.xcprivacy registered with the active target. Open the File Inspector and confirm that Target Membership shows your app target ticked. After archiving, right click the .ipa in Finder, choose Show Package Contents, and verify the file sits at the root of the .app bundle. A manifest that lives in the project navigator but outside the target is the most common cause of a second ITMS-91053 email after a developer is sure the fix has been applied.

How do you find which SDK triggered the rejection?

If your own code does not query disk space, the call is coming from a CocoaPods, Swift Package Manager, or vendored .xcframework dependency. Three approaches narrow the search quickly.

The first is symbol inspection. After archiving, open the .ipa, navigate to the Frameworks directory, and run the command nm -u <FrameworkName> against each binary. A hit on statfs, fstatfs, or any volumeAvailableCapacity key isolates the suspect framework in seconds.

The second is the SDK changelog. Major mobile vendors began shipping privacy manifests during the spring of 2024. Firebase, Google Mobile Ads, AppsFlyer, Adjust, Sentry, Branch, OneSignal, and Mixpanel had manifest-bearing releases dated after April 2024. If your Podfile or Package.swift is pinned to a version older than that, bumping to a current release usually clears the rejection without manual plist work. Apple's TN3183 technote on adding required reason API entries describes the same audit flow recommended here.

The third is process of elimination. Comment out the SDK initialization, archive, upload to a fresh App Store Connect record dedicated to test builds, and check whether the rejection still arrives. Slow, but it works for closed-source frameworks with no public changelog and no documented manifest.

What changes about the rule in 2026 compared to 2024?

The substance of the rule is unchanged. The deadline structure was set in February 2024 by Apple's privacy updates post: informational emails from 13 March 2024, hard rejections from 1 May 2024. App Store Connect now applies the rejection consistently across iOS, iPadOS, watchOS, tvOS, and visionOS submissions. visionOS, which launched after the cutover, was never given the informational grace window.

What has changed is the SDK landscape around the rule. Two years on, the long tail of frameworks that still ship without a manifest is short, and the symbols Apple flags are well known. Builds that fail ITMS-91053 in 2026 usually fail for one of three reasons: a stale dependency older than April 2024, a custom in-house framework whose maintainers never added a manifest, or a vendored binary delivered by a partner who does not track Apple's documentation. For an external read of the compiled IPA against the OWASP MASVS controls before submission, PTKD.com (https://ptkd.com) is one platform that scans the binary itself and flags manifest gaps alongside other storage and network issues that an automated upload check will not surface.

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 .ipa.
• A stale vendor manifest. Frameworks sometimes ship an incomplete declaration in an early release and correct it later. Pinning to an older pod can lock you to the incomplete file.
• Reusing the same build number. App Store Connect deduplicates by version plus build. After fixing the manifest, increment CFBundleVersion. Otherwise the old binary may sit in processing and look unchanged.
• Treating the manifest as a security audit. The plist is a disclosure of API use. It does not check for hardcoded keys, weak transport security, or insecure storage. Those issues live in a separate pass over the compiled binary.
• Confusing this rule with App Tracking Transparency. ATT prompts are runtime. The privacy manifest is upload-time metadata. They share the word privacy and almost nothing else.

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.
• The audit runs on the Mach-O. A project that compiles cleanly can still fail at upload if a third-party framework references a disk-space symbol without a manifest of its own.
• If your own code does not call disk space, bump dependency versions to releases dated after April 2024 before writing manual plist entries. Most major SDKs ship a manifest now.
• Apple did not soften the rule for 2026. The 1 May 2024 enforcement date still applies, and the rejection arrives at ingestion, not at App Review.
• 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 flags manifest gaps and storage or network issues in the same report.