When an app will not publish, one of five steps failed, and the status names it.
An app will not publish for one of five reasons, and they come in a fixed order: the developer account, then the signing certificate or key, then the build, then the store metadata, then review. Work them in that order, because each one gates the next. The fastest way to find your point is the exact status word on the screen, since Apple and Google both publish what every status means. For the happy path rather than the triage, read publishing an AI-built app.
Every step, field name, limit and policy below comes from Apple's or Google's own documentation, read on 3 October 2026. The two stores differ at all five points, and the differences are stated here rather than implied. Where a store publishes no figure, this page says so instead of supplying one.
Find your failure pointThe short version
Five points, one order and a different tell at each.
The order is a dependency chain. An unaccepted agreement stops a certificate being issued. A missing certificate stops a build signing. An unsigned build never uploads. An incomplete privacy declaration leaves the submit control inert. Only after all four does a human look at anything.
The tell differs by point. Points one to four fail inside your own console, with a specific string you can look up. Point five fails with a message from a reviewer. If nobody has written to you, you are not in review yet, and nothing you say to a reviewer will help.
The five failure points, in the order they happen
Point one is the developer account: enrolment, identity verification, and the agreements attached to it. Point two is signing, which means a distribution certificate on Apple and an upload key plus the Google Play app signing key on Android. Point three is the build, which fails at upload and nearly always with a reason attached. Point four is store metadata, the declarations that must be complete before the submit control does anything. Point five is review.
Points one to four are yours, and most are fixed in minutes once named. Point five is not yours: there you have three levers and no others, which are answering the reviewer, requesting an expedited review, and appealing. If you cannot publish an app to a store at all and no reviewer has ever written to you, the problem sits above review. When a publish fails inside an app builder, the builder is relaying a refusal that came from the store, so the store's wording is the part worth reading.
Triage
Which step actually failed
Pick the line closest to what you are looking at. The answer names the failure point and the first thing to check.
Nothing picked yet
Six symptoms, five real failure points, and one that turns out to be a release setting. Pick a line above.
Read the exact status, because the status names the step
Apple publishes a status table and colours it: red means you have to act before the app distributes, yellow means a process is still running, green means Ready for Distribution. Four strings are worth knowing by heart. Invalid Binary means the build does not meet the current binary requirements, so you upload a new one or pick a different build. Missing Compliance means the build carries no export compliance answer. Pending Developer Release means Apple accepted it and is waiting for you. Metadata Rejected means the reviewer refused your text or images rather than your code, which you fix in the console without building anything.
One status catches people badly. Ready for Distribution carries a condition in the same sentence: your agreements must be in effect, and the Account Holder accepts the latest ones in the Business section. An agreement can also reach the status Disabled, and Apple's description of that one is blunt, because the app is removed from the App Store until you provide the required information and Apple accepts it.
Google splits the question into three. App status is who can get the app: Draft, Internal testing, Closed testing, Open testing, Pre-registration, Production, plus No active releases, Unpublished, Removed by Google and Suspended by Google. Update status is where your latest batch of changes sits: In review, Update rejected, App rejected, or Changes not yet sent for review. Item status is the state of one piece, such as a release or a store listing. Read Update status first, because Google does not send your changes for review automatically, and that last string fully explains an app that has not moved in a week.
Account, signing and build: everything that fails before a human looks
On Apple the account fails through agreements. The Account Holder is the only person who can accept legal agreements and renew the membership, and Apple ties continued access to Certificates, Identifiers and Profiles, App Store Connect and the App Store Connect API to those terms being accepted by the date shown on the account landing page. If uploads started failing on a day you changed nothing, look there first. On Google the account fails through identity instead: the legal name and address come from the linked Google payments profile, and Google says those details have to be verified before you publish. An organisation account also needs a D-U-N-S number, issued free by Dun and Bradstreet, which Google says can take up to 30 days.
Google adds one gate with no Apple equivalent. A personal developer account created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days, then apply for production access from the Dashboard in Play Console. Internal testing carries no such requirement, Google says builds reach internal testers within seconds of being added, and updates on an internal test track are not subject to review, though Google notes they can be reviewed retroactively once the app is live on Play. That is why an app can work perfectly for your own testers and still be two weeks away from production.
Signing fails differently on each side. On Apple, distribution certificates belong to the team, only one of each distribution certificate type is allowed per team, and only the Account Holder or an Admin can create one; enrolled as an individual, you are the Account Holder. A TestFlight build reporting Not Available for Testing is telling you the provisioning profile is missing an application identifier, which is a signing fault wearing a testing label. On Google there are two keys and confusing them is the common error: you sign the bundle with your upload key, which Google can reset if it is lost or compromised, while Google Play holds the app signing key that signs what users install.
The build itself fails at upload. Apple currently requires uploads to be built with Xcode 26 or later using an SDK for iOS 26, and iOS apps uploaded to App Store Connect must target iOS 13 or later. Google currently requires new apps and app updates to target Android 16, API level 36, or higher. A build upload sitting in Processing for more than 24 hours is a fault rather than a queue, and Apple's instruction there is to file a Feedback Assistant ticket or contact them. A failed upload lets you reuse the same build number, so a bad attempt costs you nothing. On Google, an Errors summary at the top of the release review page blocks the release, while warnings alone do not. If the build uploaded cleanly and review still said no, that is a different list, and why apps get rejected from the app store is the one to read.
Metadata, review, and the app that was approved and still is not there
Metadata is the quietest failure, because nothing is broken. Apple requires a privacy policy URL for every app, and requires you to describe your data handling under App Privacy in App Store Connect with the answers published. Apple also asks encryption questions on every new version unless you record the answer in the app's Info.plist, which is why Missing Compliance reappears build after build. Google requires the Data safety form on the App content page for every app published on Google Play, including the closed, open and production tracks, and exempts apps active only on internal testing. The Android declaration you can skip while testing becomes compulsory the moment you widen the track.
Review is a queue with published numbers on one side only. Apple says that on average 90 percent of submissions are reviewed in less than 24 hours, and that an incomplete submission may be delayed or may not pass. Google gives a range rather than an average: a review can take a few hours or up to seven days, longer in exceptional cases, and certain accounts and certain apps get the longer look. Google also counts the turnaround from the last submitted change, so sending another change while changes are in review can push your app to the back of the queue. Neither store publishes a rejection rate, so any percentage you have seen for that did not come from the stores.
A rejection is not one thing. Apple separates Rejected from Metadata Rejected, and notifies users holding the Admin, App Manager or Developer role. A submission can also carry several items, and Apple is explicit that every item has to be accepted before any of them publish, so one refused in-app purchase holds the whole app. Google separates Update rejected from App rejected, where App rejected applies only to an app still in Draft that you are publishing for the first time. Apple also runs an App Review Board, with the instruction to submit only one appeal per submission that did not pass, and the way to appeal app store rejection is a procedure of its own.
Last, the case that is not a failure. A version showing Pending Developer Release means Apple is waiting for you: open the version, press Release This Version, confirm, then allow up to 24 hours for it to appear on the App Store. Apple emails a reminder if a version sits there for more than 30 days. A phased release reaches a random sample of users with automatic updates over seven days, so a small number on day one is the design rather than a bug. And Pending Apple Release means Apple is holding your version until the matching operating system version ships, which is a deployment target question rather than a review one. What to watch once it is live starts after you submit.
Google Play Console Help, Publish your app: publishing statuses and review times
The same five points, store by store
| Failure point | How iOS tells you | How Android tells you | When it stops you |
|---|---|---|---|
| Developer account or agreement | Agreement status such as Pending User Info or Disabled; only the Account Holder can accept, in Business | Publishing is blocked until your identity details are verified; an organisation account needs a D-U-N-S number | Before signing, and again at release |
| Certificate or signing key | Only the Account Holder or an Admin can create a distribution certificate, one of each type per team | You hold the upload key, Google Play holds the app signing key; Play App Signing needs admin permission | Before upload |
| The build | Invalid Binary, or an upload stuck in Processing for more than 24 hours | An Errors summary on the release review page blocks it; warnings alone do not | At upload |
| Store metadata | Privacy policy URL and published App Privacy answers; Missing Compliance if encryption is unanswered | Data safety form required on every track except internal testing | Before you can submit |
| Review | On average 90 percent of submissions reviewed in less than 24 hours | No average published; a few hours to seven days, longer in exceptional cases | After you submit |
Where a builder helps, and where it hands the keys back
A tool can do points two and three for you, and part of point four. Nothing can do point one, and nothing should do point five. Apple's App Store Review Guidelines, guideline 4.2.6, says apps created from a commercialised template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. A builder offering to press submit for you is offering you a rejection.
Newly is an AI app builder: you describe the app in plain English and it writes a React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then uploads it. It is $25 a month and there is no free plan. On iOS it uploads to App Store Connect and TestFlight, and the submit for review step stays yours. On Android it publishes to Google Play internal testing and separately builds a standalone production APK. Both actions are owner or admin only, which is itself a point one problem when the account holder is not the person pressing the button.
What it does not do matters more on this page. It does not enrol you in either developer programme, accept agreements, hold your D-U-N-S number, or run 12 testers for 14 days for you. It cannot answer App Privacy or Data safety either, because only you know what your app collects. Those are the failures this page exists for, and they stay with you whatever wrote the code.
Questions people ask when a publish will not go through
Because uploading and publishing are different gates. After a clean upload you can still be blocked by store metadata or by the account. On Apple that usually means a missing privacy policy URL, unpublished App Privacy answers, or an unanswered encryption question showing as Missing Compliance. Apple also warns that an app reading Ready for Distribution only distributes once your agreements are in effect, which the Account Holder accepts in the Business section. On Google it is most often the Data safety form, or an Update status reading Changes not yet sent for review, because Google does not send your changes for review automatically.
Find the point, then fix the point
Open the console and write down the exact status word before you change a single thing. For points one to four the string names your fix. For point five, answer the reviewer and wait, because nothing else moves it.
Start building