originality-check

Originality Check

Decide, with evidence, whether an app is distinct enough to exist — before you build it or submit it.

> At portfolio scale, shipping many similar small apps risks Guideline 4.3 (spam / duplicate)

> — this is the go/no-go distinctness gate that keeps that from happening.

Where it fits (read the seams)

• Not rejection-handler. That works a rejection you already have. This is upstream — it

prevents the 4.3 by catching sameness before you ship.

• Not competitive-analysis / market-research. Those size demand and position you in the

market. This judges distinctness (function + content + metadata) vs your own portfolio and vs

near-identical competitors — a spam risk, not a demand question.

• Two moments to run it: at validate / new-app (don't build a dup) and before submit

(don't trip 4.3). Also periodically across the portfolio (internal cannibalization / template-sameness).

Prerequisites

• The app idea or a shipped app to evaluate (name, one-line function, target metadata).
• Optional: .planning/VALIDATION.md (competitor + market data). If missing/stale, gather fresh

via WebSearch or the product/competitive-analysis skill.

• Optional ASC access to read the developer's existing portfolio (list_apps / get_metadata).

Flow

1. Internal check (your own portfolio). list_apps → for each shipped app read its positioning

(get_metadata). Does the candidate overlap one you already ship in function, **code

template, or metadata**? Two apps that differ only in theme/reskin = 4.3 risk.

1. External check (the market). Read VALIDATION.md if present; otherwise WebSearch for close

look-alikes. Judge: is the core function a thin reskin of an existing app, or a genuine wedge?

1. Distinctness scorecard. Score each dimension meaningful difference vs cosmetic, and flag any

that is only skin-deep:

| Dimension | Distinct if… |

|---|---|

| Function | it does something materially different, not a template swap |

| Content / data | unique data or content, not a generic wrapper |

| Metadata | name / keywords / screenshots not near-identical to siblings or competitors |

| UX / value | a real reason a user picks this one |

1. Verdict + remedy.

• Distinct → proceed.
• Borderline → give concrete ways to differentiate (merge sibling apps into one configurable

app, add the unique wedge, or drop it); if approved, name the specific wedge that MUST be built

to clear 4.3.

• Duplicate → recommend not shipping; consolidate any existing thin apps into one strong

app instead.

1. Record. Write the verdict + reasoning to .planning/ (VALIDATION or STATE). For a

borderline-approved app, record the wedge as a build requirement so plan/build deliver it.

Done

• A written verdict (distinct / borderline+wedge / duplicate) with per-dimension reasoning, and —

if borderline — the specific differentiation that must ship before submission.

Caveats

• Cosmetic theming ≠ differentiation — Apple judges function + metadata similarity, not intent.
• Protect the account. When in doubt between "borderline ship" and "consolidate," prefer one

strong app over several thin ones.

• Guideline numbers/text drift — confirm current 4.3 wording at the

App Review Guidelines (captured 2026-07).