App Store Rejection 4.3: Anatomy of a Batch Rejection (43 Apps, Two Strikes, Hard Numbers)

If you just got hit with Guideline 4.3(a) — Design - Spam (often bundled with 4.3(b) and 4.2.6), and especially if you got multiple rejections at once with a 9-question survey, this page is for you.

TL;DR — what actually triggers batch 4.3 rejections

1. The trigger is submission velocity and account profile, not code similarity. I have a controlled experiment proving this (§2).
2. A same-day batch rejection is an account-level flag. Every new submission will now be manually scrutinized until you clear it.
3. The 9-question survey has a survival pattern: honesty + one app every 48 hours + lead with your best app.
4. Hard budget rule that kept me safe ever since: ≤5 new apps per rolling 14 days, ≤8 per rolling 30 days.

1. What happened to me

Before October 1st: 28 apps on the account, every submission approved normally. Then I went into burst mode — 43 new apps inside one month, peaking at 3 submissions on October 5th.

At 5:25 AM on October 6th, Apple answered everything I had submitted that week:

• 21 apps REJECTED simultaneously — 54% of my account
• All 21 rejection letters carried timestamps within the same minute
• Every letter cited 4.3(a) Design - Spam, most bundled with 4.3(b) and 4.2.6 Minimum Functionality
• Six apps got the additional 9-question survey (the "are you a template factory" interrogation)

Why did my account look like a factory? Honest self-audit: 10 apps used rhyming suffixes (-let/-ette families), 24 apps shared one support-page template (same h1, same CSS, same footer), and four-language metadata shipped in lockstep. An reviewer doesn't need to open Xcode — the App Store search page alone exposes the pattern.

2. The experiment: it's not the code

During the flag window, three queues ran simultaneously on my account:

Read row three twice. An app sharing no code with anything on the account got the same spam survey on day one — while older apps built from the same skeleton sailed through updates in the same window.

Batch 4.3 is triggered by submission velocity and account-level profile — not by code fingerprints.

This changes your whole playbook: reskinning won't save you, refactoring won't save you. Pacing is the only lever.

3. The survey: answering the 9 questions

The survey is Apple's "prove you're not a template factory" step. Every question fishes for mass-production evidence. Four disciplines decided which apps came back:

1. Be honest. When asked whether apps share code or assets — say yes, and explain what (engineering skeleton, localization pipeline) and how each app differs functionally. Two inconsistent answers across apps = account-level trust collapse.
2. One reply every 48 hours. Never batch. Sending 21 copies of the same answer is a signed confession that you are exactly what they're asking about.
3. Lead with your best app. The first one you answer should be your strongest: real usage, full feature set, complete differentiation materials. Its approval paves the way for the rest.
4. Rewrite every answer per app. Mechanism over marketing: which APIs, why, what user value.

Result: most of the batch came back — roughly three weeks from first honest reply to final reinstatement. But this is where I have to be honest about what recovery does not look like: as of today, 6 apps from the second strike remain frozen, 0 have been restored. A 4.3(b) freeze is not a rejection you can re-appeal; it has sat through multiple 48-hour-cycle replies with no change. Treat any "frozen" state as potentially permanent when you plan your pipeline.

4. The relapse (so you don't repeat it)

After recovery, I pushed volume again. Second verdict: 6 apps frozen, cooldown of 14+ days. The difference: the first time I could say "I didn't know." The second time, I was the reason. The risk model doesn't give credit for past recovery — it only reads the current window's velocity.

About the Extended Review warning: an app carrying that text is on a watchlist. Correct move is not to resubmit quickly — document your remediation in Resolution Center, fix the real underlying issue, and wait out the cooldown. Apps with 2+ rejections need human-level handling, not pipeline treatment.

5. The rules I run now

1. Rolling 14-day new-app budget ≤ 5; 30-day ≤ 8. Check before every submission. This is the only mathematical guardrail.
2. No rhyming naming families. Ask: if an reviewer sees all my app names together in search results, what conclusion do they reach?
3. Support pages written per-app — independent h1, independent structure. No template clones.
4. Zero competitor trademarks in metadata — title, subtitle, keywords. I ate a 4.1(c) Copycats rejection on an old app's routine update for this.
5. 48-hour cadence, single-thread, never batch.
6. Freeze all new submissions while any 4.3 is unresolved.

The article above covers the most expensive 80% for free. The full text of the 9-question survey chapter (question-by-question survival plays + the 48-hour rhythm) is also free: The Nine Questions. If you're currently in a batch-rejection hole, reply with your submission cadence — I read everything.