Why did Apple flag my Firebase build under Guideline 5.1.1?

Your Firebase iOS build moved through processing in App Store Connect, and a few hours later Resolution Center returned a Guideline 5.1.1 finding pointing at one or more Firebase frameworks for a missing privacy manifest. The binary itself processed cleanly. What Apple is asking for is structured: the right firebase-ios-sdk version on disk, the right manifest entries in your own PrivacyInfo.xcprivacy file, and an accurate declaration of the required reason APIs your code touches around Firebase.

Short answer

Guideline 5.1.1 is the Data Collection and Storage clause, and Apple uses it for Privacy Manifest gaps when the missing or incomplete file would lead to incorrect privacy disclosures. For Firebase iOS apps, the most common trigger is a version of firebase-ios-sdk older than 10.22.0, the first release that shipped privacy manifests. Upgrading Firebase to a current 10.x or 11.x release, then declaring the required reason codes your own app code uses (typically UserDefaults and File Timestamp) in PrivacyInfo.xcprivacy, clears the rejection on the next submission through Apple's App Review Guidelines section 5.1.1.

What you should know

• Privacy Manifest enforcement started May 1, 2024, and tightened February 12, 2025. Apple now blocks submissions in App Store Connect when an SDK from its published list lacks a manifest.
• Firebase first shipped privacy manifests in firebase-ios-sdk 10.22.0 (March 4, 2024). Earlier versions trigger the rejection regardless of which Firebase products you import.
• Guideline 5.1.1 is not interchangeable with ITMS-91061. The validator warning blocks an upload. Guideline 5.1.1 means a human reviewer flagged the disclosure gap after the upload landed.
• You still need your own PrivacyInfo.xcprivacy file. Firebase ships manifests inside each framework, but your app target needs its own top-level file declaring the required reason APIs that your code (not Firebase code) calls.
• The fix is verifiable on the IPA. Each Firebase framework should contain a PrivacyInfo.xcprivacy resource, and your app bundle should ship one at the top level.

Why does a missing privacy manifest show up as a 5.1.1 rejection?

The short answer is that Apple groups Privacy Manifest issues under the data disclosure umbrella, and 5.1.1 is the clause that owns disclosure.

When the App Store Connect upload validator catches a missing manifest before submission, you see a warning code like ITMS-91061 ("Missing privacy manifest"). When the manifest is present but incomplete, or when the validator misses something and a human reviewer picks it up downstream, you get the rejection inside Resolution Center under Guideline 5.1.1 instead. The clause text from Apple's App Review Guidelines section 5.1.1 asks for accurate, complete disclosures of data collection, and the privacy manifest is now the primary structured input Apple uses to verify that disclosure against the nutrition label.

This matters because the fix path is different. ITMS-91061 from the validator gives you the SDK name directly. A 5.1.1 rejection often only names the guideline, leaving you to identify which framework triggered it. For Firebase apps, the practical first step is to verify the SDK version regardless of which framework Apple names, because most Guideline 5.1.1 findings on Firebase apps resolve at the version check before the manifest content even matters.

Which Firebase SDKs ship a privacy manifest, and which version do I need?

The short answer is firebase-ios-sdk 10.22.0 or later, with 10.25.0 closing the largest remaining gaps.

Per the Firebase Apple SDK release notes, version 10.22.0 (March 4, 2024) introduced privacy manifests across every Firebase SDK named on Apple's third-party SDK requirements list. Version 10.25.0 (April 30, 2024) removed UserDefaults calls from App Check, Crashlytics, Realtime Database, In-App Messaging, Performance Monitoring, and Remote Config so those frameworks no longer need a required reason declaration of their own. Version 10.24.0 removed mach_absolute_time from Crashlytics for the same reason.

If you use CocoaPods, your Podfile.lock should resolve Firebase to 10.22.0 or later, and CocoaPods 1.12.0 or newer is required to copy the manifest into the build. Swift Package Manager users pin to the same version range through Package.resolved. React Native projects on @react-native-firebase/app 19.0.0 or later track this Firebase version family, and Expo SDK 50 and later picks up the same versions through its config plugin.

What required reason codes belong in my own PrivacyInfo.xcprivacy alongside Firebase?

The short answer is the codes your own code triggers, not the codes Firebase has already declared.

Each Firebase framework declares its own required reason codes inside its embedded manifest. Your app's top-level PrivacyInfo.xcprivacy file covers the four reason categories described in Apple's required reason API documentation for code you wrote, including any wrapper code around Firebase calls. The four categories that show up most often in apps that integrate Firebase are listed below.

The mistake many developers make is copying Firebase's internal manifest entries into the app's own manifest. The two files do not need to repeat each other. Apple's tooling merges manifests across all frameworks in the bundle. Declaring a reason your code does not actually trigger reads as inaccurate, and Apple has the right to bounce the build on the same 5.1.1 grounds.

How do I check the build before resubmitting?

The short answer is two checks: one on the archive, one on the IPA.

First, in Xcode 15.3 or later, the build will fail at archive time if a referenced SDK from Apple's list ships without a manifest. That gate catches outdated Firebase before the IPA is produced. Build, archive, and let Xcode complete validation. If validation passes here, you have the SDK version part right.

Second, after archive, inspect the IPA. Each Firebase framework directory inside the bundle should contain a PrivacyInfo.xcprivacy file at its top level, and your app target should ship one alongside the executable. A quick shell loop in Terminal lists every manifest the bundle ships: unzip -l YourApp.ipa | grep PrivacyInfo. If a Firebase framework directory appears in the listing without its manifest, your Firebase version line is mixed and one product is older than 10.22.0.

For builders who want an automated read of the compiled IPA against OWASP MASVS and Apple's privacy disclosure rules before resubmission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning of AI-coded and no-code builds. The report covers the SDK list, the manifest presence per framework, and the required reason gaps against the four categories above. A separate scan does not replace Apple's validator, but it tends to surface the same findings before the build leaves your machine.

What to watch out for

The first trap is upgrading only some Firebase products. Mixed Firebase versions inside a single Podfile (for example, FirebaseAuth 10.22.0 alongside an older FirebaseStorage) often resolve cleanly in CocoaPods but ship one framework without a manifest. The validator may name only that one product. Pin every Firebase pod to the same version line, or upgrade the umbrella Firebase pod and let CocoaPods resolve.

The second trap is shipping a hand-written manifest with reason codes that do not match the code. Apple's tooling cross-references the binary against the declared codes. A manifest that claims CA92.1 for UserDefaults reading when no NSUserDefaults symbol exists in your binary reads as inaccurate, and so does a manifest that omits a code Apple's static analysis finds in your binary.

The third trap is assuming React Native, Expo, or FlutterFlow wrap the requirement away. All three pass the manifest requirement through to the native side. The Firebase pod version is what matters, and any other native SDK on Apple's list still needs its own manifest. Expo SDK 50 and later handle the app-level manifest generation, but third-party native modules outside that bundle remain the developer's responsibility.

The fourth trap is treating a 5.1.1 rejection as identical to ITMS-91061. The validator warning blocks the upload. The 5.1.1 rejection lands after submission, often after the build has been in review for days. A clean validator run is necessary, not sufficient.

Key takeaways

• A 5.1.1 rejection that names Privacy Manifest is almost always a Firebase SDK version problem first and a missing reason code problem second. Check Podfile.lock or Package.resolved before anything else.
• Firebase iOS SDK 10.22.0 was the first release with manifests; 10.25.0 closed the largest remaining gaps. Keep the Firebase product family in lockstep.
• Your own PrivacyInfo.xcprivacy file declares the reason codes your code uses, not the codes Firebase already declares inside each framework manifest.
• Verify the IPA by listing PrivacyInfo.xcprivacy occurrences before resubmitting. Xcode validation catches the obvious case; the IPA listing catches the rest.
• Some teams pair Firebase apps with an external pre-submission scanner. PTKD.com (https://ptkd.com) is one of the platforms focused on automated scanning of compiled mobile builds against OWASP MASVS and Apple's privacy disclosure rules before they reach App Store Connect.