Your app has been stuck in “Waiting for Review” for ten days. You have filed three expedited-review requests and five support tickets. A “senior advisor” promised a callback two weeks ago and went silent. Meanwhile, the launch event you planned around your release date is next week. There is no official escalation path for any of this — at least not one Apple publishes. This post is the playbook I use, drawn from the threads where indie developers have actually moved their cases forward, plus the documentation I have learned to lean on.

What is actually available

The official channels, in the order Apple lists them:

• App Store Connect Resolution Center. The in-app message thread tied to a specific submission. Use it for review-status questions about that submission.
• Contact Us → App Review form. The route for review-related questions outside a specific submission.
• Expedited review request. One-shot request to bump a submission’s priority.
• Apple Developer Program Support (contact form). For account-level issues — terminations, payment, agreements.
• Apple Developer phone support. Available to enrolled developers; quality varies.

None of these has a published SLA. The 48-hour App Review target Apple publishes on the App Store Connect status page is a target, not a commitment. Both thread 836045 and thread 835627 show what happens when the queue drops a case: silence.

A four-step playbook for stuck submissions

This is the order I run, escalating only when the previous step has been silent for the stated wait.

Step 1: Resolution Center, with a written paper trail (day 1 of overdue)

The moment a submission goes past five days in “Waiting for Review,” open the Resolution Center for that app and write a short, factual message. Include:

• The exact submission date and current status.
• Any time-bound business impact (launch event, broken integration, payment cutoff).
• Your build version and submission ID.

Keep the tone matter-of-fact. The reviewer sees this thread, and emotional escalation early closes off the channel for later.

Step 2: Expedited review request (day 2)

Submit one expedited review at developer.apple.com/contact/app-store/expedite/. One. Filing three, as the developer in thread 836045 did, does not improve your position — it crowds your own case in the queue.

Two things to know:

• Document business impact concretely. “Launch event with 500 paid attendees on Saturday, March 14” beats “this is urgent.” Reviewers triage on visible, dated impact.
• An expedited request is not a guarantee. If you don’t hear back in 48 hours, treat it as if you did not file one. Move to step 3.

Step 3: Apple Developer phone support (day 3–4)

Phone advisors cannot move your review forward, but they can do two useful things:

1. Confirm there is no flag on your account. Sometimes a submission is silently held because a separate account-level question is open. The advisor can see that; you cannot.
2. Create a case number you can reference later. Get the case number, write it down, ask for a callback time, and confirm the advisor’s name. Advisors rotate, and the next one will have no context unless you reference the case number.

The mistake in thread 835627 is instructive: relying on a single advisor’s promise of a senior-advisor callback. There is no contractual callback. Treat every phone call as a one-shot — get a case number on every call, do not let one advisor’s promise serve as your tracking system.

Step 4: Public Developer Forums, written carefully (day 7+)

This is the one that consistently moves cases. Posting a calm, factual thread on the Apple Developer Forums sometimes triggers internal escalation. Both threads cited above are textbook examples — the developers posted, and the threads picked up traction.

What works in a forum post:

• A neutral title. “App Review case unanswered for 14 days — case #12345” beats “Apple is destroying my business.”
• A timeline of facts. Date of submission, date of each support contact, what each response was.
• No accusation, no speculation. State that you are looking for guidance.
• Reference your case numbers. Apple staff who lurk the forums can pull the records.

What does not work: rage posts, demands for a contact, naming individual advisors. The forum moderators will fold them, and your account-level standing gets worse, not better.

Account-level issues: appeals and the App Review Board

If your case is about an account termination warning, an IP dispute, or a flagged identity verification — the thread 835627 situation — the rules differ.

Appeals go through the App Review Board, not regular App Review support. The Board reviews disputed rejections and policy decisions. Submit the appeal as soon as you have a written rejection in hand — do not wait for verbal advisor follow-ups.

For IP-related disputes, especially apps named after or referencing a third-party product, the only thing that resolves them is written permission from the IP holder. Verbal “yes you can use the name” from a vendor representative has not held up in a single forum case I have seen. Get it on company letterhead or as a signed email, scan it, attach it to the appeal. The forum case in thread 835627 stalled in part because the IP question was unresolved on paper.

What to set up before you ever need it

A short list of things I do for every App Store account I run, before anything goes wrong:

1. Keep Apple’s Resolution Center emails in a tagged folder. When you need to reconstruct a timeline, you will need every email, not just the most recent thread.
2. Note every case number, advisor name, and date in a single document. A two-column markdown file is enough. Apple’s CRM is opaque; yours doesn’t have to be.
3. Get IP permissions in writing at the start. If your app references another product, get a signed permission letter on file before submission. It is much easier to obtain when nothing is on fire.
4. Have a public-facing email and a published support page. When your account is under review, Apple’s automated systems check whether you look like a legitimate business. The cost of a real domain and a real support page is low; the absence of either has cost developers their accounts.
5. Never name your only revenue stream after a third party. Even with permission, the IP holder can revoke. Build the brand on something you own.

What does not work

A short list, from threads and from personal experience:

• Cancelling and resubmitting. Your queue position resets; the underlying review state does not. Both developers in thread 836045 confirmed it did not help.
• Filing multiple expedited requests. One is the cap that works. Multiple flags your case as noisy.
• Tagging Apple executives on social media. Sometimes a publicized case moves; far more often it tags your account as a PR risk, which is not what you want for a Resolution Center conversation.
• Trusting “expedited” to mean fast. Expedited only changes priority; if reviewer capacity is the bottleneck, expedited still waits in line.

The honest summary

Apple’s developer support runs as a one-way ticket queue with no published SLA, no transparency on queue position, and no real escalation for non-enterprise customers. The forum threads where developers eventually got unstuck have one thing in common: a calm, well-documented public post tied to a real case number. That is not a process Apple advertises. It is what works in practice.

Next steps

Once the stuck submission moves, write a one-page playbook for yourself: the dates, the case numbers, the contact paths that responded, the ones that did not. The next time the queue drops one of your cases — and there will be a next time — you will save the week you lost this round.

---