You can request an expedited app review from Apple, but only for a critical bug or an event you are part of.
An expedited app review is an exception, and Apple publishes exactly two circumstances for it: you are fixing a critical bug in your app, or you are releasing to coincide with an event you are directly associated with. You ask through a form linked from Apple's App Review page, under the heading Expedited reviews. Google Play publishes no equivalent request. Before you file anything, look at the baseline you are trying to beat: Apple's App Review page, read on 3 October 2026, says that on average 90 percent of submissions are reviewed in less than 24 hours. Most people searching for how to speed up app review are already inside that window. If your problem is when the date cannot move, the request is worth making, as long as you plan for it being refused.
What follows is the published criteria, the detail Apple asks you to include, the things it does not publish, and what the Android side gives you instead. Every step, field name and figure here came from Apple's or Google's own documentation, opened on 3 October 2026. Where neither company publishes a number, this page says so rather than supplying one.
Check whether your case qualifiesThe short version
It is an exception, not a queue you can jump on request.
The request costs nothing and takes a few minutes, which is exactly why Apple frames it around extenuating circumstances. A crash that is live for your users is one. An event you are genuinely part of, with a date, is the other. A launch date you picked, a client deadline and a demo next week are none of them, and a request that says so is a request with nothing to stand on.
Apple does not publish how many requests it grants, how fast a granted one moves, or a cap on how many you may file. We looked for all three on 3 October 2026 and found none of them on any page you can read without signing in. Any page that hands you those numbers invented them.
What Apple will expedite, in Apple's own words
Apple's App Review page lists expedited reviews under extenuating circumstances and names two. For a critical bug fix, it asks you to include the steps to reproduce the bug on the current version of your app. For an event related app, it asks that your request include the event, the date of the event, and your app's association with the event. Those items are the whole published test. Write them in the request itself.
The same page carries a link labelled Request an expedited review, which points at Apple's App Store contact form with the topic set to expedite. Opening that link on 3 October 2026 redirected to Apple's sign in, so the form sits behind your developer account and its fields cannot be read from outside it. The public page does not state which account role may file the request, so if you are not the Account Holder, check that before you promise anyone a submission went in.
Read the order of Apple's event wording closely, because it is the part people get backwards. Apple recommends you plan and schedule the release of your app in App Store Connect, and treats expediting as what you do if your app is still in review and the launch of your event is quickly approaching. So an Apple expedited review request is a rescue for something already in the queue. If you have not submitted yet, submitting is the faster move.
One paragraph further down the same page is worth more than the expedite form to a lot of readers. If you are submitting a bug fix update and review finds additional issues, you can resolve those with your next submission, as long as there are no legal or safety concerns. Apple says to reply to the offer message in App Store Connect and say you would like the current submission approved. That turns two round trips into one, which is usually what the person asking to expedite app store review actually needs.
Apple Developer, App Review: review status, expedited reviews and appeals (read 3 October 2026)
Work out whether yours qualifies before you file it
Run your situation against the two published circumstances first. The checklist below is Apple's criteria and the detail each one needs, not our opinion of what sounds urgent. If nothing lights up, the request is not the lever, and the time is better spent making the submission complete so it clears the normal queue on the first pass.
One test that costs you nothing: can you write the reproduction steps, or the event name and date, in two sentences a stranger could follow? If you cannot, the reviewer reading your request cannot verify the circumstance either.
If the submission is already in and you are watching the status move, after you submit to the app store covers what each state means and which parts you can still change without starting over.
Check it
Does your case match what Apple publishes?
Apple names two circumstances on its App Review page. Tick the rows that are true of your submission.
No published reason yet
Tick what is true of your submission today. Apple publishes two circumstances and nothing else.
Google Play has no expedite, it has managed publishing
Google publishes no expedited review request at all. There is no form, no criteria and no published turnaround to beat, and we checked Play Console Help for one on 3 October 2026. What Google does publish is a range: processing can take a few hours or up to seven days, or longer in exceptional cases, depending on the review time your app is subject to. Its own advice on the same page is a buffer of at least a week between submitting and going live. The asymmetry is the useful fact here. On iOS you can ask; on Android you can only be early.
What Google gives you instead is control of the publish moment. With managed publishing on, approved changes wait for you. The path, confirmed in Google's documentation on 3 October 2026, is the Publishing overview page in Play Console, then the Managed publishing status section, then Turn on managed publishing, then Save. Submitted work appears under Changes in review, moves to Changes ready to publish once it is approved, and goes live within a few minutes of you selecting Publish changes. Review happens before your date instead of on it.
Two limits matter if you are reading this in a hurry. Your app must already be available on Google Play to use managed publishing, so it is no help on a first release. And the review turnaround is counted from the last submitted change, so sending one more change while things are in review can push your app to the back of the review queue. That is the opposite of expediting, and it is the mistake people make at two in the morning.
If what you really need is the build in front of people today, both stores have a track that moves faster than the store queue. Google says app updates on internal test tracks are not subject to review in most cases, with two exceptions: a first roll out on an internal test track must be reviewed, and so must the submission after a rejection. Apple's TestFlight page says external testers need your first build approved by App Review for TestFlight, and sets no such requirement for internal testers, who can be up to 100 members of your own team. Getting real people onto a build is app testing before launch, and on a bad week it is also your release plan.
Google Play Console Help, control when app changes are reviewed and published (read 3 October 2026)
What actually moves a submission along
Completeness is the only lever Apple quantifies. It says that on average over 40 percent of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information, and that an incomplete submission may be delayed or may not pass. The App Review Information section of App Store Connect is where you remove that risk: a demo account with a working username and password, the specific settings a feature needs, and a demo video or the hardware itself if a feature needs an environment that is hard to replicate. Anything that cannot run on a reviewer's own device needs that video.
You can also watch and talk, in the two places Apple names today. Review status sits in the Apps section of App Store Connect and in the App Store Connect app for iPhone and iPad. Submissions and messages from App Review sit on the App Review page within Apps, and Apple says you can visit that page at any time, even with no active submissions or conversations. You can remove items with issues from a submission and continue with the items App Review accepted, which beats holding the whole release hostage to one screenshot.
If the answer comes back as a refusal rather than a delay, expediting is finished and you are in a different procedure with its own rules, including one appeal per submission that did not pass. That is if it is rejected instead, and it is a different page.
Expedited review: what each store actually publishes
| What you want to know | Apple App Store | Google Play | Where this comes from |
|---|---|---|---|
| A way to ask for a faster review | Yes, a request form linked from the App Review page | No request is documented | Apple App Review page; Play Console Help |
| Reasons that qualify | Critical bug fix, or an event you are directly associated with | Not applicable, there is no request | Apple App Review page |
| Published review time | 90 percent of submissions in less than 24 hours on average | A few hours up to seven days, or longer in exceptional cases | Both, read 3 October 2026 |
| How often requests are granted | not published | not applicable | neither store publishes a figure |
| When the date cannot move | Schedule the release, submit early, expedite only if still in review | Turn on managed publishing and allow a week of buffer | Both, read 3 October 2026 |
Who files the request when a builder made the app
This part cannot be delegated to a tool. The request is a short account of your circumstances, filed from your own developer account, and what decides it is whether Apple agrees the circumstance is one of the two it publishes. No build pipeline changes that.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then uploads to App Store Connect and TestFlight and publishes to Google Play internal testing. It is $25 a month, with no free plan and effort based credits. It does not press submit for you: Apple's guideline 4.2.6 puts submission on the person whose app it is, so the App Store Connect connection is owner or admin only and any expedite request is yours to file.
The practical consequence for a fixed date is the same whoever built the app. Upload days before you need it, not hours. On iOS you are joining a queue with a published 24 hour shape and an unpublished tail. On Android the published range reaches a week, and nobody will shorten it for you. A build sitting in TestFlight on Monday is worth more than a perfectly argued request on Friday.
Questions people ask about expedited app review
Submit the version in App Store Connect first, then open the link labelled Request an expedited review on Apple's App Review page and sign in with your developer account. Give one of the two circumstances Apple publishes and the detail it asks for: the steps to reproduce the bug on the current version of your app, or the event, the date of the event and your app's association with it. Checked on Apple's own page on 3 October 2026.
Get the build uploaded before the date arrives
Write down the date you need, subtract a week, and have a build in TestFlight and in Google Play internal testing by then. An expedite request is what you file when that plan already failed.
Start building