No, two apps cannot have the exact same name on the iOS App Store, because the app name is unique across the entire store and App Store Connect blocks a name that is already taken by any developer. Beyond that basic rule, the details are what usually matter: the subtitle does not have to be unique, so many apps can share a subtitle, and a name that differs from an existing one only by capitalization is treated as the same name, so case is not a way to claim a taken name. Separately, an inactive or effectively dead developer account can still hold a name you want, and reclaiming a squatted name is not guaranteed. So the store name is globally unique and case-insensitive for uniqueness, while subtitles are free to repeat.
Short answer
App names are globally unique on the App Store, but subtitles are not, and case does not create a distinct name. Per Apple's App Store Connect help, you reserve an app name that must be unique across the store, so a taken name is blocked, while the subtitle has no such uniqueness requirement and can duplicate. A name differing only by capitalization counts as the same name and, even if allowed, would risk a copycat rejection under Apple's App Review Guidelines. An inactive account can hold a name, and Apple frees unused reserved names after a period, but a squatted name is not guaranteed to become available.
The rule: app names are globally unique
The base rule is that an app's name on the App Store must be unique across the whole store, so no two apps can carry the exact same store name. When you create or reserve an app in App Store Connect, you enter the name, and if another app already uses it, the system will not let you take it, so the uniqueness is enforced at the point you try to claim the name. This is why a name you want may be unavailable: another developer, somewhere, already has it.
This uniqueness applies to the app name specifically, the primary name shown on your product page and reserved in App Store Connect, up to a limited number of characters. It does not extend to every piece of text associated with your app, which is where the nuances below come in, but for the name itself the rule is simple and absolute: it is one app per name across the entire App Store. So if you are planning a launch, checking and reserving your intended name early matters, because you cannot share it with an existing app and you do not control whether someone else claims it first.
Subtitle uniqueness constraints
The subtitle does not have to be unique, which is the first nuance many developers get wrong. The subtitle is the short line shown beneath your app name on the product page, and unlike the name, it carries no global uniqueness requirement, so multiple apps can use the same or similar subtitles without conflict. You can describe your app with a common phrase in the subtitle even if other apps use the same phrase, because Apple does not reserve subtitles the way it reserves names.
This gives you flexibility that the name does not. Where the name must be a unique string you may not be able to get, the subtitle is a free field for a concise description, so you can convey what your app does with common words. The subtitle still must follow the metadata rules, being accurate and not misleading or stuffed with keywords, but uniqueness is not among its constraints. So if you are worried about differentiating from a similarly-purposed app, the subtitle is not where the uniqueness limit applies; only the name is reserved, and the subtitle is yours to phrase as you like within the content rules.
Is the name case sensitive?
A name that differs from an existing one only by capitalization is treated as the same name, so case is not a way to claim a name that is taken. If another app already uses a name, you cannot register the same word with different capitalization and expect it to count as a distinct name, because the uniqueness check is not defeated by changing letter case alone. Practically, capitalization variants of a taken name are not available to you.
Even in a situation where a case variant slipped through, it would be a poor and risky choice, because two apps with names identical except for capitalization would be confusingly similar, and Apple's guidelines prohibit copycat apps and misleading metadata. So a name that merely re-cases an existing app's name invites a rejection under the copycat and metadata rules, quite apart from the uniqueness check. The takeaway is that case does not make a name distinct for either availability or safety, so if the name you want is taken, changing capitalization is not a workaround, and you need a genuinely different name.
Can dead accounts squat names?
Yes, an inactive or effectively dead developer account can still hold a name you want, and there is no guaranteed way to force it free. A name reserved by, or attached to an app on, an account that is no longer active remains taken as far as the availability check is concerned, so you can find a name unavailable because of an app or reservation that is not even being maintained. This name squatting, whether deliberate or just the residue of an abandoned project, is a real obstacle.
Apple does reclaim some unused names: a name reserved but never used to submit an app within a defined period can be released, so reservations do not hold names indefinitely. But a name attached to an app that was published, even if later removed or on a dormant account, may stay held longer, and there is no reliable, developer-initiated process to seize a name someone else holds. So if the name you want is squatted, your realistic options are to wait in case it is eventually freed, to contact Apple though without any guarantee, or, most practically, to choose a different available name. Counting on reclaiming a squatted name is not a plan you can rely on.
What to do if the name is taken
If the name you want is already taken, the practical path is to differentiate it into an available, distinct name rather than fight for the exact string. Add a distinguishing word or a brand element so the name is genuinely different, not merely a case or spacing variant, since those do not count as distinct and risk a copycat flag. Check availability as you go by attempting to reserve candidates in App Store Connect, which tells you immediately whether each is free.
Reserve your chosen name early, before you are ready to submit, so you lock it in rather than risking someone else claiming it during development. If the taken name is one you have a genuine trademark right to, you may have grounds to raise it with Apple, but for most cases choosing a different available name is faster and more certain than pursuing a name held by another party. So treat a taken name as a prompt to pick a distinct one and reserve it promptly, which keeps your launch on track regardless of who holds the name you first wanted.
Name field rules at a glance
Sorting which fields must be unique clarifies the constraints. The table below compares them.
| Field | Must be unique across the App Store? | Notes |
|---|---|---|
| App Store name | Yes, globally | Blocked if taken; case variants count as the same |
| Subtitle | No | Can duplicate across apps |
| On-device display name | No | The icon label can coincide with others |
| Bundle ID | Yes | Unique per account, in reverse-DNS form |
Read the table by the uniqueness column: only the App Store name and the bundle ID are reserved, while the subtitle and on-device name are free to repeat.
Naming checklist
Working through these steps secures an available, compliant name. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Check availability | Try to reserve the name in App Store Connect | [ ] |
| Differentiate if taken | Choose a genuinely distinct name, not a case variant | [ ] |
| Use the subtitle freely | Describe the app; no uniqueness limit applies | [ ] |
| Avoid trademarked names | Steer clear of copycat and metadata rejections | [ ] |
| Set the on-device name | A concise icon label, which can coincide with others | [ ] |
| Reserve early | Lock the name before you need to submit | [ ] |
The step that most affects your timeline is reserving the name early, since the App Store name is globally unique and you do not control whether someone else claims it while you build.
Secure the build behind the listing
Sorting out your app's name gets your listing in order, but the name is only metadata, and the app users download is what carries the real risk, so it is worth checking the build while you finalize the listing.
A scanner like PTKD.com analyzes your build and reports issues such as leaked keys and secrets, over-broad permissions, and insecure data handling by severity, mapped to OWASP MASVS, so the app behind your unique name is checked for security problems. To be clear about the boundary: PTKD does not reserve your name, set your subtitle, or manage your App Store Connect listing. It checks the build itself, so the app you ship under your chosen name is as sound as the listing is complete.
What to take away
- Two apps cannot have the exact same App Store name, because the name is unique across the whole store and App Store Connect blocks a taken one.
- Subtitles are not subject to the uniqueness rule, so multiple apps can share a subtitle, and only the name is reserved.
- A name differing only by capitalization is treated as the same name and risks a copycat rejection, so case is not a workaround for a taken name.
- Inactive or dead accounts can hold a name you want, and while Apple frees unused reserved names after a period, reclaiming a squatted name is not guaranteed.
- The on-device icon label is separate from the store name and can coincide with others, so if a name is taken, choose a distinct one, reserve it early, and check the build with a tool like PTKD.com.
