The code was never the hard part. The App Store review was.

I shipped my first iOS app — a small baby tracker — and got rejected twice. Not for bugs. Not for crashes. For things I literally couldn’t see: a privacy-label mismatch I didn’t know existed, and EULA/paywall wording that wasn’t where Apple wanted it. Each rejection meant a 24–48h wait, a fix, a resubmit, and another wait.

The frustrating part wasn’t the rejection. It was that every reason was already sitting in my build and my App Store Connect metadata the whole time. Nothing just cross-references them and tells you “hey, this will bounce.”

So I started pulling my own builds apart to understand what Apple actually looks at. Here’s what I learned — and the Swift to do it yourself.

An .ipa is just a ZIP

That’s the first thing that clicks. Rename it, unzip it, and you get:

Payload/
YourApp.app/
Info.plist
PrivacyInfo.xcprivacy
embedded.mobileprovision
Frameworks/
SomeSDK.framework/
PrivacyInfo.xcprivacy

Everything Apple’s automated checks care about is in there. If you build with Xcode, the .xcarchive in ~/Library/Developer/Xcode/Archives has the same .app bundle under Products/Applications/ — and it exists before you export an .ipa, so you can inspect it earlier.

Reading Info.plist (it’s binary)

A common gotcha: the Info.plist inside a shipped build is usually in binary format, not XML. In Swift, PropertyListSerialization handles both transparently:

let plistURL = appURL.appendingPathComponent("Info.plist")
let data = try Data(contentsOf: plistURL)
let info = try PropertyListSerialization
.propertyList(from: data, format: nil) as? [String: Any] ?? [:]

Now you can check the things that quietly get apps rejected. The classic one is empty or placeholder usage strings (Guideline 5.1.1):

for (key, value) in info where key.hasSuffix("UsageDescription") {
let text = (value as? String ?? "").trimmingCharacters(in: .whitespaces)
if text.count < 10 || ["todo", "test", "xxx"].contains(text.lowercased()) {
flag(.error, "5.1.1", "(key) is empty or placeholder")
}
}

I shipped a NSCameraUsageDescription that literally said “TODO” once. Don’t be me.

Another cheap win: ITSAppUsesNonExemptEncryption. If it’s missing, you get the export-compliance question on every submission, which slows you down.

The privacy manifests (the modern rejection magnet)

Since May 2024, third-party SDKs that use “required reason APIs” must ship a privacy manifest (PrivacyInfo.xcprivacy). Missing ones are a top rejection reason now. They live at the app root and inside each .framework, so you walk them recursively:

let frameworksURL = appURL.appendingPathComponent("Frameworks")
let frameworks = (try? FileManager.default.contentsOfDirectory(
at: frameworksURL, includingPropertiesForKeys: nil)) ?? []

for framework in frameworks where framework.pathExtension == "framework" {
let manifest = framework.appendingPathComponent("PrivacyInfo.xcprivacy")
if !FileManager.default.fileExists(atPath: manifest.path) {
flag(.error, "privacy", "(framework.lastPathComponent): no privacy manifest")
}
}

The part that actually matters: the cross-check

Here’s the insight that turned this from “a checklist” into something useful.

A static checklist can tell you “you should declare your data collection.” It can’t tell you that your specific build contains an SDK that collects data you forgot to declare. That requires crossing your build with your App Store Connect metadata.

Concrete example: RevenueCat’s privacy manifest declares it collects Purchase History:

let manifestData = try Data(contentsOf: manifest)
let m = try PropertyListSerialization
.propertyList(from: manifestData, format: nil) as? [String: Any] ?? [:]

let collected = (m["NSPrivacyCollectedDataTypes"] as? [[String: Any]] ?? [])
.compactMap { $0["NSPrivacyCollectedDataType"] as? String }
// -> ["NSPrivacyCollectedDataTypePurchaseHistory"]

If that data type is collected by an SDK in your binary but missing from your App Privacy labels in App Store Connect (which you can read via the App Store Connect API, read-only), that’s an instant Guideline 5.1.1 rejection — and one you’d never catch by eye. That mismatch is the whole game.

Deterministic vs subjective

One honest distinction I had to make: not all rejections are catchable from static analysis.

• Deterministic (always catchable): missing privacy manifests, undeclared SDK data, empty usage strings, export compliance, metadata mismatches. These never vary by reviewer.
• Subjective (reviewer-dependent): design judgments, “spam”, perceived value. No tool can predict these honestly.

Anyone claiming to predict the second bucket is selling you something. The first bucket, though? That’s the stuff that quietly wastes your week, and it’s 100% catchable before you ever hit “Submit.”

I packaged this into a tool

I ended up turning all of this into a small native macOS app called Cleared — you drop in a build, it parses it locally, pulls your App Store Connect metadata read-only, and flags the deterministic rejection reasons before you submit. It runs fully on-device (the AI explanations too — no key, nothing leaves your Mac).

But honestly, the point of this post isn’t the tool. It’s that most App Store rejections are predictable, and you already have everything you need to catch them — it’s sitting in your .ipa right now.

If you ship iOS apps: what’s the rejection that burned you the most? I’m still adding checks based on real ones.

(If you want to try the tool: cleared.sakaax.com — but the parsing above works on its own too.)