Apple's 4.3 spam check is a 30-second batch job. 22 rejections prove it

Originally published at tensorust.com.

TL;DR: Apple App Review rejected 11 of my iPhone apps under Guideline 4.3 Spam. Then it did it again. Both times, all 11 rejections landed inside 30 seconds (30 s on October 5, 27 s on October 12), one email every 3 seconds, in an order that has nothing to do with the order I submitted them. Round two came 167.7 to 167.9 hours after I resubmitted, for every single app: a seven-day timer, accurate to 12 minutes. I filed three appeals with the App Review Board on October 5. 14 days later: zero replies. Today I ran my own "spam detector" over all 20 app repos as Apple saw them. The two most alike apps I have ever shipped are both live. Apple is not reviewing apps for 4.3. It is reviewing accounts, and it is not saying so.

If you came here from Google asking what "Guideline 4.3 spam" means: it is Apple's rule against duplicate apps. Part (a) bans "multiple Bundle IDs of the same app", and part (b) bans apps "indistinguishable from what's already widely available". The rejection usually says your app "shares a similar binary, metadata, and/or concept" with other apps, with "only minor differences". It does not tell you which app, which file or which screen. The short fix list is at the bottom: stop batch-submitting, reply before you resubmit, and book a call with App Review. The rest of this article is the receipts.

The 22 Guideline 4.3 rejection emails for 11 apps, Gmail timestamps, Oct 5 and Oct 12 2026. Static frame: batch.png.

11 apps, 30 seconds, one email every 3 seconds

On September 26, 2026 I submitted 11 new iPhone apps, all built from Windows with the no-Mac pipeline I wrote about before: Odometer (car maintenance), Parked (parking meter), Rooms (home insurance inventory), Pricebook (grocery prices), Pawprint (pet meds), Chores (kids' chore chart), Clockout (tips for service workers), Curve (grade calculator), Climbbook (bouldering log), Race Pace (running splits) and Cutoff (caffeine and sleep). The submissions were spread over 15.5 hours: the first at 7:10 AM Pacific, the last at 10:42 PM.

Nine days later, on October 5, every one of them got the same "There's an issue with your submission" email. I pulled the timestamps out of Gmail this morning. The first arrived at 5:29:32 PM Eastern. The last arrived at 5:30:02 PM. Eleven apps that each solve a different problem, for a different person, with a different design, judged in thirty seconds.

I also checked whether the decisions came out in submission order, the way a human working down a queue would produce them. They did not. The Spearman rank correlation between "order submitted" and "order rejected" is -0.06 for the first batch and 0.06 for the second. That is zero. Pawprint was submitted 4th and rejected 1st. Odometer was submitted 1st and rejected 11th. Whatever made these decisions, it was not a person opening apps one after another.

Eleven different apps, judged in thirty seconds. That is not a review. That is a for loop.

Round two: a seven-day timer, accurate to 12 minutes

Here is where I broke Apple's one rule, and I will own it. The rejection said: if you disagree, reply in App Store Connect and do not resubmit. I replied to all 11, answering all nine of App Review's questions per app. Then I resubmitted all 11 anyway, within 10 minutes (3:13 to 3:23 PM Pacific on October 5).

The second rejections arrived on October 12, between 6:04:46 and 6:05:13 PM Eastern. 27 seconds for 11 apps. But the wait is the weird part. Every app waited between 167.7 and 167.9 hours from resubmission to rejection. 168 hours is exactly seven days. Eleven apps, eleven waits, a spread of 12 minutes.

App Review emails, Submitted line in Pacific time vs email timestamp. Apple says 90% of reviews finish in under 48 hours.

For comparison, Apple's own App Review page says it reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours." When I timed all 64 App Review decisions on my account last weekend, the median was 73 hours, already worse than Apple's promise. Nothing else on my account ever waited a clean 168.

My read, and it is a read, not a leak: flagged accounts go into a holding queue with a one-week timer, and when the timer fires, the whole batch gets the same canned rejection. A human may press the button. Nobody is opening the apps. If you have a better explanation for 11 different apps landing on 7 days minus 15 minutes, I want to hear it.

I'm not the only one. Same week, same 30-second treatment

I went looking on X for other developers who got this in October 2026. It took one search. These are real posts, captured today, unedited.

On October 5, the same day as my first batch, @krPorsche918 posted that Apple rejected five of their apps "in the same minute, with the same sentence: Guideline 4.3 Spam." Their write-up has the best line anyone has written about this: "To me, 14 apps in 13 days was productivity. To Apple, it was a pattern." The same week, Apple approved all 53 in-app events on their live apps.

@krPorsche918 on X, Oct 5 2026, 275 views, captured 1:15 PM ET Oct 19 2026, real and unedited.

On October 8, @vovalukashov (Luka Shaw) asked the question everyone in the replies was thinking: "Looks like Apple stopped approving my new apps... Is this what happens to everyone who builds small apps that do one thing?" Three new apps rejected in four weeks, one of them twice. "Updates to my old apps still go through." 62K people saw it.

@vovalukashov on X, Oct 8 2026, captured 1:15 PM ET Oct 19 2026, real and unedited.

And on October 12, at 6:26 PM Eastern, 22 minutes after my second batch of 11 hit, @martindonadieu (Martin Donadieu, the Capgo founder) posted his App Store Connect screen: a wall of red "Rejected" badges and the caption "Moved from no review to almost all rejected LOL". 223K views. Three days later he posted again: rejected for 4.3 a second time, for a 100% local ticketing app that ran a 500-person event this summer and is already on Google Play.

@martindonadieu on X, Oct 12 2026, 22 minutes after our second batch, captured 1:15 PM ET Oct 19 2026, real and unedited.

Look at the pattern across all four of us. New apps die. Updates pass. My own account shows it: in the same window that killed 11 new apps twice, Apple approved updates to Chain and Minder (October 12) and six updates on September 29. All six of those September updates added the same paywall pattern the rejected apps had (Pro.swift; Purchases.swift in Chain), committed the same morning (September 26, between 9:26 and 9:29 AM Eastern). Same code, same day. Updates: approved in about 3 days. New apps: rejected twice. Luka says his updates go through. Porsche got 53 in-app events approved. Martin's existing apps are still up.

So here is where I disagree with Luka. His conclusion was "I guess it's a sign to focus on the ones already in the App Store." That is exactly the behavior this filter is training into every small developer, and it is the wrong lesson. The filter is not saying your new app is bad. It is saying your account is shipping too fast for Apple's comfort. Those are different problems with different fixes.

Was Apple right? I ran a spam detector on my own apps

Fair question: maybe my apps really are clones. I am one developer with 20 iPhone apps in 30 days, built with AI coding agents, all from the same pipeline. If anyone deserves a 4.3, it might be me. So this afternoon I tested it, instead of arguing about it.

The experiment: for each of my 20 local app repos, take the git commit Apple actually saw (for the 8 live apps, the last commit before their first approval; for the 11 rejected apps, the last commit before the October 5 resubmit). Then compare every pair of apps, 190 pairs, on five things a 4.3 filter could plausibly look at:

• File tree overlap: Jaccard similarity of the tracked file paths (shared paths divided by all paths). This is the "skeleton".
• Identical files: files that are byte-for-byte the same after replacing the app's own name.
• Swift line overlap: share of distinct non-trivial Swift source lines the two apps have in common.
• Store text overlap: overlap of three-word phrases in the App Store description.
• Screenshot distance: the closest pair of store screenshots between the two apps, by 256-bit average hash (lower means more alike).

git ls-tree of each repo at its submit-time commit, fingerprint.py, 1:19 PM ET Oct 19 2026.

The honest result first, because it does not flatter me: the rejected 11 really do share a skeleton. Their median file tree overlap is 0.76, against 0.56 for the live apps. They share a median of 14 identical files per pair against 5, and about three times the Swift lines (0.067 against 0.021). Clockout and Odometer have literally identical file trees: the same seven Swift files, with the same names, in the same folders. If Apple's filter looks at project structure inside the binary, my rejected batch lights up.

Now the part Apple should explain. The single most similar pair of apps in all 190 is Baseline Ledger and Fairway Ledger, my tennis journal and my golf journal. They share a third of their Swift lines (0.333), 20 identical files, a 0.90 file tree, the most similar store description and the closest screenshots of any pair. Both were approved, two days apart, on September 22 and 24. Both are live today. Chain and Quiver share a 0.968 file tree. Both live.

fingerprint.py, 55 rejected pairs and 28 live pairs, each repo at its submit-time commit, Oct 19 2026.

And the things a human reviewer actually looks at, the store page and the screenshots, do not separate the two groups at all. Store text overlap: 0.010 for rejected pairs, 0.009 for live pairs. Screenshot distance: 76 against 82. A person scrolling the listings could not tell the rejected apps were "more similar". Only a machine diffing the bundles could.

fingerprint.py run 1:19 PM ET Oct 19 2026.

The one file every rejected app had

The fingerprint that splits the groups cleanly is not a similarity score. It is one file. All 11 rejected apps shipped Sources/Pro.swift in their first submission. None of the 8 live apps had it at first approval. Pro.swift is a StoreKit 2 paywall: the app is free, and a one-time $4.99 purchase unlocks the full version. Here is the top of Odometer's, at the commit Apple reviewed:

// Sources/Pro.swift (odometer repo, commit af40d3658)
/// Odometer Pro: one non-consumable. Keeping one car on schedule is free forever; Pro is the
/// whole garage and the paperwork.
@MainActor
@Observable
final class Pro {
    static let productID = "com.mattbusel.odometer.pro"
    /// The first build that has Pro in it. Anything earlier had every feature.
    static let firstFreemiumBuild = 2

    enum Reason: String, Identifiable { case costs, garage, history, export, settings; var id: String { rawValue } }

    private(set) var unlocked: Bool
    private(set) var grandfathered = false
    private(set) var product: Product?

    var price: String { product?.displayPrice ?? "$4.99" }

    func ask(_ why: Reason) { if !unlocked { paywall = why } }
    ...
}

The files are not copies of each other (no two rejected apps have an identical Pro.swift; each has its own product, its own free tier and its own reasons to upgrade). But the shape is the same: one non-consumable, one Pro class, one paywall sheet. The live apps were approved without it and only went freemium later, through updates submitted on September 26, the same day as the 11 new apps. Those updates sailed through on September 29.

Here is what I think is really happening, and Apple will never say it out loud. A brand-new free app with a $4.99 unlock, from an account that drops 11 of them in one day, is the exact silhouette of a template farm. The 4.3 text and its sister rule 4.2.6 are written about "commercialized template or app generation services". In 2026, with every coding agent able to spit out an app a day, the template farm and the solo dev with Claude Code look the same from the outside. Apple's filter judges the silhouette, and the human who signs off never opens the app. Correlation, not proof: 19 apps is a small sample. But it is a cleaner split than anything in the guideline text.

What I sent back, and what came back: nothing

The 4.3 rejection comes with nine questions: what the app does, who it is for, how it differs, how you tested it, whether it shares code with your other apps, and so on. I answered every one, per app, honestly. Including the parts that probably hurt me, like this from Odometer's reply:

"No shared framework or asset pack. Every screen, model, illustration and text is specific to Odometer. Two files follow a pattern I reuse: the StoreKit 2 purchase handling for its one non-consumable (the paywall's text, free/Pro split and look are specific to the app), and a test-only driver that steps through the app's screens to record the walkthrough video and is inactive in normal use."

Then I filed appeals with the App Review Board through Apple's form, which takes at most 5 apps and 2,000 characters per reason, so it took three forms (5 + 5 + 1). The argument was simple: all 11 were rejected within one minute with word-for-word identical text, so no individual review happened, and I asked for a human to open each app.

That was October 5. I searched my inbox this morning for anything from Apple since. There are Apple Ads billing emails, an iPhone Duo pre-order ad, and a notice that the App Review Guidelines were revised on October 16. There is no email from App Review or the App Review Board since the second batch on October 12, and nothing at all about the appeals. 13.8 days and counting.

That October 16 revision is its own small insult. Apple rewrote seven parts of the guidelines (new rules on creative assets and hidden features, payment links, child safety). Guideline 4.3 was not one of them. In the middle of a public wave of 4.3 batch rejections, the rule stayed word-for-word the same.

Apple's own numbers say you are not special

Apple publishes a yearly App Store Transparency Report. The 2025 edition counts 9,100,620 submissions reviewed and 2,093,244 rejected, about 23%. The Design section, which includes spam and copycats, accounts for 415,532 rejections. Apple's May 2026 newsroom post says it rejected more than 371,000 submissions for copying other apps, spam, or misleading users.

Now look at the line nobody quotes. The same report counts 26,305 appeals of app removals and 423 restorations. That is 1.6%. Back in 2021, Apple's Senior Director of App Review said in a court filing that the team had more than 500 human reviewers and that less than 1% of rejections are appealed. Do the arithmetic yourself: 9.1 million submissions a year is roughly 25,000 a day. 371,000 spam-type rejections is about 1,000 a day. Nobody is opening 1,000 apps a day with care. The 30-second batch is not a glitch in that system. It is the system.

Hot takes, ranked

1. 4.3 has become a volume tax on solo developers. It does not catch clones. My two most similar apps are live. It catches accounts that ship more than Apple thinks one person should. In the AI coding era, that is every indie dev who is any good.
2. The App Review Board is a black hole for batch rejections. My bet: these 11 appeals get no human reply before November, and if they ever do, it will be one templated paragraph for all 11.
3. Apple will never publish 4.3 numbers by itself. The transparency report lists "4.3.0 Spam" only for removals (418 apps), never for rejections, because a per-guideline count would show how much of the "spam" fight is really a throttle on new developers.
4. Updates pass because updates already make Apple money. An update to a live app is a known quantity with a payment history. A new app is a cost. Every account in this article got updates approved during the same weeks its new apps were killed. That is not a coincidence, it is a business model.
5. Google is going to eat this. Martin's app was on Google Play a week before Apple rejected it a second time. When the indie dev's first launch moves to Android, Apple's "quality" story gets a lot quieter.

How to survive a Guideline 4.3 spam rejection

This is what I would do differently, from the data above and Apple's own pages. It is the advice I am now following myself.

1. Never batch-submit new apps. One or two new apps per account per week. Porsche's "14 apps in 13 days" and my "11 in one day" got the same answer. Updates to live apps can go as fast as you like.
2. Reply, and do not resubmit. The rejection says it, and I ignored it. My resubmits landed on a seven-day timer and died in 27 seconds. Answer the nine questions in App Store Connect and wait.
3. Launch new apps without the paywall, add IAP in an update. 0 of my 8 approved apps had a paywall at first approval; 11 of 11 rejected apps did. Small sample, but it is the one clean split I found, and the freemium updates passed every time.
4. If your apps are variants, merge them. 4.3(a) literally tells you to ship one app and sell the variations as in-app purchases. If a reviewer could describe two of your apps with one sentence, they will.
5. Book a call with App Review. Apple offers 30-minute Webex appointments with App Review to discuss the guidelines. Almost nobody mentions this. It is the only channel where a human has to look at you. It is my next move.
6. Appeal with specifics, one appeal per submission. Apple's appeal page asks for "specific reasons why you believe your app complies". Timestamps of a batch rejection are specific. So far they have not been enough, so pair them with item 5.

If you want the pipeline these 20 apps were built and shipped with (from a Windows PC, no Mac), the complete iOS-on-Windows guide covers it, and what 20 real apps cost to build has the money side.

The numbers so far

• Rejected under 4.3, twice: 11 apps (22 rejections), October 5 and October 12, 2026
• Time to reject 11 apps: 30 seconds (Oct 5), 27 seconds (Oct 12)
• Submit order vs reject order: Spearman -0.06 and 0.06 (no relationship)
• Wait on round two: 167.7 to 167.9 hours for all 11 (Apple says 90% within 48 h)
• Appeals filed: 3 forms covering 11 apps, October 5. Replies: 0 after 13.8 days (inbox checked 1:10 PM ET, October 19)
• Live on the US App Store today: 8 apps (iTunes lookup, 1:12 PM ET October 19), unchanged since October 17
• Most similar pair of all 190: Baseline Ledger + Fairway Ledger, 33% shared Swift lines. Both live.
• Paywall at first submission: 11 of 11 rejected apps, 0 of 8 approved apps

The data, and how to rerun it

Decision timestamps: the 22 "There's an issue with your submission" emails from Apple's App Review sender, pulled from Gmail with their "Submitted:" lines (Pacific Daylight Time) on October 17 and re-checked on October 19 at 1:10 PM Eastern for anything newer (none). Fingerprints: fingerprint.py run at 1:19 PM Eastern October 19 over 20 local repos, each at the commit before its decisive submission (git rev-list -1 --before=...), reading files with git show, PNGs excluded from file comparisons, the app's own name replaced with a placeholder before hashing. Live status: the iTunes Search API lookup for my developer account, 1:12 PM Eastern. Posts by @krPorsche918, @vovalukashov and @martindonadieu were captured from X at about 1:15 PM Eastern October 19, real and unedited.

So, @martindonadieu, @vovalukashov, @krPorsche918: check your own rejection emails. Did yours land within seconds of each other, and did your resubmits wait exactly a week? If three more accounts show the same 168-hour timer, this stops being my theory. Everyone else: has Apple's App Review Board ever actually answered your 4.3 appeal, and how long did it take? Drop your numbers in the comments.

Building iPhone apps without a Mac and want the pipeline set up on your own repo (signing, screenshots, fastlane submission and the review notes I now use)? The No-Mac iOS Pipeline is $299, first TestFlight build in 5 business days.