The short answer: App Store expedited review is a request for urgent review, not a separate approval standard. First submit in App Store Connect, then ask Apple to expedite the already-submitted item. Explain genuine urgency with verifiable facts; Apple decides based on availability and demand.
When is expedited review appropriate?
Apple’s App Review guidance identifies extenuating circumstances such as a critical bug fix or an app directly associated with an upcoming event. A missed internal deadline is not the same as evidence of a user-facing emergency.
For a critical bug, describe what is broken in the version currently live on the App Store. Apple specifically asks for reproduction steps for that live version. Explain the affected workflow and user impact, then identify the submitted update containing the fix. Do not present a bug found only in an unreleased build as a live incident.
For an event, identify the actual event, its date, and the app’s direct relationship to it. Explain which feature attendees or participants need and why the timing matters. Apple advises planning and scheduling releases ahead where possible; an event is not a substitute for preparation.
If you cannot explain urgency accurately, use the normal review process. Do not manufacture an event or inflate a minor defect into a critical outage.
How to request App Store expedited review
Follow the sequence in Apple’s Request expedited review help:
- Prepare a reviewable submission. Select the correct build and complete the required information in App Store Connect. In App Review Information, add necessary instructions in Notes. For account-based features, provide a working demo account or a fully featured demo mode so reviewers can access them.
- Submit for review first. Uploading a build or preparing a submission is not enough. Confirm that the item has actually been submitted. Only already-submitted items can be considered for expedited review. See our App Store Connect guide if the submission flow is unfamiliar.
- Open Apple’s official form. Sign in to Request an Expedited App Review, then select the app and platform. This is Apple’s request form, not a separate priority button we can enable for you.
- Explain the urgency. Identify the submitted version and build, state the critical bug or event facts, and provide the relevant evidence below. Keep the request short enough that the reason is immediately clear.
- Monitor review communications. Watch App Store Connect and the email associated with the request. Keep a team member available to answer questions and keep the review environment working.
Do not put production passwords, customer data, or private credentials into a reusable request template. Provide reviewer access through the appropriate App Review Information fields, not a public document.
Evidence checklist before you send
Use this as a preparation checklist, not a claim that every bullet is a mandatory form field:
- Submission identity: app name, Apple ID, platform, submitted version, build number, and current submission status.
- One clear reason: critical live bug or a specific event, described without marketing language.
- Bug evidence: live App Store version, device and OS context, exact reproduction steps, expected versus actual behavior, and known user impact. Label estimates as estimates.
- Fix verification: what changed in the submitted build and how you tested the affected workflow.
- Event evidence: actual event name, date and time zone, a verifiable reference where available, and the app’s direct role in the event.
- Review readiness: necessary Notes, tested demo access or demo mode, reachable services, and a contact who can answer promptly.
Separate observation from inference. “The checkout flow fails after step three on the live version” is more useful than “everyone is blocked” if you do not have evidence for the latter.
Hypothetical request templates
These are fictional drafting aids, not AirBuild customer cases or successful requests. Replace every placeholder with accurate facts and omit anything you cannot substantiate. No credentials belong here.
Critical bug fix
App: [name / Apple ID]; platform: [platform]
Submitted update: [version / build]; status: [current status]
We request expedited review for a critical bug affecting
[workflow] in the live App Store version [version].
User impact: [verified impact; scope and limits of evidence].
Reproduce in the current live version:
1. [starting condition, device / OS]
2. [action]
3. [actual result versus expected result]
Submitted build [build] fixes [cause or behavior].
Verification: [tests performed and results].
Review access and instructions: [location in App Review Information].
Contact: [responsible team contact].
Event-related submission
App: [name / Apple ID]; platform: [platform]
Submitted version / build: [version / build]
Event: [actual name]
Date and time zone: [date / time / zone]
Reference: [verifiable event reference, if available]
Direct relationship: [how the app supports participants].
Time-sensitive need: [specific feature needed for this event].
We request expedited review of this submitted item because
[factual reason timing matters].
Review instructions: [location in App Review Information].
Contact: [responsible team contact].
What if the app is rejected?
Expediting addresses urgency; it does not overturn a rejection or waive the App Review Guidelines. Choose the response that matches the problem:
- Missing information or reviewer question: reply in App Store Connect with the requested explanation or access instructions. Address outstanding requests before appealing.
- A real product or metadata issue: fix it, test it, and resubmit as appropriate. If the new submission has genuine urgency, explain that separately in an expedited request.
- A misunderstanding about compliance: consider an App Review Board appeal. Explain specifically why the app complies and address the cited concern. Apple says to submit only one appeal per rejected submission.
Do not use an expedited request as an appeal letter. A faster review cannot resolve an inaccessible demo account or an unfixed policy issue.
Plan for uncertainty, not a promised deadline
Apple evaluates expedited requests according to availability and demand. Neither submitting the request nor having a valid reason guarantees acceptance, completion by a chosen deadline, or approval. General review-time figures are not a service-level agreement for your app.
Keep stakeholders informed, maintain a contingency plan for the event or affected users, and verify release settings separately from review status. Approval and making an update available are different steps.
If you are preparing a web project for iOS, AirBuild’s bring-your-project options are a separate development workflow—not privileged access to Apple’s review queue. Neither AirBuild nor using SwiftUI grants automatic compliance. The practical advantage you control is a tested app, complete review information, and an honest, well-evidenced request.