I have been writing software for a long time. Long enough to have been rejected by App Review before, and long enough to know that most rejections are boring. A missing privacy string. A screenshot that shows a device frame Apple no longer likes. A login the reviewer couldn’t get past. You read the note, you fix the thing, you resubmit, everyone moves on.
This one is different, and not because the rejection was harsh. It’s different because I still don’t know what I’ve been rejected for.
On 9 September 2026 Apple rejected my flag game, Who’s Flag Is It Anyway?, under Guideline 4.3(a), the spam rule, on the grounds that it is too similar to apps submitted by other developers. I appealed and asked a single, specific question: which apps? On 19 September the App Review Board told me the original decision was valid and referred me back to the original decision.
So I’m writing it down. Partly because writing things down is how I think, and partly because when I went looking for other developers in the same position, I found rather a lot of them.
The app
Let me establish what we’re talking about, because “flag game” undersells it and the whole dispute is about whether this thing is distinct.
https://www.whosflagisitanyway.com.au
Who’s Flag Is It Anyway? is a geography game for iPhone, iPad and Apple TV. It has twelve modes:
- Flag Quiz, the obvious one
- Speed Round, against the clock
- Memory Match, pairs of flags
- Passport, progress across regions
- World Tour, a guided run through the map
- Anthems, hear an instrumental national anthem and pick the country
- Landmarks, identify the country from a landmark
- Map Outlines, identify the country from its silhouette
- Emoji Mode, because every flag is an emoji and I couldn’t resist
- Family Mode, local pass-and-play for two to four players
- Daily Challenge, a single puzzle synchronised worldwide, same for everyone, once a day
- Learn, a reference library covering roughly 200 countries
The Apple TV version isn’t the phone layout stretched across a television. It has its own focus-engine interface built for the Siri Remote, because a quiz you play from the sofa needs different affordances from one you play on a bus.
On the business side it is about as unexciting as an app can be. No adverts. No analytics. No tracking. No accounts. No third-party SDKs of any kind. It works entirely offline and keeps progress on the device. There is one optional non-consumable in-app purchase and no subscription.
Technically, it is a pure Apple app. Swift, SwiftUI throughout, the Observation framework for state, StoreKit for the purchase, AVFoundation for the anthems. No cross-platform framework, no app generator, no purchased template, no shared codebase with anything else I’ve ever shipped. There is no Android version, and there can’t be one without a rewrite, because I made the deliberate decision to build it Apple-native and lean on Apple’s own frameworks.
Hold that thought. It becomes relevant later.
The rejection
Version 1.0 (build 2) was reviewed on 9 September 2026 on an iPad Air 11-inch (M3). It came back with:
Guideline 4.3(a) – Design – Spam
We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences.
The note went on to explain that submitting similar or repackaged apps creates clutter on the App Store, and listed the kinds of things that typically lead to this outcome: using the same source code or assets as other apps, creating multiple similar apps from a repackaged template, purchasing a template from a third party that contains problematic code, or submitting similar apps through multiple accounts.
The suggested fix was to “review the app concept and submit a unique app with distinct content and functionality.”
I read that list several times looking for the one that applied to me. Same source code as other apps: no. Repackaged template: no. Purchased template: no. Multiple accounts: no, there’s one account and it has one flag game on it. Sibling apps: none. Reskin of something else: no, there is no something else.
At this point I want to be fair to Apple. If you receive the volume of submissions they do, you need a mechanism for catching template farms, reskinned games and the hundred-city-guides-from-one-codebase pattern. Guideline 4.3 exists for a reason and I don’t object to the reason. Mistakes are inevitable in any review process, human or otherwise, and I’d have been perfectly content with “sorry, we got that wrong” or even “here’s the app we think you copied, argue your case.”
What I got was neither.
Three words doing a lot of work
Before the appeal I went back to the guideline itself, because the rejection notice and the guideline it cites don’t say quite the same thing.
Here is Guideline 4.3 as it currently stands on Apple’s site:
4.3 Spam
(a) Don’t create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city). This practice results in unnecessary apps, which makes it hard for users to find the apps they want. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and providing the variations using in-app purchase.
(b) Don’t submit apps that are indistinguishable from what’s already widely available. Opportunistically creating variants of existing app categories or popular apps degrades App Store discovery, reduces overall app quality, and harms both users and developers. Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience. […]
Read 4.3(a) again. As written, it is about one developer shipping the same app under multiple Bundle IDs. The map-app-per-city example is the archetype. That’s a rule about my own catalogue, and my catalogue contains one flag game.
4.3(b) is the one about apps being indistinguishable from what’s already out there, from anyone. If Apple’s position were “the App Store has enough flag quizzes, thank you,” 4.3(b) is where that argument lives. But I wasn’t cited under 4.3(b). I was cited under 4.3(a), with a notice that talks about “apps submitted to the App Store by other developers,” which is a phrase that doesn’t appear in 4.3(a) at all. For completeness, the guideline about copying another developer’s app is 4.1, Copycats, and that wasn’t cited either.
That’s one mismatch. The second is the phrase at the heart of the notice: “similar binary, metadata, and/or concept.”
Those are three entirely different allegations, and they’d need three entirely different responses.
A similar binary, in ordinary software terms, might suggest shared code: a template, a generator, a framework that makes up most of the executable, or a copied codebase. I should be clear that this is my reading of the phrase as an engineer. Apple hasn’t defined it, and I have no idea how, or whether, App Review compares binaries. But taken at face value it’s a serious claim, and it’s also the most checkable one. I can produce the repository. I offered to.
Similar metadata means the App Store listing: the name, subtitle, description, keywords, screenshots, category. If my listing reads like someone else’s, that’s a copywriting job. I’d change it this afternoon. I said so.
A similar concept means, as far as I can tell, “flag quizzes exist.” They do. So do to-do lists, weather apps and podcast players. Nobody would argue a new podcast player is spam because it plays podcasts, and 4.3(b), not 4.3(a), is the guideline that sets the bar for what counts as “meaningfully different” within a well-worn category. A twelve-mode game with anthems, map silhouettes, a worldwide daily challenge, a tvOS interface and a 200-country reference library is, I’d have thought, a reasonable attempt at clearing it.
“And/or” collapses all three into one sentence. It’s the review-note equivalent of a compiler error that says “something in your project is wrong.” Which file? Which line? Which of the three categories of thing? Without that, the remediation advice, “submit a unique app with distinct content and functionality,” isn’t advice. It’s the guideline restated.
The appeal
I filed an appeal through the App Review Board process. Apple’s own guidance on appeals says to “provide specific reasons why you believe your app complies with the App Review Guidelines,” so I did. The appeal didn’t argue that Apple was wrong in the abstract. It set out, point by point, why I believed this was a false positive:
- Written from scratch in Swift and SwiftUI
- No templates, no app generator, no purchased or shared codebase
- No third-party SDKs
- Code, UI, icon and written content all ours
- A single standalone title, not one of a family
- Twelve distinct game modes, listed
- A dedicated tvOS implementation
- Distinctive audio, geography and gameplay features
- No advertising, tracking or accounts
Then the part that mattered:
Could you let us know which app(s) you believe ours duplicates?
I added that if some element of the metadata happened to resemble another listing I would gladly revise it, and offered architecture notes, a source-code walkthrough, or whatever technical detail would help. Tell me what you think I copied and I’ll investigate it. That was the whole appeal.
The App Review Board
On 19 September 2026, appeal APL568173 came back. The substantive content was one sentence:
The App Review Board determined that the previous rejection feedback was valid.
For further information, it directed me to the previous rejection.
It did not identify the allegedly similar app. Or the allegedly similar binary. Or the allegedly similar metadata, functionality or assets. It did not say which of the three “and/or” branches applied. It did not say what needed to change. It did not acknowledge that a question had been asked.
Compressed, the exchange runs like this:
Apple: Your app duplicates something.
Me: What?
Apple: Something.
Me: Which app?
Apple: We have reviewed our decision and determined that we were correct.
Me: Yes, but what did I duplicate?
Apple: Please refer to our previous message.
I’ll leave it there. The point isn’t that it’s funny, though it is a bit. The point is that it’s circular.
You cannot debug “something, somewhere”
Here’s the engineering problem, stripped of the frustration.
I can change the code. I can change the architecture, the UI, the assets, the metadata, the functionality, the gameplay, the App Store presentation. Every one of those is under my control and I’ve changed all of them many times over in the course of building the thing.
What I can’t do is pick which one to change without knowing which one is the problem. A “similar binary” finding and a “similar concept” finding point in opposite directions. Rewriting the game loop does nothing for a metadata collision. Rewriting the description does nothing for a binary match. And if the real objection is that the category is crowded, no amount of work on this app addresses it, and I’d rather be told that now than after a third rewrite.
Any developer will recognise the shape of this. It’s a bug report that says “it’s broken” with no steps to reproduce, no expected-versus-actual, no log. The difference is that with a bug report you can go back and ask. I did go back and ask. That was the appeal.
Apple’s own App Review page says that when a submission doesn’t pass review, “details are provided, including any specific App Review Guidelines that your submission didn’t follow.” The guideline number was provided. The details were not.
This isn’t just me
I assumed, briefly, that I’d hit a rare edge case. Then I searched the Apple Developer Forums.
The exact sentence, “shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences,” appears in thread after thread. To be clear about sourcing: these are developers’ own accounts, not Apple statements, and I can’t verify any of them. But the pattern is consistent enough to be worth noting.
- A Godot developer who’d spent six months on an original C# game was rejected under 4.3(a) with the same wording in September 2024. Their theory, which is speculation, was that the Godot runtime made up enough of the binary to resemble other Godot games. What’s documented is that shrinking the binary didn’t help, and repeated appeals explaining the engine and the gameplay eventually did.
- A VPN developer in December 2024 received the identical sentence, appealed several times, and reported that Apple never named the app theirs was supposedly similar to. An Apple staff reply on the forum said they’d follow up in App Store Connect. A later reply, quoted by the developer, said Apple was “not able to provide feedback on app concepts or features.”
- Another developer in May 2025 laid out essentially the case I laid out: built from scratch, no templates, individually written metadata. Apple staff replied that the app violated 4.3 and recommended booking an App Review appointment through the “Meet with Apple” sessions.
- A developer in October 2025, rejected repeatedly for an app with a custom Create ML model and custom UI, said they’d already had a call with App Review and still hadn’t been told which app theirs resembled. The reply from Apple Developer Relations pointed them, again, at the appointment sessions.
I want to be careful here. I have no evidence about how Apple arrives at a 4.3(a) finding. Apple’s guidelines say every app “is reviewed by experts,” and I have no basis to claim otherwise or to say anything about what tooling sits behind a decision. Developers on the forums speculate about automated binary comparison; that’s speculation, and I’m not repeating it as fact.
What I can say from primary sources is narrower and, I think, more damning: Apple’s published appeals process asks the developer for specifics, and the responses developers report receiving, mine included, don’t return any. Apple staff have repeatedly directed developers facing similar problems towards one-to-one App Review appointments. That’s an avenue still available to me. But it doesn’t change what happened here: I asked a specific question through Apple’s formal appeal process, provided detailed evidence, and the App Review Board upheld the rejection without answering it. And the developer above who’d already had that call reported coming out of it none the wiser.
The uncomfortable irony
There’s an irony in this that I’d rather note than milk.
I built an Apple-only app. Swift, SwiftUI, Observation, StoreKit, AVFoundation. A separate tvOS interface built for the focus engine because I thought the Apple TV deserved better than a scaled-up phone screen. No cross-platform layer. No third-party SDKs, partly on principle and partly because Apple’s frameworks were good enough that I didn’t need any.
That was a bet on the platform, and it has a cost: the app doesn’t exist anywhere else and can’t easily. There is no Android build sitting on a shelf. If Apple’s door stays shut, the work stays on my Mac.
I’m not arguing that going native should buy special treatment from App Review. It shouldn’t, and it doesn’t. But the developers most exposed to an unexplained 4.3(a) rejection are precisely the ones with nowhere else to go, and those are the ones who took Apple’s own advice about how to build for its platforms. If the platform wants that kind of investment, and Apple’s WWDC sessions suggest it does, the least it can offer in return is a rejection a developer can act on.
What now?
So here is where I’ve landed, and it’s not a threat or a flounce.
I can change the code.
I can change the functionality.
I can change the interface.
I can change the metadata.
I can even change the concept, if Apple can tell me which part of it is the problem.
What I cannot do is fix a problem that Apple refuses to identify.
The app is written, complete, tested on three device families, and ready to ship. For now, Apple simply won’t let it through the door, and the only reason on file is that it resembles something, somewhere, in some way, submitted by someone.
What exactly is a developer supposed to do next?
Sources
- App Store Review Guidelines, 4.3 Spam (Apple)
- App Store Review Guidelines, 4.1 Copycats (Apple)
- App Review: appeals and responding to rejections (Apple)
- Preventing Copycat and Impersonation Rejections (Apple App Review staff post, April 2025)
- Developer forum threads reporting the same 4.3(a) wording: thread 771167, thread 785249, thread 803895, and a Godot forum thread (developer accounts, unverified)