How checkappnames matches app names
Every result this tool produces comes from a small set of rules applied to live store listings. This page documents those rules exactly — what gets normalized away before two names are compared, what separates a conflict from a lookalike, which storefronts are queried, and the cases where the answer is wrong or incomplete. If a result surprised you, the explanation is almost certainly on this page.
The pipeline, end to end
- 1You submit a name and a set of storefronts. The server validates that list — the scan size is derived from what the server accepts, not from what the browser claims.
- 2Each storefront is queried against Apple's public iTunes Search API through a bounded concurrency pool, in the storefront's own language. A full scan also queries Google Play.
- 3Every returned listing title is normalized, then classified against your name as an exact match, a similar match, or no match.
- 4A storefront is reported as found if any listing was an exact match, possible match if the strongest signal was a similar one, and not found otherwise.
- 5Results stream back as each storefront answers, so you see conflicts before the scan finishes. The finished scan is stored for 90 days.
Normalization: what is stripped before comparison
Two names that a person reads as identical are rarely identical as strings. “Café-Mate”, “Cafe Mate” and “CafeMate” are three different byte sequences describing one brand. Before anything is compared, both the listing title and your query pass through the same four steps:
| Step | What it does | Example |
|---|---|---|
| NFKD | Decompose every character into base plus combining marks | é → e + ́ |
| Strip U+0300–U+036F | Remove Latin combining diacritics | e + ́ → e |
| NFC | Recompose what survived, then lowercase | ホ + ゙ → ポ |
| Strip non-alphanumeric | Drop everything outside Unicode letters and numbers | cafe-mate → cafemate |
Why the recomposition step exists
The third step is not cosmetic, and it is worth explaining because it is the kind of bug that produces confidently wrong results. NFKD does not only split accented Latin letters — it also splits Japanese kana into a base character plus a combining dakuten or handakuten at U+3099/U+309A. Those are combining marks, so the final “keep only letters and numbers” pass deleted them. The result was that ポ silently became ホ, and every voiced kana in the Japanese storefront was compared against the wrong character. Recomposing to NFC before that pass restores them. Accented Latin text is folded on purpose; Japanese is not.
Exact match versus similar match
A listing is reported as an exact matchin one of two cases. Either the two names are identical once normalized, or the listing begins with your query’s complete run of words. The second case covers the standard store title shape, where a brand is followed by a descriptive tail: “Spotify: Music and Podcasts” is an exact match for “Spotify”, because the listing opens with your whole name and then keeps going.
That rule is narrower than it used to be, deliberately. The original implementation asked whether the listing title containedthe query anywhere in its text. Under that rule “go” was a hard conflict with “Pokémon GO”, and “fit” was a hard conflict with “Benefit Tracker”. Those listings still surface — but as possible matches, which is the honest severity. Reporting a short generic word as a blocking conflict in forty storefronts is worse than useless; it teaches you to ignore the results.
A listing is a similar matchwhen at least half of your query’s words overlap with the listing’s words, where a word counts as overlapping if either contains the other. The threshold is 50%, and it is a blunt instrument on purpose: it is tuned to surface things worth a human glance, not to be right on its own.
This is where false positives live. A two-word query needs only one overlapping word to clear the bar, so “Task Flow” will flag “Flow State Meditation”. That is the trade being made: a similar match is a prompt to look, and looking is cheap. A missed conflict found after you have shipped is not.
Found
A listing is the same name.
Treat an exact match in a market you plan to enter as a real problem.
Possible match
A listing shares most of its wording.
Open it. Compare category, developer, and how the two brands read side by side.
Not found
Nothing crossed either threshold.
A clean signal for that storefront at that moment — not a guarantee.
Storefront coverage
Apple operates far more storefronts than any tool needs to check. A full scan covers 44 of them, chosen for market size and for the likelihood that a naming conflict there actually costs you something. The first 10 are queried first on every scan, including the free preview, so the most common conflicts surface within a second or two.
Each storefront is queried in its own language, because the listings returned depend on it. The locale column below is the exact value sent with each request.
| Storefront | Code | Locale | Tier |
|---|---|---|---|
| United States | us | en | Priority |
| United Kingdom | gb | en | Priority |
| Germany | de | de | Priority |
| Japan | jp | ja | Priority |
| Australia | au | en | Priority |
| Canada | ca | en | Priority |
| France | fr | fr | Priority |
| Turkey | tr | tr | Priority |
| Brazil | br | pt | Priority |
| India | in | en | Priority |
| Italy | it | it | Full scan |
| Spain | es | es | Full scan |
| South Korea | kr | ko | Full scan |
| Mexico | mx | es | Full scan |
| Russia | ru | ru | Full scan |
| Netherlands | nl | nl | Full scan |
| Sweden | se | sv | Full scan |
| Norway | no | nb | Full scan |
| Denmark | dk | da | Full scan |
| Finland | fi | fi | Full scan |
| Poland | pl | pl | Full scan |
| Austria | at | de | Full scan |
| Switzerland | ch | de | Full scan |
| Belgium | be | nl | Full scan |
| Portugal | pt | pt | Full scan |
| New Zealand | nz | en | Full scan |
| Singapore | sg | en | Full scan |
| Hong Kong | hk | zh | Full scan |
| Taiwan | tw | zh | Full scan |
| Saudi Arabia | sa | ar | Full scan |
| UAE | ae | ar | Full scan |
| South Africa | za | en | Full scan |
| Argentina | ar | es | Full scan |
| Chile | cl | es | Full scan |
| Colombia | co | es | Full scan |
| Indonesia | id | id | Full scan |
| Malaysia | my | ms | Full scan |
| Thailand | th | th | Full scan |
| Philippines | ph | en | Full scan |
| Vietnam | vn | vi | Full scan |
| Egypt | eg | ar | Full scan |
| Israel | il | he | Full scan |
| Pakistan | pk | en | Full scan |
| Nigeria | ng | en | Full scan |
Google Play is checked once per full scan rather than per country, because Play’s catalog is not partitioned into per-country listings the way the App Store’s is.
Limitations
These are the cases where a result is wrong, stale, or narrower than it looks. They are listed here rather than buried because knowing them is what makes the rest usable.
It is a point-in-time search, not a registry
Results reflect what the stores returned at the moment you ran the scan. A listing published minutes earlier, or a title changed after indexing, may not appear yet.
Search ranking bounds what we can see
Each storefront returns a ranked page of results for your term, not the complete catalog. A very low-ranking listing with a conflicting name can fall outside that page.
Storefronts can fail or rate-limit
A storefront that errors or throttles is reported as such rather than as clean — an unanswered country is never counted as available. If nothing usable came back at all, a paid scan is refunded automatically.
Google Play coverage is thinner
Play has no equivalent public search API, so that half of the check is scraped and can return unavailable. Treat a Play result as a weaker signal than an App Store one.
Similar matching has no semantic understanding
It compares words, not meanings. It will not notice that your name is a translation of an existing one, a homophone, or a deliberate misspelling that reads identically to a user.
Availability is not legal clearance
Nothing here searches trademark registers. A name can be entirely absent from every app store and still infringe a registered mark. This is the limitation that costs the most when ignored.
Sources
- Apple — iTunes Search API
The endpoint every App Store lookup on this site uses.
- Unicode Standard Annex #15 — Normalization Forms
Defines NFKD and NFC, and the decomposition behaviour described above.
- Unicode — Combining Diacritical Marks (U+0300–U+036F)
The block stripped during accent folding.
- Unicode — Kana combining marks (U+3099, U+309A)
The dakuten and handakuten that made the recomposition step necessary.
- App Store Connect Help — App information
Apple’s rules for the display name a scan compares against.
- Google Play Console Help — Store listing requirements
The Play title field and its 30-character limit.