Guideline 4.1: copycats

Where the line actually sits

Fine:

• The same category, the same problem, a different product.
• Standard platform components and navigation patterns.
• Category conventions: a tab bar where everyone has a tab bar, a card list where everyone has a card list.
• Naming that describes what the app does in ordinary words.
• Comparing yourself to a competitor on your own website, factually.

Not fine:

• A name a user could confuse with theirs.
• An icon in their distinctive style.
• Their interface reproduced, screen by screen.
• Their marketing copy, rewritten lightly.
• Implying an affiliation that does not exist.

The test to apply to your own submission: put your screenshots next to theirs on a phone screen. If someone who knows their app would have to look twice, that is the finding, regardless of what you intended.

The template problem

Templates are legitimate and widely used. The risk is specific and manageable:

Change the parts that carry identity. Colour, typography, icon, copy, onboarding, empty states, and the arrangement of the main screen. Keep the parts that are infrastructure.

Assume the reviewer has seen it. If the template is popular, they have seen several this month, which is exactly why a lightly reskinned one reads as spam rather than as a product.

And this is not only a review problem. An app indistinguishable from fifty others has nothing to say about itself. It cannot be recommended by anything — not a reviewer, not a search engine, not a model answering "what should I use for X" — because there is no sentence about it that is not also true of the others. Guideline 4.2, minimum functionality.

What to check before submitting

# names and marks in your own metadata
grep -rniE 'fastlane/metadata|store' -e '' >/dev/null 2>&1
grep -rniE '(jobber|housecall|uber|tinder|hinge|calm|headspace|notion|duolingo)' \
  fastlane/metadata store src app 2>/dev/null | head

# template leftovers that reveal the origin
grep -rniE 'template|starter kit|codecanyon|lorem ipsum|your app name|example\.com' \
  src app fastlane/metadata app.json 2>/dev/null | head

The second command finds the tell. A submission still containing the template's placeholder copy, sample data or demo assets is the version that gets read as a reskin, and it is a twenty-minute fix.

Then do the visual test: your screenshots beside the nearest existing app, at phone size.

If you are rejected under 4.1

Reproduce the reviewer's view before changing anything. Which app do they think you copied, and looking at both, can you see it? Frequently you can, and the fix is obvious once you stop defending the intent.

Change identity, not features. Name, icon, palette, typography, onboarding copy, the arrangement of the main screen. You are not being asked to build a different product.

Then explain what you changed, briefly, in the Resolution Center. Review notes that work. · After a rejection.

Appealing without changing anything rarely works here, because the judgement is visual and a reviewer looking at two screenshots has already made it.

shipcheck flags template leftovers, placeholder copy and third-party marks in metadata and UI strings. It cannot judge visual similarity, which is a human question, and it says so rather than implying otherwise. What it checks. · The first-submission checklist.

Questions and answers