The Rejection Email Already Says What to Fix

The Guideline Number Comes First

A rejection notice is short. It names the guideline you tripped, describes what the reviewer saw, and states what they want changed. Of those three, the one that decides your next move is the number. It maps onto the published review guidelines line for line, so opening that entry shows you the standard being applied rather than one reviewer’s summary of it.

Skip the number and read only the prose, and you will fix the wrong thing. “Your app is not useful enough” sounds like a request for more features. If the number attached to it points at minimum functionality, the request is about kind rather than count: an app that only does what a browser already does has no reason to sit in the store. Read the sentence emotionally and you start bolting on features. Read the number and the direction is decided for you.

Rebuild, Reply, or Just Fix the Listing

Rejections split three ways. The first is an app that genuinely is not finished. Crashes during review, leftover placeholder copy, links that go nowhere: there is no route out of these except a new build. Completeness is the guideline Apple cites more than any other, and most of what falls under it is visible before you submit.

The second is a reviewer who never reached the feature. Anything behind a login does not exist without an account, and the same goes for anything behind a paywall. What this needs is not a code change but a test account in the review notes, the steps to reproduce, and a short screen recording when the flow is unusual. More rejections than people expect are closed with one reply.

The third is store metadata. Screenshots that no longer match the build, a description promising something the app does not do. Metadata problems can be corrected in the listing without shipping a new binary at all. Miss that distinction and you spend days rebuilding something that was never the problem.

Blocked Before a Reviewer Sees It

Google requires new apps and updates to be built against a recent Android release, and moves that floor up a notch at the end of August each year. Submit below the line and the Console refuses the upload before review even starts. Nobody looked at your app, so there is no reviewer to explain what to change.

Declarations sit in the same category. If the data safety form disagrees with what the app actually collects, the submission comes back. Using the advertising identifier without declaring it stops you as well. An app that lets people create an account has to let them request deletion from inside the app, and Google additionally wants a public deletion URL that opens without a login. A privacy policy URL is table stakes on both stores.

None of this measures engineering skill. If the app was built by an agency or a contractor, check whose job these declarations were. It is common for the code to be finished while the work inside the store account sits unclaimed and both sides assume the other has it.

The App That Is Only the Website

A web view wrapped in a shell gets stopped not because the technique is bad but because it ships the browser experience a second time. Apple files this under minimum functionality. Clearing it means something that only works as an app, notifications, offline storage, camera, location, has to sit inside the actual flow people use. Bolting one on after a rejection is late and looks like exactly what it is. Raising it while the app is still being scoped costs nothing.

Planning as if the First Submission Passes

Treating review as a single pass when you set a launch date puts the whole schedule on one roll. A rejection adds the fix and then adds the wait for the queue again, and that queue is not something the build team can speed up. When something fixed sits behind the launch, a campaign or an event, the only lever left is submitting earlier. One rejection is ordinary and worth no drama. The same rejection arriving three times is different: at that point the answer is not another pass through the guidelines but a look at how the app is put together.

One Forwarded Email Is Enough

The notice you received plus the name of the app is a whole first conversation. Weple’s app care covers store policy and rejection handling as a standing monthly job, so the work starts by reading your rejection against the guideline text and sorting it: new build, review note, or a declaration inside the console. Never having shipped to a store before changes nothing about how we start. What the monthly plan covers is set out on the pricing page. If the same reason has now come back twice, send that history along with it.