To war-game a response to an app store rejection, paste the rejection notice with its guideline numbers, your draft reply, the App Review notes you submitted, and a short description of what changed in the build. Then instruct Pingpong to read the reply as the reviewer working through that notice. Ask, guideline by guideline, whether the reply resolves the issue, needs a new build, or argues a point the reviewer has no authority to grant. Do it before you reply, because each round trip with review can cost a day or more.
This page covers formal replies to App Review in the Resolution Center area of App Store Connect, and the equivalent policy responses in Google Play Console. For appeals, partnership asks, or fee changes with any platform, see war-game a message to a platform before you send it. Executive starting points live under Pingpong for executives.
What the reviewer checks
A reviewer answering your reply has the notice, your build, your review notes, and the guidelines. They tend to check:
- Does the reply address each cited guideline by number?
- Can they sign in with the demo account, without a texted code or a company email?
- Does the build they have show the fix, or does the reply describe a fix in a build not yet submitted?
- Do screenshots or a screen recording show the exact flow the guideline is about?
Mission statements, user counts, and customer deadlines do not answer any of those questions. A request to speed things up goes through the separate expedited review form, with the reason stated plainly.
Reply in place or submit a new build
Some rejections can be cleared by a reply alone: a demo account that failed, a missing explanation of a feature, metadata such as a screenshot or description. Others need a code change, and no reply will clear them until a new build is uploaded. A draft that treats a code issue as a misunderstanding usually comes back rejected again. The war-game should sort each cited guideline into one of those two groups.
A worked example
This example is illustrative and does not describe a customer. A 45-person property management software company ships a tenant app for paying rent and filing maintenance requests. Version 4.0 is tied to its largest customer, a property manager moving 3,000 units onto the app on the 15th. Missing that date triggers a contract service credit, and the board expects a rollout update.
On Thursday the submission comes back with two issues. Under guideline 2.1, the reviewer could not sign in because the demo account required a code sent to a phone. Under guideline 5.1.1(v), the app lets people create accounts but has no way to delete one from inside the app.
The chief executive's 600-word draft opens with the company's mission, argues that landlords create tenant accounts so deletion should go through the landlord, says deletion is available by emailing support, and asks for faster review because of the customer launch.
A useful pass sorts the two issues. Guideline 2.1 needs only a reply: put a demo account with the code step turned off into the review notes. Guideline 5.1.1(v) needs a build. The email path would probably not satisfy a reviewer, and the landlord argument is worth stating only with screens showing that tenants cannot sign up on their own, and the reviewer may still require an in-app path. The deadline belongs in the expedited review request.
The team fixes the demo account that afternoon and replies in two sentences. Over the weekend it ships 4.0.1 with an in-app deletion request that starts the process and explains which lease records the landlord must keep. The resubmission includes a screen recording of that flow, and a separate expedited review request cites the launch date. The board update gives the new submission date and the service credit at risk if review takes longer than three days.
A request you can copy
Below are an app store rejection notice, my draft reply, my App Review notes, and a summary of what changed in the build I submitted. Read the reply as the reviewer handling this notice. For each cited guideline, say whether the reply resolves it, whether it needs a new build, or whether it argues something you cannot grant. Check whether the demo account instructions would let you sign in. Quote any sentence in the reply that the build or screenshots contradict. List anything that belongs in an expedited review request instead of the reply. Stay in the reviewer seat.
Attach the screenshots or recording you plan to send.
How Pingpong runs the war-game
The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. Check each conclusion against the current guideline text before you reply. For the steps inside the app, see running your first review.
What a model can't war-game
A model does not see the reviewer's internal notes, how the store has ruled on similar apps recently, or the current version of every guideline. Have counsel confirm any data retention claim you put in the app.
When a rejection threatens a launch the board approved, see war-game a decision before the board meeting. More guides live under work decisions before you commit.