Quick answer
Read the exact guideline number in the rejection, then reply in App Store Connect before you change anything. Apple says you can correspond with App Review to resolve issues before resubmitting a build. On Google Play, fixing the problem is not enough on its own, because your changes are not sent for review automatically and you have to press Send for review yourself.
What should you do first?
> Quick answer: Read the guideline number, then reply before you change anything. Apple lets you correspond with App Review to resolve issues without resubmitting a build.
Most people delete the asset, upload a new one, and resubmit blind. That's the slow route.
I read Apple's and Google's current review documentation before writing this, because the reply and resubmit steps differ in a way that costs real days.
Most people delete the asset, upload a new one, and resubmit blind. That's the slow route.
I read Apple's and Google's current review documentation before writing this, because the reply and resubmit steps differ in a way that costs real days.
A rejection is not a verdict
It's a message with a person behind it, and you can answer it.
Apple's review page says that when a submission doesn't pass, the details include the specific guidelines it didn't follow, and that you can correspond with App Review to resolve the issues before resubmitting the build.
That last clause is the one people miss.
You do not have to guess, change something and try again. You can ask.
And a reply costs you nothing. The worst case is that the reviewer repeats the guideline, which still tells you more than guessing did.
Apple's review page says that when a submission doesn't pass, the details include the specific guidelines it didn't follow, and that you can correspond with App Review to resolve the issues before resubmitting the build.
That last clause is the one people miss.
You do not have to guess, change something and try again. You can ask.
And a reply costs you nothing. The worst case is that the reviewer repeats the guideline, which still tells you more than guessing did.
Find the guideline number
Every Apple rejection cites one. It's the difference between a five minute fix and a week of flailing.
Apple says that on average over 40 percent of unresolved issues relate to guideline 2.1, App Completeness.
That covers crashes, placeholder content and incomplete information, which includes a missing demo account.
So before you assume your screenshots were the problem, check whether the reviewer simply couldn't get into the app.
The number is in the message, usually in the first line. Search the guidelines for it and read the actual text rather than somebody's summary.
Apple says that on average over 40 percent of unresolved issues relate to guideline 2.1, App Completeness.
That covers crashes, placeholder content and incomplete information, which includes a missing demo account.
So before you assume your screenshots were the problem, check whether the reviewer simply couldn't get into the app.
The number is in the message, usually in the first line. Search the guidelines for it and read the actual text rather than somebody's summary.
Metadata rejections versus build rejections
Two different problems that arrive looking identical.
A metadata rejection is about your screenshots, description, icon or age rating. The binary is fine.
A build rejection is about the app itself, and it needs a new build.
Work out which one you have before you rebuild anything, because rebuilding for a metadata problem wastes the whole review cycle.
The giveaway is which asset the message names. If it cites a screenshot, a description or an age rating, your binary was never the problem.
A metadata rejection is about your screenshots, description, icon or age rating. The binary is fine.
A build rejection is about the app itself, and it needs a new build.
Work out which one you have before you rebuild anything, because rebuilding for a metadata problem wastes the whole review cycle.
The giveaway is which asset the message names. If it cites a screenshot, a description or an age rating, your binary was never the problem.
How fast Apple actually reviews
I checked Apple's own figure for this. On average 90 percent of submissions are reviewed in less than 24 hours.
That's fast enough that a same day reply and resubmit often ships the next morning.
It also means a rejection costs you a day, not a week, which changes how much you should panic.
Incomplete submissions are the exception. Apple says those may be delayed or may not pass at all.
So the cost of asking a question is usually one extra day. The cost of guessing wrong twice is three.
That's fast enough that a same day reply and resubmit often ships the next morning.
It also means a rejection costs you a day, not a week, which changes how much you should panic.
Incomplete submissions are the exception. Apple says those may be delayed or may not pass at all.
So the cost of asking a question is usually one extra day. The cost of guessing wrong twice is three.
Google Play works on a different clock
Google's own guidance says processing can take a few hours or up to seven days, and longer in exceptional cases.
It recommends building in a buffer of at least a week between submitting and going live.
So an Apple style same day turnaround is not the expectation here.
Plan a Play release around that week, not around your launch date.
New developer accounts and sensitive permission requests sit at the slow end of that range. Budget accordingly on a first release.
It recommends building in a buffer of at least a week between submitting and going live.
So an Apple style same day turnaround is not the expectation here.
Plan a Play release around that week, not around your launch date.
New developer accounts and sensitive permission requests sit at the slow end of that range. Budget accordingly on a first release.
The Play mistake that costs you days
This is the single most useful thing on the page.
When a Play submission is rejected and you fix it, your changes are not sent for review automatically. You have to open the Publishing overview page and press Send for review.
People fix the problem, watch the console, and wait for a review that was never queued.
Check that page every time. It takes five seconds.
The page tells you plainly whether anything is waiting to be sent. Nobody looks, because fixing the problem feels like the last step.
When a Play submission is rejected and you fix it, your changes are not sent for review automatically. You have to open the Publishing overview page and press Send for review.
People fix the problem, watch the console, and wait for a review that was never queued.
Check that page every time. It takes five seconds.
The page tells you plainly whether anything is waiting to be sent. Nobody looks, because fixing the problem feels like the last step.
Do not keep editing while it is in review
Google states that the review turnaround is counted from the last submitted change.
So every extra edit you make while waiting restarts the clock and can push you to the back of the queue.
That's the opposite of what instinct tells you to do.
Make all your fixes, send once, and then leave the listing completely alone until you hear back.
Keep a list of the things you want to change instead. Ship them in the next release.
So every extra edit you make while waiting restarts the clock and can push you to the back of the queue.
That's the opposite of what instinct tells you to do.
Make all your fixes, send once, and then leave the listing completely alone until you hear back.
Keep a list of the things you want to change instead. Ship them in the next release.
When the problem really is the screenshots
Two families of cause, and they fail at different moments.
Technical failures happen at upload. Wrong dimensions, an alpha channel, the wrong colour profile.
Content failures happen at review. A claim you can't support, a competitor's name, content that doesn't match the app.
We covered the upload errors in the screenshot rejection post, and what you're allowed to show in the screenshot content post.
Technical failures happen at upload. Wrong dimensions, an alpha channel, the wrong colour profile.
Content failures happen at review. A claim you can't support, a competitor's name, content that doesn't match the app.
We covered the upload errors in the screenshot rejection post, and what you're allowed to show in the screenshot content post.
Writing a reply that works
Short, specific, and about the guideline rather than about your feelings.
Say what you changed, or ask exactly what would satisfy the guideline if you genuinely don't know.
Attach a screen recording if the reviewer couldn't reach the feature. Apple explicitly asks for one where a feature needs hardware or an environment that's hard to replicate.
No arguing in the first reply. Arguing is what the appeal is for.
One message, not five. A thread with six replies from you takes longer to read and longer to answer.
Say what you changed, or ask exactly what would satisfy the guideline if you genuinely don't know.
Attach a screen recording if the reviewer couldn't reach the feature. Apple explicitly asks for one where a feature needs hardware or an environment that's hard to replicate.
No arguing in the first reply. Arguing is what the appeal is for.
One message, not five. A thread with six replies from you takes longer to read and longer to answer.
The appeal, and when to use it
Apple runs an App Review Board for the case where you believe your app was misunderstood or treated unfairly.
Three rules from Apple's own page. Give specific reasons why you comply. Submit only one appeal per rejected submission. Respond to any requests for more information before appealing.
That middle rule matters. You get one shot per rejection, so make it count.
An appeal is for a disagreement about the guideline, not for a fix you could have made in ten minutes.
Write it the next morning, not the same night. Appeals written angry read as angry.
Three rules from Apple's own page. Give specific reasons why you comply. Submit only one appeal per rejected submission. Respond to any requests for more information before appealing.
That middle rule matters. You get one shot per rejection, so make it count.
An appeal is for a disagreement about the guideline, not for a fix you could have made in ten minutes.
Write it the next morning, not the same night. Appeals written angry read as angry.
Expedited review is real and narrow
Apple allows a request to expedite for extenuating circumstances, and names two.
A critical bug fix, where you must include steps to reproduce the bug in the current version.
An event related app, where you must give the event, the date and your association with it.
Use it sparingly. It's a favour, not a feature, and it's the wrong tool for a screenshot that got bounced.
Request it too often and it stops working. That's the practical reason to hold it back.
A critical bug fix, where you must include steps to reproduce the bug in the current version.
An event related app, where you must give the event, the date and your association with it.
Use it sparingly. It's a favour, not a feature, and it's the wrong tool for a screenshot that got bounced.
Request it too often and it stops working. That's the practical reason to hold it back.
The bug fix exception nobody knows
Worth keeping in your back pocket.
Apple says that if you're submitting a bug fix update and review finds additional issues, you have the option to resolve those in your next submission, as long as there are no legal or safety concerns.
So a new unrelated complaint doesn't automatically block the fix your users are waiting for.
You have to accept the option when it's offered, which means reading the message rather than skimming it.
Apple says that if you're submitting a bug fix update and review finds additional issues, you have the option to resolve those in your next submission, as long as there are no legal or safety concerns.
So a new unrelated complaint doesn't automatically block the fix your users are waiting for.
You have to accept the option when it's offered, which means reading the message rather than skimming it.
Talking to App Review directly
Apple offers thirty minute video appointments about the review guidelines.
You can ask what to expect, how your app aligns with the guidelines, and the reasons behind common rejections.
It's underused, and it's free.
If you've been rejected twice for the same thing and still don't understand why, that's the call to book.
Bring the rejection message and the guideline number with you. A vague question gets a vague answer.
You can ask what to expect, how your app aligns with the guidelines, and the reasons behind common rejections.
It's underused, and it's free.
If you've been rejected twice for the same thing and still don't understand why, that's the call to book.
Bring the rejection message and the guideline number with you. A vague question gets a vague answer.
Fixing assets without a new build
Half the panic around a metadata rejection comes from assuming a whole release cycle is at stake.
On both stores there are routes to change store assets outside a full app update, and knowing which applies saves days.
That's a topic of its own, and we covered it in the screenshots without an update post.
Work out which route you're on before you rebuild anything.
On both stores there are routes to change store assets outside a full app update, and knowing which applies saves days.
That's a topic of its own, and we covered it in the screenshots without an update post.
Work out which route you're on before you rebuild anything.
The order to work in
Read the guideline number. Decide whether it's metadata or the build. Reply before you change anything.
Make every fix at once, then submit once.
On Play, press Send for review and confirm it moved.
Then stop touching it. You can prepare the replacement assets in our editor while you wait, and upload them in one go.
Make every fix at once, then submit once.
On Play, press Send for review and confirm it moved.
Then stop touching it. You can prepare the replacement assets in our editor while you wait, and upload them in one go.
Frequently asked questions
Can I reply to an App Store rejection instead of resubmitting?
Yes. Apple states that when a submission does not pass, you can correspond with App Review to resolve the issues before resubmitting the build. The App Review section on your app's page in App Store Connect is where that conversation happens, and it is usually faster than guessing.
Why is my fixed Google Play listing still not in review?
Because changes are not sent for review automatically after a rejection. You have to open the Publishing overview page and press Send for review yourself. This catches out almost everyone once, and people can wait days for a review that was never queued.
How long does app review take on each store?
Apple says that on average 90 percent of submissions are reviewed in less than 24 hours. Google says processing can take a few hours or up to seven days, and longer in exceptional cases, and recommends a buffer of at least a week before your go live date.
Should I appeal a rejection?
Only if you believe the reviewer misunderstood your app or treated you unfairly. Apple allows one appeal per rejected submission to the App Review Board, and asks you to respond to any requests for information first. For anything you could simply fix, fixing it is faster.
How do I avoid the rejection next time?
Check the asset rules before you upload rather than after. Dimensions, transparency and content claims cause most of the avoidable failures, and our [Play asset checklist](/blog/google-play-store-listing-asset-checklist-2026) walks through each one in order. Keep a short pre upload list of your own and run it every release. Four lines is enough, and it catches the failures that cost a day each.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.