How do I request expedited App Review for a critical security bug?

Your app is in App Store Connect or Google Play Console with a security defect that is already exposed: an OAuth state parameter that is not validated, a Supabase row level security policy that leaks user records, a hard-coded admin key that landed in a public release, or an SDK update that closes a published CVE you only learned about two hours ago. Standard review is fast in 2026, but fast is not the same as before-the-news-cycle fast. The next question is whether Apple will grant an expedited App Review, how to make the request count, and what to do on the Google Play side where the word expedite does not officially apply.

Short answer

Apple grants expedited App Review for critical bug fixes through the Apple App Review distribute page and its Contact Us form at developer.apple.com/contact/app-store/?topic=expedite. Apple states that 90 percent of submissions are reviewed in less than 24 hours, so expedite is reserved for defects where 24 hours is still too long. A security bug with a working exploit, a CVE, or a verifiable public disclosure fits the critical bar. The request must name the app and version in review, the specific defect, the scope of user exposure, and steps to reproduce on the version currently in App Store Connect.

What you should know

• Apple's expedited path is a form, not a switch. It lives under Contact Us on the App Review page, with the topic set to expedite.
• Apple's own language names two qualifying reasons: critical bug fixes and event launches. A security defect with an active exposure qualifies under the critical bug umbrella.
• Reviewers approve specific requests, not urgent ones. A line like critical security update is filler; a line like OAuth state parameter is unvalidated in version 4.1.2 allowing account takeover, fixed in 4.1.3 in AuthCallback.swift is what gets read.
• Google Play has no public expedite button. The Help link inside Play Console is the only escalation surface for most developers.
• Managed publishing matters more than the support ticket on Google Play. It lets you push the patched build the moment Google's review clears.
• Apple does not publish a quota, but each request lands on a visible history. Reviewers see prior asks; repeated requests for non-critical issues appear to slow later reviews, based on patterns reported on the Apple Developer Forums.
• Apple states publicly that 90 percent of submissions are reviewed in less than 24 hours. Expedite is the lane for the cases where that window is still too slow.

What separates a critical security bug from a security improvement?

Apple does not publish an acceptance criterion, and the line is sharper than most expedite write-ups admit. The honest test is whether the defect produces measurable harm to users that would persist if the patch waited through the standard 24-hour queue. Three signals push a request from improvement into critical: a working exploit (public or private), a known scope of user exposure (count of records, count of accounts, type of data), and a fix that is narrow and verifiable.

Three patterns get approved more often:

1. A named CVE in a third-party SDK shipped in your build, where you can cite the CVE number, the vulnerable version, and the patched version.
2. A live data exposure that is already visible to the public: a misconfigured Supabase policy, an open S3 bucket reachable from the app, an analytics endpoint leaking session tokens.
3. A regression in your own code that bypasses authentication, breaks a payment safeguard, or sends user data to the wrong tenant.

Three patterns get rejected:

1. A pre-emptive hardening pass with no current exploit and no incident, often framed as proactive security.
2. A privacy manifest update or App Tracking Transparency tweak. Apple already routes those through a separate path and treats them as compliance, not emergency.
3. A general performance or refactor PR rebranded as a security fix to push it through faster.

The distinction matters because Apple's reviewers see your expedite history on the account. A weak request that gets denied does not blacklist you, but it does shape the tone of the next ask. Save the lever for the cases that need it.

What information should the expedite request actually contain?

The form is short, which makes each field decisive. Apple's public guidance asks for the bug and the steps to reproduce on the current version. In practice, the requests that move fastest carry six pieces of information.

The single most common failure mode is vagueness in the defect summary. The second most common is forgetting that Apple asks for reproduction steps on the version currently in review (the broken one), not the patched build. Both are easy to fix before submitting.

For builders who want an external automated read of the patched build to confirm the fix landed and no regressions slipped in before the expedite request goes out, 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, missing privacy manifests, and common authentication regressions.

How does Google Play handle a critical security bug 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 Play Console Help form. Open Help, search for Submit, and select Get help on a specific submission. The form asks for the app and what you need. Use it with the same specificity Apple expects: name the defect, cite the CVE or disclosure, describe user exposure, link to the fix.

The second is managed publishing. The Google Play managed publishing documentation confirms that updates are processed as usual and, once approved, the developer controls exactly when the changes go live. Switching the release to managed publishing before the security patch goes in keeps the patched build under your control after review clears, so you can push the moment review finishes rather than waiting for the auto-publish window or a server rollout.

The third, available to a small fraction of developers, is direct contact with a Play Partner Manager. Most independent developers and small studios do not have this access, and asking support for it during an incident is the wrong moment. For everyone else, the Help form plus managed publishing is the pair that matters.

Google's pre-review automated checks typically complete in under 15 minutes for established apps. The longer wait sits in the human review stage, which can stretch from hours to seven days depending on account history, app category, and any recent policy strikes. A clear, specific Help ticket about a security defect appears to move faster than a generic urgent request, but Google does not commit to a turnaround.

How long does an expedited review actually take in practice?

Apple does not publish expedited review timing, and the public number to anchor against is the 90 percent in under 24 hours figure for standard review. Developers reporting on the Apple Developer Forums describe approved expedites landing in roughly 2 to 8 hours during business hours in the reviewer's region, with weekend and holiday windows running longer. Automated checks (privacy manifest scan, missing API declaration scan, binary validation) still run during expedite, and any failure there stops the build the same way it would in a standard submission. The speed gain is at the human review stage, not the static analysis stage.

Three pre-flight checks reduce the chance of a wasted expedite:

1. Confirm the patched binary actually closes the defect on a real device, not just in the simulator.
2. Confirm the privacy manifest still validates and the API declarations are still present, because expedite does not skip those checks.
3. Confirm the build's increment version is one above the broken build in App Store Connect, otherwise the submission queues behind itself.

What to watch out for

The most damaging mistake during a security incident is rushing a patch that introduces a regression. An expedited approval on a build that breaks login or removes a permission Purpose String costs more time than a careful standard submission would. A second common mistake is using expedite for issues that are not exposed, like a defect found in QA that has not shipped. Apple's reviewers are looking for harm avoided in the next 24 hours specifically, and a defect that is not yet in production does not meet that bar.

A third mistake is overstating scope. Reviewers handle thousands of requests; inflated impact language (every user is at risk when the defect only affects a feature 3 percent of users open) reads as a credibility flag and can land the request in the slow pile. Plain numbers, even small ones, move faster than dramatic ones.

Finally, do not submit two expedite requests for the same review attempt expecting reinforcement. A second request usually replaces the first in the reviewer's queue rather than stacking, based on patterns reported by developers. One careful request is the right call.

Key takeaways

• Treat Apple's expedited App Review form as a tool for harm avoided in the next 24 hours, not a fast lane for any urgent feeling. The bar is a defect with a working exploit or a verifiable public exposure.
• The request that moves fastest names the app and version, the defect, the user impact, the steps to reproduce on the version currently in review, and the fix. Vagueness in any of those fields slows the response.
• On Google Play, managed publishing is the lever you control. Pair it with a specific Help ticket that cites a CVE or public disclosure.
• A patch that introduces a regression cancels the speed gain. Run a pre-submission scan on the patched build before the expedite request goes out; some teams outsource that check to platforms like PTKD.com (https://ptkd.com), which scans compiled IPA and AAB builds against OWASP MASVS for storage, network, and authentication regressions.
• Save expedite for the cases that need it. Each request lands on a visible history with Apple's reviewers, and the lever works best when the account uses it sparingly.