A solo developer's post titled "Apple won't let me show my app" made the rounds this week: his planner app was rejected because "The screenshots do not show the actual app in use in the majority of the screenshots," and his appeal is pending. If you are staring at a rejection of your own, here is the direct answer: Apple gives you exactly four levers, and the order matters. Fix and resubmit is almost always fastest, because Apple reviews 90% of submissions in under 24 hours. Reply to App Review when the reviewer got a fact wrong. Appeal to the App Review Board only when you believe the guideline itself was misapplied. Request an expedited review only for a critical bug or a dated event. Everything below is from Apple's own published process pages, opened July 24, 2026.
Lever 1: Fix and resubmit (the default)
Apple's App Review page states that "on average, 90% of submissions are reviewed in less than 24 hours." That number changes the strategy: arguing costs days, while a corrected resubmission usually costs one. If the rejection is about metadata, screenshots, description, review notes, you can fix those fields and resubmit the same build without a new binary upload. Read the rejection message carefully first; it names the specific guideline, and the fix is often narrower than the message feels. In the screenshot case above, the governing text is guideline 2.3.3 of the App Review Guidelines: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen," with text and image overlays explicitly permitted. A set where most frames show real UI, with overlays doing the marketing, satisfies the sentence as written.
Lever 2: Reply to App Review (when the reviewer is factually wrong)
Every rejection opens a conversation thread, and replying is free. The path, per App Store Connect Help: go to Apps, select your app, click the unresolved issues link at the top, then Resolve next to the submission, then Reply to App Review. You get 4,000 characters and file attachments, and you need the Account Holder, Admin, or App Manager role.
What makes a reply work is structure, not volume. Our template, three parts: quote the guideline text verbatim; state the specific fact the reviewer missed ("the paper page shown in screenshots 2 through 4 is the app's live preview UI, reachable from the home tab"); attach evidence, a 30-second screen recording beats four paragraphs. End with a question that can be answered, such as which specific screenshots fail the requirement. Reviewers respond to replies in the same queue discipline as submissions, so this typically costs a day or two, not weeks.
Lever 3: Appeal to the App Review Board (when the guideline was misapplied)
Apple's published standard for appeals is narrow: use one "if your app didn't pass review and you feel we misunderstood your app's concept and functionality, or that you were treated unfairly." The rules on the same page: give specific reasons grounded in the guidelines, submit only one appeal per rejected submission, and answer any outstanding requests for information before appealing. The form is at developer.apple.com/contact/app-store. Apple publishes no turnaround commitment for appeals, so treat this lever as the slow, principled one: right when you need a precedent, wrong when you need to ship this week. Often the winning move is lever 2 and lever 1 in parallel, resubmitting a compliant version while the thread argues the point.
Lever 4: Expedited review (speed, not verdicts)
An expedited review request exists for two documented situations: a critical bug in your live app, where your request should include steps to reproduce it, and a launch tied to an event you are directly associated with, where Apple asks for the event, its date, and your association. Note what this lever is not: it does not overturn rejections, it reorders the queue. Apple's own recommendation for event launches is to plan ahead and schedule your release in App Store Connect, holding an approved build until launch day.
The lever you pull before submitting
The same Apple page discloses that "over 40% of unresolved issues are related to guideline 2.1: App Completeness": crashes, placeholder content, broken links, and missing review information. The highest-yield 30 minutes in this whole process happens before submission: fill in the App Review Information section with a working demo account and password, describe any special configuration, finalize every string and image, and test on current OS versions. Two more escape hatches worth knowing: if new issues surface while Apple reviews a bug-fix update, you can reply and ask for the current submission to be approved anyway, fixing the new findings next round, "as long as there are no legal or safety concerns." And Apple offers 30-minute Webex appointments with App Review to discuss guidelines before you build the risky feature, useful for the categories where the economics already demand paperwork.
The timeline math for a launch
Worked example, ours. Suppose your launch is September 1. A clean pass costs one day. One rejection plus a same-day fix costs roughly two to three days. One rejection, one reply exchange, and a resubmission costs about a week. A Board appeal has no published clock, so budget it as unbounded. Submitting August 20 therefore survives two full rejection cycles with margin; submitting August 29 survives none, and turns any screenshot dispute into a missed date. The general form: submission date = launch date, minus review time, minus two failure cycles, minus your own fix time. App review is one of the platform chokepoints you cannot remove, only buffer, the same class of dependency we mapped in the platform dependency audit, and for a solo shop it is the difference between a one-person company shipping on schedule and explaining a delay. The levers are documented, the queue is fast, and the failure mode is almost never Apple's speed. It is submitting with no room to be told no.
Discussion
Sign in with Google or just a name. No email link, no password to remember.