Free sample · The 4.3 Survival Report ($19)
The Experiment: Rate, Not Fingerprints
This is one chapter from the full report. If you've been hit by guideline 4.3(a)/(b) and the nine-question survey, the rest of the report covers the survey answers, appeal templates, and recovery timeline in the same level of detail.
Sample chapter — abridged from the full report. All data points intact.
The experiment: rate, not fingerprints
This is the most valuable section of the report, and the third row deserves to be read twice. During the incident window, three queues of submissions moved through review on the same account, at the same time, from the same person, with the same tooling:
| Queue | Window | Outcome | What it controls for |
|---|---|---|---|
| 15 first-time submissions | May – Sep, before the flag | All passed clean | Same shared scaffolding, same localization pipeline, same toolchain — before the rate tripwire |
| Version updates to 2 flagship apps | During the flag | Passed, one by one | Same account, same templates, flag active — updates still flowed |
| 1 brand-new app, unrelated category | During the flag | 4.3 + 4.2.6 + nine questions anyway | 2,030 lines of code (largest in the account), zero code shared with the affected family, completely different category |
Read row three again. A brand-new app with no code similarity to anything in the account — different category, biggest codebase, clean design — still got the batch rejection and the survey. Whatever the rejection text says about "similar apps," the trigger that selects who gets surveyed is account-level submission rate. Code inspection is the aftermath, not the trigger.
What "account-level" actually means
When a batch lands with minute-identical timestamps, you are not dealing with independent reviewers. Three things change on an account-level flag:
- Every new submission gets manual screening — including updates to previously-approved apps. Expect slower review on everything.
- Old submissions can be held hostage — two apps from Sep 19 sat in WAITING_FOR_REVIEW for a month while the flag burned. They were never explicitly rejected. They were just... held.
- The survey is the exit interview. The nine questions are not information gathering for its own sake — your answers get compared against each other across apps, and against what the reviewer can see on the storefront. Consistency is scored.
The nine questions: how to survive them
The 4.3(a) batch rejection attaches a survey. The questions ask about shared code, shared personnel, marketing relationships between apps, and why the apps exist. The temptation is to lawyer up and minimize everything. The failure mode is different: a wave of near-identical replies landing in Resolution Center is itself proof of a template operation — which is exactly what you're being accused of.
| Question cluster | Survival play |
|---|---|
| Q1–Q3 · What does the app do / who is it for | Concrete mechanisms, not marketing. "User taps X, system does Y, stored in Z." One screenshot reference per claim. |
| Q4 · Did you develop it yourself? | Never lie here. Approval decisions get revisited during account investigations; a discovered lie converts a recoverable 4.3 into a termination risk. Independent developer: say so plainly. |
| Q7 · Code shared across apps? | State exactly what is shared (a 210-line localization helper, standard scaffolding) and what is not (core logic per app). Precision reads as honesty; minimization reads as evasion. |
| Q8 · Third parties involved? | Same rule as Q4. "No agency. Built by one person." |
| Q9 · Cross-promotion between apps? | Disclose what exists, even if it's unflattering. An undisclosed mechanism found later costs more than the disclosure. |
The rhythm that worked
- One app per 48 hours. Not five in a day. Batch-sending identical replies at machine speed is machine-speed evidence against you.
- Best app goes first. A clean approval on your strongest app raises the odds for every thread behind it — and gives you a citable precedent: "{App} passed review on {date}; the shared components in question are identical."
- Draft, read end-to-end, then send. Never send a first draft. Once it's in the thread, it's evidence.
- End every reply with one sentence: "If anything still reads as spam, please identify the specific triggering element." It converts silence into actionable signal, and reviewers do answer it.
- Freeze all new submissions while any 4.3 is unresolved. Every new submission during a flag is another file in the case file.
The second strike (the section nobody else can write)
The first recovery worked. Apps cleared, the flag lifted, revenue resumed. And then — this is the confession part — the account went right back to burst submissions. Six more apps, fast, in mid-October.
The second strike was worse in every way that matters:
- Six apps frozen outright — not rejection-with-survey, but removal from sale pending review, with a cooldown measured in weeks
- No negotiation path. The first time, the survey gave you a channel. The second time, the channel narrows: the record already shows you were told.
- The defense from strike one is gone. First time, "I didn't understand the rate sensitivity" was at least arguable. Second time, the account is the argument. The risk model does not award credit for prior recovery — it only reads the current window.
Extended Review = yellow card
Easy to miss: some apps got the older-format 4.3(a) rejection with this warning attached — resubmitting similar apps may extend review times, and repeated violations may result in account termination.
Translation: that app (and the account) is on a watchlist. The play that worked: do not rush a resubmit. Fix the real underlying issue (in this case: document the Accessibility API usage rather than remove it), write the fix into the Resolution Center thread so there's a paper trail, and let the cooldown run before touching the app again. Apps with 2+ rejections leave the pipeline world and enter the hand-crafted world — one at a time, with context in every reply.
The rate budget: rules with bodies on them
| Rule | What it means |
|---|---|
| 5 / 8 | Rolling 14-day new-app submissions ≤ 5; rolling 30-day ≤ 8. Check your submission log before every new-app upload. Exceeding it isn't a risk — it's a coin flip with your account as the stake. |
| No name families | Zero rhyming-suffix or shared-pattern naming across a portfolio. Test: if a reviewer lines up your app names in search results, what conclusion do they reach in five seconds? |
| Pages are fingerprints | Every support URL gets its own h1, its own structure, its own copy. A shared template across 24 apps is the loudest possible factory signal — and it's visible without installing anything. |
| Zero trademarks | Title, subtitle, keywords: no competitor names, no platform-adjacent brands. 4.1(c) Copycats hits updates to old apps too — a routine update got pulled back for a keyword added months earlier. |
| 48h survey rhythm | One reply per 48h during batch rejections, strongest app first, freeze everything else until it clears. |
| Freeze on flag | Any unresolved 4.3 on the account = no new submissions of any kind. Updates to clean apps are the only gray zone — treat even those as slow. |