Your App Got Rejected. The Bad Code Wasn’t Yours.

You shipped a clean build on Friday.

Monday morning, the rejection letter lands. Guideline 5.1.1. Something about PrivacyInfo.xcprivacy and a “required reason API” you’ve never heard of.

You search the codebase. Nothing.

You didn’t write the offending code. One of your SDKs did.

This is the most common iOS rejection pattern in 2026, and it has almost nothing to do with the app you built. Apple reviewed 7.77 million app submissions in 2024 and rejected 1.93 million of them, roughly 1 in 4. That number climbed 9.5% year-over-year. Privacy noncompliance is one of the biggest categories, and the trap is that the violation is usually buried in a third-party framework you pulled in months ago.

Here’s the take: if you ship iOS apps and you don’t run a privacy manifest audit before every submission, you’re rolling dice with your launch date. The fix takes under an hour. The rejection costs you a week.

What “required reason API” actually means

Apple flagged a handful of common system APIs as “required reason.” They’re not banned. You just have to declare why you use them in a manifest file called PrivacyInfo.xcprivacy.

The list includes APIs almost every app touches:

·       UserDefaults (settings, flags, tokens)

·       File timestamps and disk space

·       System boot time

·       Active keyboard list

Use the UserDefaults API, the disk space API, or access the system boot time, all of which Apple now considers “required reason APIs.” You did not include a privacy manifest declaring these usages. Rejected.

The catch is that almost no one calls these APIs directly anymore. Firebase calls them. Mixpanel calls them. Sentry, Amplitude, AppsFlyer, the React Native bridge, Expo modules. Half the cross-platform mobile ecosystem touches at least one required reason API in some internal helper.

Privacy Manifests are the sneakiest blocker. Now every third-party library bundled in your app needs it. Miss one, and you’re rejected before a human even looks at your app.

Why your app target isn’t the problem

The thing that confuses most engineers reading the rejection letter: they add a PrivacyInfo.xcprivacy to the app target, resubmit, and get rejected again.

That’s because the missing manifest isn’t yours.

If your rejection letter mentions “PrivacyInfo.xcprivacy” or the phrase “required reason API,” the fix is almost always a missing manifest inside one of your bundled SDKs, not your app target. Apple’s rejection letter usually names the framework. Update it or vendor a manifest file into the framework bundle.

Translation: every SDK ships its own manifest now, and if one of them is on a version released before the SDK author got around to adding theirs, your app catches the blame.

Every third-party library bundled inside your app needs its own manifest not just your code.

The 30-minute pre-flight audit

Run this before every TestFlight build that’s headed for review. It’s faster than reading this section.

1.     Generate the Privacy Report in Xcode. Run Xcode’s Privacy Report before every submission. In Xcode: Product → Generate Privacy Report. This gives you a single PDF summary of every manifest in your app. If anything is missing, it appears here, before Apple sees it. This is the single highest-ROI step in this whole post.

2.     Diff your SDK versions against their changelogs. For every native dep in Podfile.lock, Package.resolved, or your Expo config, check whether the current version includes a privacy manifest. Most major SDKs added theirs between mid-2024 and early 2025. If you’re pinned to an older release, that’s your suspect.

3.     Update or vendor. If a maintained SDK has a newer version with the manifest, bump it. If it’s abandoned, you have two choices: vendor a manifest into the framework bundle yourself, or replace the SDK. Pick replace if you can.

4.     Audit your tracking story. Every analytics, attribution, and crash SDK should map cleanly to an entry in your App Privacy Label. If your code collects an email but the label says “no data linked to user,” that’s a separate rejection waiting to happen.

5.     TestFlight first, App Store second. TestFlight is your safety net. Running a beta before production submission catches the blockers that would otherwise kill your launch timeline. Cheap insurance.

That’s the whole audit. Five steps, no heroics.

The cost of skipping it

The rejection itself is technically free. Apple doesn’t fine you. You just resubmit.

The real cost is downstream. The cost of a rejection is not the rejection itself, it is the week of re-submission cycles, the fixed launch date you slipped, and the retention curve that flattens while you wait.

If you’ve already booked a press hit, sent the launch email, or promised an investor a “live in the store by month-end” date, the slip compounds. A founder we talked to had to push a Series A demo by 11 days because their attribution SDK was one minor version behind. The engineering fix took 40 minutes. The investor reschedule took the rest.

React Native and Flutter teams: read this twice

If you’re shipping cross-platform, your SDK surface area is bigger than you think.

Every native module Expo autolinks, every CocoaPods transitive dependency, every Flutter plugin that wraps an iOS SDK, is a potential manifest gap. The pure-JS or pure-Dart code is fine. It’s the native bridges that catch you.

A practical checklist for cross-platform teams shipping to the App Store:

·       Pin Expo SDK to a recent release. Manifest support landed across Expo’s first-party modules in 2024 builds.

·       Audit Flutter plugins individually. The Flutter team can’t push a manifest into someone else’s plugin.

·       For React Native, run pod install --verbose and read the framework list. Anything you don’t recognize is worth a manifest check.

·       If you use OneSignal, Branch, Adjust, Singular, AppsFlyer, or any attribution SDK, double-check. These were among the last to ship manifest updates.

This is also where we’d point you to our React Native app development and Flutter app development pages if you’d rather not own this audit yourself.

When this take is wrong

A few cases where the privacy manifest isn’t actually your problem.

If your rejection letter cites Guideline 2.1 (App Completeness), that’s about broken demo flows or missing login credentials, not privacy. Different fix entirely.

If you’re getting hit on 4.3 (Design), the reviewer thinks your app duplicates something already in the store. Manifests won’t help.

And if you’re a small indie shipping a single-target SwiftUI app with zero third-party SDKs, you can probably get away without PrivacyInfo.xcprivacy for now, assuming you don’t call any required reason APIs yourself. Most teams aren’t in that bucket.

The pre-submission checklist (steal this)

Tape this above your monitor. Run it before every App Store submission:

·       [ ] Product → Generate Privacy Report in Xcode shows zero missing manifests

·       [ ] Every analytics, attribution, and crash SDK is on a 2024-or-later release

·       [ ] App Privacy Label matches what your code actually collects

·       [ ] If you access IDFA at all, ATT prompt is implemented and live

·       [ ] Delete Account flow exists in Settings, not just via support email

·       [ ] TestFlight build ran for at least 24 hours with no privacy-related warnings in Xcode

·       [ ] You can name every native dep in your bundle and why it’s there

If all seven check, submit. If any don’t, fix before you click “Submit for Review.” A failed review costs you a week minimum. The checklist costs you twenty minutes.

You don’t need to learn this the hard way

If you’ve shipped an iOS app, you’ll hit this eventually. The first time costs you a launch slip. The tenth time costs you twenty minutes.

If you’d rather skip straight to the tenth time, we can help. We ship iOS apps and cross-platform builds with privacy manifest checks baked into the standard pre-submission process, not bolted on the week before review. Senior engineers only. You talk to the person fixing your manifest, not an account manager.

Send us your Podfile.lock (or package.json and Expo config) and we’ll tell you within 48 hours which SDKs are likely to trip the next review. Free, no scope call required.

Send it over here.

P.S. If you’ve already been rejected and the clock is ticking on a launch date, lead with the rejection letter text in your message. The guideline number tells us 80% of what we need to know before we even open your project.

P.P.S. We’ve shipped this audit for teams in regulated verticals where a rejection isn’t just a slip, it’s a compliance event. Our ResQ case study is one example of a mobile build where the pre-submission checks were part of the architecture, not the launch sprint.