What does "Invalid Binary" mean on the App Store?

It's an automated status App Store Connect assigns to a build that failed Apple's processing and validation checks after upload, before it reaches a human reviewer. It usually comes with an ITMS-prefixed error code naming the exact cause: a missing Info.plist key, an undeclared API, a signing problem, or an unanswered compliance question. It is not a guideline rejection, and you clear it by fixing the cause and re-uploading.

How do I fix ITMS-91053, the missing API declaration error?

ITMS-91053 means your app uses a "required reason" API without declaring an approved reason in a privacy manifest. Add a PrivacyInfo.xcprivacy file with an NSPrivacyAccessedAPITypes array covering the flagged categories. Because the offending API often comes from a third-party SDK, updating that dependency to a version that ships its own manifest frequently resolves it. It's been enforced on every upload since May 1, 2024.

Why is my build stuck on "Missing Compliance"?

Because you haven't answered App Store Connect's export-encryption question for that build, and it can't be submitted until you do. Answer it in the build's page, or add the ITSAppUsesNonExemptEncryption key to your Info.plist so you're never asked again. Only set it to NO if your app uses exempt encryption like standard HTTPS, since the declaration is legally binding.

Do I need a new build number to re-upload after an Invalid Binary?

Yes. App Store Connect rejects a re-upload that reuses a build number for the same version, so increment CFBundleVersion (the build number) before archiving again. You do not need to change your marketing version number; only the build number has to be unique.

How long does it take for a binary to process after upload?

Usually a few minutes to about an hour. The build shows "Processing" and then either becomes selectable for submission or flips back to "Invalid Binary" with an email explaining the new failure. Processing time is separate from App Review time, which is the human step that begins only after a valid build is submitted.

All posts

GuideJul 8, 2026 · 9 min

"Invalid Binary" and Other Pre-Review Errors, Decoded

"Invalid Binary" isn't a human rejection — it's an automated App Store review error that hits before your app reaches a reviewer. Here's how to clear each one.

The Argus Team

Reply Argus

"Invalid Binary" is not a rejection from a human reviewer. It's an automated status App Store Connect stamps on a build that failed Apple's processing and validation checks after upload, before your app ever reaches the App Review team. The email says your binary is invalid. What it means is that a machine, not a person, found something it won't accept: a missing Info.plist key, an undeclared API, a broken code signature, or an unanswered export-compliance question. None of it is a judgment call about your app, and almost all of it is fixable in a single re-upload.

The confusing part is the timing. These errors land fast, sometimes minutes after upload while you're still closing your laptop, and they read like the review verdict you were bracing for. They're not. Real App Review, where a human weighs your app against the guidelines, happens later and speaks a different language. This post maps the earlier gate: what "Invalid Binary" means, the pre-review errors and ITMS codes you'll actually hit, and how to clear each one.

What does "Invalid Binary" actually mean?

Every submission runs two gauntlets, back to back. First, automated processing: the moment your upload finishes, Apple's systems unpack the build, validate its structure, check entitlements and signatures, and scan for required declarations. Only if it passes does the build become selectable for submission and move to the second gauntlet, App Review, the human step where a reviewer opens your app and checks it against the guidelines.

"Invalid Binary" means you failed the first gauntlet. The build shows that status in App Store Connect and you get an email listing the reason, usually with an ITMS-prefixed code (a holdover from the old iTunes delivery pipeline, where the number maps to a specific check). The good news buried in it: a failed upload is not a review rejection. It doesn't burn a review, count against you, or start any clock. You fix the cause, bump the build number, and upload again. For what comes after this gate, see [the App Store review process explained](/blog/the-app-store-review-process-explained).

Which errors hit before a human ever sees your app?

These are the automated failures that produce an Invalid Binary or a stuck build, ordered roughly by how often they bite. Each maps to a concrete fix in your project, not a conversation with Apple.

Missing purpose string (ITMS-90683) — your app, or a framework it links, touches a protected resource (camera, microphone, location, photos, contacts) but your Info.plist has no usage description for it. Add the matching key (`NSCameraUsageDescription`, `NSLocationWhenInUseUsageDescription`, and so on), each with a real, human sentence explaining why. An empty or placeholder string can still fail.
Missing API declaration / privacy manifest (ITMS-91053) — since May 1, 2024, any app using a "required reason" API (user defaults, file timestamps, system boot time, disk space) must declare an approved reason in a `PrivacyInfo.xcprivacy` file. This one frequently comes from an SDK you didn't write, like an analytics or networking library, so the fix is often updating that dependency to a version that ships its own manifest, plus adding your own.
Missing Compliance / export encryption — not strictly an Invalid Binary, but it strands the build the same way: it sits under "Missing Compliance" and can't be submitted until you answer the encryption question. Add the `ITSAppUsesNonExemptEncryption` key to Info.plist to answer it once and skip the prompt on every upload.
Missing push notification entitlement (ITMS-90078) — you linked the push framework but the `aps-environment` entitlement isn't in the build, usually because the App ID or provisioning profile wasn't configured for Push Notifications. Fix the capability and regenerate the profile.
Invalid code signature / provisioning — wrong certificate, an expired or mismatched provisioning profile, or an entitlement the profile doesn't grant. The most Xcode-specific failure, and the one most worth letting automatic signing handle.
Bad or missing assets — a missing required app icon size, an unsupported Info.plist value, or a deprecated API flagged during processing. The email names the file; the fix is almost always in your asset catalog or plist.

Automated failure ≠ guideline rejection

Invalid Binary and its ITMS codes come from a machine checking structure, before review. A guideline rejection comes from a human reviewer and cites a numbered guideline (like 5.1.1 for data collection) inside App Store Connect's Resolution Center, not an ITMS code. If you're staring at a guideline number rather than an ITMS number, you cleared this gate, and that's a different problem, covered in the [App Store guideline rejections guide](/blog/app-store-guideline-rejections-guide).

How do I clear an Invalid Binary, step by step?

The loop is short once you trust it. Don't overthink the failure: read the exact code, fix the exact cause, and re-upload. Resubmitting the same binary hoping it processes differently is the one move that never works.

1
Step 1 — Read the exact code
Open the rejection email and find the ITMS-##### code and the file or key it names. Apple almost always tells you precisely what failed. Copy the code; it's your search term and your checklist for this build.
2
Step 2 — Fix the real cause in your project
Purpose string missing? Add the Info.plist key with a genuine reason. ITMS-91053? Add PrivacyInfo.xcprivacy and update the SDK that triggered it. Signing error? Verify the certificate, capability, and provisioning profile match. Make the smallest change that addresses the named cause — nothing else.
3
Step 3 — Bump the build number
App Store Connect rejects a re-upload that reuses a build number for a version. Increment CFBundleVersion (the build number) before you archive again. You do not need to change the marketing version.
4
Step 4 — Archive, upload, wait for processing
Upload the new archive and watch the build's status. It goes from "Processing" to selectable if it passes, or straight back to "Invalid Binary" with a new email if something else failed. Processing usually takes a few minutes to an hour.
5
Step 5 — Answer compliance and attach the build
If the build is stuck on Missing Compliance, answer the export-encryption question (or add ITSAppUsesNonExemptEncryption so it never asks again). Then select the build for your version and submit for review, the human gate you were actually trying to reach.

The privacy manifest is the modern first-timer trap

If you're hitting Invalid Binary for the first time in a while, ITMS-91053 is the likely culprit. It's newer than most guides, it's enforced on every upload since May 2024, and it usually originates in a third-party SDK rather than your own code. Before you dig through your source, check whether an outdated dependency is the one using a required-reason API without declaring it; updating that library often clears the error outright.

Export compliance is a legal declaration, not a UI toggle

Setting ITSAppUsesNonExemptEncryption to NO is only correct if your app uses exempt encryption (standard HTTPS via the system networking stack, say) and nothing more. If you ship your own cryptography, or you're unsure, don't reflexively set it to NO to silence the prompt; the answer is legally binding. Read Apple's export-compliance docs before you declare.

You cleared the gate — now the reviews start

Getting a valid binary through processing and past a human reviewer is the hard, satisfying part of shipping, and where a lot of teams mentally file the launch as "done." It isn't. The moment your app is live, a different stream starts: star ratings and written reviews from real users, in their own language, at the exact hours a bad update lands hardest. That first rocky release after a submission scramble is precisely when the reviews get pointed:

A quick, honest response here does real work. Google reported roughly a +0.7-star average lift for developers who respond (I/O 2019), and Hassan et al., across 4.5 million reviews, found reviewers who got a reply were about six times more likely to raise their rating (4.4% versus 0.7%).

Update took forever to show up and then crashed on open for me on an iPhone 12. Was excited for the new features but couldn't even get in.

Sorry 3.2 landed rough — a launch-time crash on iPhone 12 is exactly what we should have caught before shipping, and didn't. 3.2.1 with the fix is in review now. If it clears and you still hit it, email help@ and we'll dig in directly. — Sam

That reply is under a few hundred characters (safe on both stores, since Google Play caps replies at a hard 350), and it turns a two-star launch complaint into a visible sign that someone's home. Writing one is easy. Writing one for every review, in every language your users speak, during the week you're also firefighting the update that caused them: that's the part that quietly lapses.

This is where [ReplyArgus](/features) fits, and it's honest about its lane. It does nothing to your binary (that's between you and Xcode); it takes over the review side once you're live. It watches your Apple App Store and Google Play reviews in one inbox, drafts an on-brand reply to each in the reviewer's own language (100+ languages, both directions), grounded in your past approved replies and an auto-ingested knowledge base of your store listing, and holds everything for your approval before anything publishes. Solo devs shipping under exactly this time pressure use it to keep replies from piling up; there's a walkthrough in [replying to app reviews as a solo dev](/blog/reply-to-app-reviews-solo-dev). And because it exposes your reviews over an [MCP connector](/agentic-tools), you can triage them straight from Claude or Cursor without opening App Store Connect at all.

Start free — Argus drafts your first reply in minutes

Ship the binary; let ReplyArgus handle the reviews that follow. Connect a store and it surfaces every review and drafts an on-brand reply grounded in your real app, in the reviewer's language, waiting for your one-click approval. Free plan, no card: [start free](/signup).

Frequently asked

What does "Invalid Binary" mean on the App Store?: It's an automated status App Store Connect assigns to a build that failed Apple's processing and validation checks after upload, before it reaches a human reviewer. It usually comes with an ITMS-prefixed error code naming the exact cause: a missing Info.plist key, an undeclared API, a signing problem, or an unanswered compliance question. It is not a guideline rejection, and you clear it by fixing the cause and re-uploading.
Is Invalid Binary the same as an App Store review rejection?: No. Invalid Binary is an automated failure from Apple's upload processing, flagged with an ITMS code, before any person sees your app. A review rejection comes from a human reviewer and cites a numbered App Store Review Guideline in the Resolution Center. If you have an ITMS code, you haven't reached human review yet; if you have a guideline number, you have.
How do I fix ITMS-91053, the missing API declaration error?: ITMS-91053 means your app uses a "required reason" API without declaring an approved reason in a privacy manifest. Add a PrivacyInfo.xcprivacy file with an NSPrivacyAccessedAPITypes array covering the flagged categories. Because the offending API often comes from a third-party SDK, updating that dependency to a version that ships its own manifest frequently resolves it. It's been enforced on every upload since May 1, 2024.
Why is my build stuck on "Missing Compliance"?: Because you haven't answered App Store Connect's export-encryption question for that build, and it can't be submitted until you do. Answer it in the build's page, or add the ITSAppUsesNonExemptEncryption key to your Info.plist so you're never asked again. Only set it to NO if your app uses exempt encryption like standard HTTPS, since the declaration is legally binding.
Do I need a new build number to re-upload after an Invalid Binary?: Yes. App Store Connect rejects a re-upload that reuses a build number for the same version, so increment CFBundleVersion (the build number) before archiving again. You do not need to change your marketing version number; only the build number has to be unique.
How long does it take for a binary to process after upload?: Usually a few minutes to about an hour. The build shows "Processing" and then either becomes selectable for submission or flips back to "Invalid Binary" with an email explaining the new failure. Processing time is separate from App Review time, which is the human step that begins only after a valid build is submitted.

Try it

Let Argus draft your next reply.

Watch it answer a real review in your voice. 10-day trial, no card to begin.

Start free

See the features or pricing.

Keep reading

Guide8 min

App Store Reviews Not Showing? The Full Fix List for Apple and Google Play

App Store or Google Play reviews not showing? Here's every real cause — moderation delay, wrong country storefront, filtering, rating lag, cache — and the fix.

Guide9 min

Are App Store Reviews Fake? How to Spot Them and What to Do

Yes, some App Store and Google Play reviews are fake — but fewer survive than you think. How to spot them, and what to do when they hit your app.