Guideline 4.3 is the rule that quietly kills more small-studio submissions than most first-time developers expect. It doesn't require a bug, a crash, or a privacy misstep. It only requires that your app looks, in the reviewer's eyes, like something that already exists on the store, or like something you or someone else has already shipped with a different coat of paint.
We've been through this more than once at Olnesta Ltd, on our own submissions. The rejection notice is famously terse. It tells you the app appears to be spam or a duplicate; it rarely tells you which app, which template, or which specific overlap triggered the decision. That vagueness is the part that makes 4.3 feel arbitrary, but the underlying logic is fairly consistent once you've seen it a few times.
What review is actually comparing against
Our understanding, from experience rather than any formal Apple document, is that a 4.3 assessment weighs your submission against at least three things: known commercial app templates, other apps already live under your own developer account, and the broader pool of recently submitted apps that share a recognizable structure. That last bucket is why 4.3 rejections sometimes hit apps that feel genuinely original to the person who made them. If a template kit has been popular in the last year, anything that happens to land in the same shape as one of its default configurations can get caught in the same net, even if you wrote every line yourself.
The pattern that most reliably triggers it is when two or more apps share layout, feature set, and interaction flow, and differ mainly in surface details: the name, the icon, the accent color, the copy on the onboarding screens. This is true even when the apps come from apparently unrelated developer accounts. Reviewers are looking at the built artifact, not the org chart behind it.
What this means in practice is that the risk isn't really about intent. You can write an app in good faith, ship it, and still get a 4.3 letter because the shape of what you made overlaps with something you've never heard of. That's frustrating, but it's the environment we're all shipping into.
What actually counts as differentiation
The defense that holds up is real differentiation, and "real" is doing a lot of work in that sentence. Changing the color scheme is not differentiation. Renaming the tabs is not differentiation. Swapping a stock icon set for another stock icon set is not differentiation. These are the changes a reskin would make, and review is specifically calibrated to notice them.
What has worked for us falls into three rough categories. The first is functional: the app genuinely does something the comparable ones don't, or does a shared thing in a materially different way. The second is content: the app is built around a specific body of material, a specific dataset, a specific domain, that isn't interchangeable with what the neighbors are shipping. The third is audience: the app is shaped end to end around a group of users whose needs push the design somewhere the generic version wouldn't go.
Any one of these, done honestly, tends to be enough. The trap is trying to argue differentiation on appeal without having built it in. Appeals do sometimes work, and it's worth writing a clear, specific response through the Resolution Center explaining what the app actually does and who it's for. But an appeal that just restates surface differences rarely turns the decision around. Appeals that succeed are typically the ones where the developer can point at a concrete capability or a concrete body of content that the comparison apps didn't have.
Where this leaves a small studio
If you're running a portfolio of small apps, the honest question to ask before each submission is whether this one would be recognizable as its own thing to someone who had never met you. Not to your existing users, who already know the brand, but to a reviewer seeing it cold alongside a queue of other builds. If the answer is that it would mostly be recognizable by its name and icon, that's the signal to keep working before you submit, not to submit and hope.
This is less fun than shipping fast, and it's part of why the small-catalog approach tends to hold up better than the many-similar-apps approach over time. Each app has to earn its slot on the store on its own merits, and 4.3 is the rule that enforces that. Treating it as a design constraint from the beginning, rather than a hurdle at submission, is the shift that makes the rejections stop.