Your app is in App Store Connect with a serious security defect: a hard-coded API key that just landed in a public release bundle, a Supabase row level security policy that exposed user records, or an SDK update that fixes a CVE you only learned about an hour ago. Standard review is fast in 2026, but fast is not the same as Friday night emergency fast, and Google Play has no public expedite button at all. The question for the next ninety minutes is whether to ask Apple for an expedited App Review, what to put in the form, and what to do on the Google Play side where the same word does not even apply.
Short answer
Apple grants expedited App Review for critical security fixes through the Contact Us form at developer.apple.com/contact/app-store, reachable from Apple's App Review distribution page. Select Expedited App Review, identify the build in App Store Connect, and describe the security defect with specifics: what is exposed, who is affected, and what your patch changes. Apple states that 90 percent of submissions already clear in under 24 hours, so expedite is for cases where the standard queue is still too slow.
What you should know
- Apple's expedite path is a form, not a button inside the app entry. It lives under Contact Us on the App Review page; the option is named Expedited App Review.
- Apple lists two qualifying reasons publicly: critical bug fixes and event-tied launches. Security defects fit under the critical bug umbrella.
- Google Play has no parallel button. The Help link inside Google Play Console is the only escalation path, and Google does not commit to a turnaround.
- The decision is human and conservative. Reviewers reject most expedite requests; the strongest cases name a CVE, a public disclosure, or a clear data exposure.
- Each expedited approval is per submission, not per app. A future security patch starts the process over.
- Standard App Review is already fast. Per Apple's distribution page, 90 percent of submissions are reviewed in under 24 hours.
When does Apple actually grant an expedited App Review for a security fix?
Apple does not publish acceptance criteria, but the public language on the App Review distribute page names critical bug fixes as one of the two qualifying cases for expedited review (the other being event-tied launches). A security defect that exposes user data, leaks credentials, or breaks a promise made under App Tracking Transparency fits cleanly under critical bug. What does not fit is a polish change framed as a security update, a refactor with no exploitable surface, or a regression that affects a tiny subset of devices.
The judgement reviewers seem to apply, based on patterns reported on the Apple Developer Forums and Apple Community threads, is whether the patch reduces a measurable harm to users that would persist if review took its normal course. Apple has stated publicly that 90 percent of submissions clear in under 24 hours, so the implicit standard is harm avoided in the next 24 hours specifically.
Three patterns get approved more often:
- A named CVE in a third-party SDK shipped with your app, where you can cite the CVE number and the SDK upgrade that fixes it.
- A live data exposure visible to the public, such as a misconfigured Supabase row level security policy, a leaked API key in a release bundle, or an open S3 bucket.
- A regression in your own code that bypasses authentication, leaks a session token, or breaks a payment safeguard.
Three patterns get rejected:
- A pre-emptive hardening pass with no current exploit and no incident.
- A privacy manifest update or App Tracking Transparency tweak, since those have their own review path and are not user-facing emergencies.
- A general performance improvement that the developer rebrands as a security fix.
What information should go in the expedited request form?
The form is short, which makes the content of each field decisive. Use plain language, name the defect, and assume the reviewer has thirty seconds to decide.
| Field | What to put | Why it matters |
|---|---|---|
| App and version | Exact app name, bundle ID, and the version number currently in review | Reviewer needs to match the request to a specific build in the queue |
| Issue summary | One sentence: what is broken, who is exposed | Sets urgency context before the reviewer reads detail |
| Technical detail | CVE number, repository issue link, SDK version, exact code path | Lets the reviewer verify the defect without a back-and-forth |
| User impact | How many users, what data, what action they cannot take safely | Establishes whether the harm is severe enough to skip the queue |
| Fix description | What the patch changes, with file paths or method names where helpful | Shows that the new build addresses the specific issue, not a sibling one |
| Deadline justification | Why the standard 24 hour queue is not fast enough | Separates real urgency from operational inconvenience |
The single most common failure mode is vagueness in the issue summary. A line like critical security update is filler. A line like OAuth state parameter is not validated in version 3.2.4, allowing account takeover, fixed in 3.2.5 by adding state verification in AuthCallback.swift is the kind of summary that gets read in full.
For builders who want an external automated read of the build to confirm the patch actually closes the vulnerability before the expedite request goes in, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASTG for no-code and vibe-coded apps, including checks for hard-coded secrets, exposed credentials, and missing privacy manifests.
How does Google Play handle urgent security patches without an expedited button?
Google has not published an expedite mechanism for Google Play Console. The path that works in practice has three pieces. The first is the Help link inside Play Console: open Help, search for Submit, then select Contact us or Get help on a specific submission. The form asks for the app and what you need. Use it, with the same specificity Apple expects.
The second piece is managed publishing. Switch your release track to managed publishing before the security patch goes in. A managed release stays in your control after Google's review completes, so you can stage the patch and publish the moment review finishes rather than waiting for the auto-publish window. The Play Console publishing overview explains that managed publishing puts release timing in your hands.
The third piece, used by teams who have built a relationship with Google through prior support tickets or Play Partner Manager access, is reaching out to the partner manager directly. This option is not available to most independent developers. For everyone else, the Help form is the only path, and a careful explanation of the security issue (CVE number, exposure scope, fix) appears to move the request faster than a generic urgent message.
Google's published pre-review checks page notes that pre-review automated checks usually take less than 15 minutes and that passing them is not the same as passing the full review. Most updates clear within hours; some accounts and some app categories see review windows of up to seven days, especially after a policy strike or account flag.
How long does an expedited review take in practice?
Independent developer reports across Apple Developer Forums and Apple Community threads suggest an expedited App Review decision usually returns within 4 to 12 hours during weekdays, and within 24 hours including weekends. That decision is whether the expedite is granted, not whether the build itself passes. A granted expedite places the build at the front of the human reviewer queue; the review then runs at normal speed, which in many cases finishes within the same business day.
On Google Play, the picture is different. The Help form yields a response from a support agent, who may or may not move the submission. Some teams report a one hour acknowledgement and a same-day publication. Others get a templated reply saying the review will complete on its normal schedule.
The table below sketches what to expect on each store. Treat the times as directional, based on patterns reported by developers, not as a guarantee.
| Aspect | Apple App Store | Google Play |
|---|---|---|
| Public expedite mechanism | Yes, Contact Us form on the App Review page | No |
| Named qualifying reasons | Critical bug fix, event-tied launch | None published |
| Typical decision time on the request | 4 to 24 hours | Variable, depends on the support agent |
| What to attach | App, version, CVE or technical detail, user impact, fix description | CVE, exposure scope, fix, regulator or breach context |
| Approval frequency | Conservative, most requests rejected | Conservative, no public statistics |
| Per-submission scope | Yes, each new submission needs its own request | Same, plus managed publishing as the in-house lever |
The expedite request only changes the position in the queue. The build still goes through Apple's automated checks: the privacy manifest scan that returns ITMS-91061, the required reason API scan that returns ITMS-91053, the App Transport Security validator, and the entitlement checks. A build that fails any of these will fail under an expedited review the same way it would under standard review. Submit a build you have already validated locally, ideally with Apple's App Review Guidelines open in a second tab so the patch does not introduce a Guideline 5.1.1 or Guideline 4.2 regression.
What to watch out for
- Each expedite is per submission. A future security patch starts the process over.
- Burning the credit on a non-emergency lowers the chance of approval next time you have a real fire.
- Automated checks still run. An expedite request does not skip the privacy manifest check, the missing API declaration check that returns ITMS-91053, or the binary validation that catches signing errors. Validate the build locally first.
- Apple does not respond to expedite requests with reasons for rejection in most cases. Apply once, and if rejected, work the issue through the standard channel.
- Google Play managed publishing must be enabled before the security patch is submitted, not after. Flipping the toggle on a submission already in review has no effect on that submission.
- A security patch that also bumps the minimum iOS or Android version, or that adds a new SDK, is no longer a narrow fix. Apple and Google both treat scope expansion as a reason to apply standard review depth even when expedite is granted.
Key takeaways
- Apple's expedited App Review is a real path with a published form. Use it only when a measurable harm to users is in flight or imminent, and describe that harm in plain terms.
- The form should name the app and version, describe the security defect with specifics, name the affected users, and describe the fix in enough detail for a reviewer to verify it in under a minute.
- Google Play does not publish an expedite button. The Help link inside Play Console, plus managed publishing, is the closest path most teams have.
- Standard App Review is already fast: Apple states that 90 percent of submissions clear in under 24 hours, so the cost of the standard queue is often smaller than the cost of a poorly justified expedite request.
- Some teams use platforms like PTKD.com (https://ptkd.com) to run a pre-submission scan that confirms the security patch actually closes the vulnerability and does not introduce a Guideline 5.1.1 or ITMS-91053 regression before the expedite request is filed.
