App Store Name Availability: How to Check a Name Before You Build On It

The Name field in App Store Connect takes 30 characters and tells you nothing about whether you are allowed to keep them. Two boxes further down sits the Bundle ID, which is fixed for the life of the app the moment a build lands against it, and which almost nobody reads before typing.

App store name availability has no official checker. Apple reserves a name to one app per localization inside your own account and settles conflicts with a different developer by trademark claim. Google Play caps the title at 30 characters and does not hand you an exclusive one. Search both stores, then check trademarks.

Two jobs, then. Work out whether the name is free, which is a stranger question than the search boxes on the first page of results suggest. Then work out which boxes on this form you can change later and which you cannot, on both stores, with the character limit for each. The whole sequence from a finished build to a live listing is a separate job; this page assumes you are already in front of the form with the cursor blinking.

Is there an app store name availability checker?

No official app store name availability checker exists. The third-party checkers search public store listings, which tells you what is published today and nothing about what Apple will accept tomorrow. The only Apple-side test that counts is trying to create the app record in App Store Connect.

Search for this question and most of what comes back is a search box. namecheck.com and namecheckly.com do the same job: they query the public storefronts, and one or two social networks, and report matches. Five useful seconds, and neither page tells you the rule Apple actually applies.

A store search proves that a listing with that name is visible in the storefront you searched, in the country you searched from, on the day you searched. It does not prove the name is unclaimed, because an app can be unpublished, region-limited, or sitting in an account as an unreleased record and still hold the name.

Apple’s rule is narrower and stranger than a global register. Its guidance for creating an app record says: “You can use an app name for one app per localization.” The reservation is per localization, and the documented conflict Apple resolves for you is the one inside your own account. Apple does not document what App Store Connect does when a different developer already uses the name. Its published dispute route covers trademark rights, which is the next section.

Google Play works differently again. The title is capped at 30 characters by policy and must not mislead people into downloading the wrong app, and Google’s store listing guidance advises: “Make sure your title is unique, accessible, and avoid common terms.” Read that as advice, because that is what it is. As of 16 August 2026, neither Google’s store listing best practices page nor its Metadata policy states that a Play title must be unique to one app, and Google publishes no name reservation of any kind.

How to check a name is free before you build on it

Four checks, in this order, because each one is cheaper than the one after it.

1. 01 Search both storefronts as a customer would. Search the App Store on a device and Google Play on the web, in every country you plan to sell in, for the exact name and for the name with a space or a hyphen moved. This is the five-second version and it catches the obvious collision.
2. 02 Try to create the app record in App Store Connect. This is the only Apple-side test that means anything, because the New App dialog is the thing that actually accepts or refuses the name. It needs a paid membership to exist first, which is the real reason people skip it and find out later.
3. 03 Search the trademark registries that cover the countries you will sell in. Apple settles a two-developer name conflict by trademark claim, so this is the layer that decides the outcome if the argument ever happens. It is also the check that survives the app.
4. 04 Check the domain and the social handles last. They cost nothing to check and they are not a store rule, so a taken handle is a preference to weigh, never a blocker.

If the name is already used by an app in your own account, Apple documents exactly two ways out: “If an app in your account already uses the app name, you have two options: submit an update to the existing app to change its name, or remove the app from App Store Connect to allow the name to be used in a new app record.”

If a different developer holds it, the route runs through trademark law and not through App Store Connect: “If another developer is using the app name and you have trademark rights to it, you can submit a claim.” That claim goes to Apple’s intellectual property dispute forms, which is where the “submit a claim” link on Apple’s own help page now forwards to. Worth reading before you assume it applies to you: the form asks you to declare, under penalty of perjury, that you are the rights holder or authorized to act for them. It is a trademark process wearing a web form, and without a mark behind it there is nothing to file.

The gap in Apple’s documentation is worth naming instead of guessing around. As of 16 August 2026, Apple’s help states the one-name-per-localization rule and the trademark route, and does not state what App Store Connect does when you type a name that belongs to a different developer’s published app. Step 2 above is how you find out, and it is why it belongs before you print anything or buy anything.

What a bundle ID is, and why it is the part you cannot change

The bundle ID is the app’s permanent internal identity. Customers never see it, it has nothing to do with the name on the listing, and Apple describes it as “A unique identifier for your app that is used throughout the system.”

It is also the one field on the form with no undo. Apple’s App Store Connect reference states it plainly: “You can’t change this property after you upload a build.” The same entry adds an instruction people discover the hard way: “The Bundle ID property must match the bundle ID you set in the Xcode project.” Get the two out of step and you have a build that will not attach to the record you made for it.

The shape is a reverse domain name, com.yourcompany.yourapp, and the convention is only a convention. Pick it deliberately, from a domain you actually control, because the string outlives every product decision above it. When an AI builder mints the identifier for you without asking, that choice is being made on your behalf at build time, and it pays to know which string you were handed before the first upload.

One field over sits the SKU, the other one-way door, and it gets almost no warning anywhere. Apple: “The SKU can contain letters, numbers, hyphens, periods, and underscores but not start with a hyphen, period, or underscore. You can’t change the SKU after you add the app to your account.” It is internal tracking, invisible to customers, and it locks earlier than the bundle ID, because adding the app happens before any build exists.

App Store Connect also generates a numeric Apple ID for the app when you add it. That number appears in the App Store URL on desktop, it is easy to mistake for the bundle ID, and Apple says of it: “You can’t edit this property.”

All three get set in the same sitting as the beta build, which is why registering the bundle ID and creating the matching App Store Connect record is one job. A build that uploads and then never appears against the record is often this pairing going wrong, and it has a diagnosis of its own.

Android calls the same thing an application ID, and Google documents its format as a stricter version of a package name: “It must have at least two segments (one or more dots).” Each segment has to start with a letter, and every character has to be alphanumeric or an underscore. Some Android APIs still say “package name” when they mean the application ID, which is a naming leftover, not two different things.

The permanence rule on Android arrives from a different direction and lands in the same place. Google’s build documentation instructs developers never to alter the application ID once the app is live, because Play keys the listing and everything attached to it to that string rather than to the title above it. What a package name costs you on Play once the app is live is the longer version of that story, and a rebuilt binary that arrives with a different package name is the failure it produces.

The field people spend a week choosing can be changed. The one they fill in without reading cannot.

Which listing decisions you can change later

Every row below is read from Apple’s or Google’s own published documentation on 16 August 2026, and each row carries that date so it still says something if you copy it out on its own. Nothing here comes from an account or from a third-party guide. Two Apple pages are doing the work: the app information reference, which describes each field, and the required, localizable, and editable properties reference, whose tables tick off which properties Apple will let you edit on a live app with no new version behind the change. Where a row below says Apple does not mark something, that is the second page being read for what it ticks and what it leaves blank, and a blank cell is Apple declining to promise rather than Apple forbidding. On the Play side, listing text sits inside Google’s publishing flow, which reviews and publishes store listing changes separately from an app release.

Fifteen rows, ten of them yes. The name that took a week of arguing, the description that keeps getting rewritten, the keywords, the category: all changeable, some of it in minutes and none of it locked. The five that are fixed are a machine identifier nobody reads, an internal tracking code nobody reads, a number the store generates for you, a tick box about children that hardens after review, and the Android equivalent of the first one.

Two of those five lock before you have a finished app. The SKU locks when you add the app to your account and the bundle ID locks on the first upload, and neither moment feels like a decision at the time.

Character limits for every listing field, on both stores

Every limit below is read from Apple’s and Google’s own published documentation on 16 August 2026, not from an account, and each source is linked so you can re-read it yourself. Store limits change without an announcement, so check the source before you commit copy to a design.

Apple, from the App Store Connect app information reference, the platform version information reference, and the product page guide:

Google Play, from the store listing best practices page and the Metadata policy:

The keywords row needs its own paragraph, because Apple publishes two different numbers for it. The App Store Connect reference says: “You can provide up to 100 bytes of content.” The product page guide says: “Keywords are limited to 100 characters total, with terms separated by commas and no spaces.” Both sentences were live on 16 August 2026. If you write your keywords in plain English they are the same budget, because one ASCII character costs one byte. If you localize into Japanese, Arabic, Greek or anything else outside that range, a character can cost two, three or four bytes, and a byte budget and a character budget stop meaning the same thing. Apple does not say which encoding the byte count uses, so treat 100 bytes as the tighter of the two and localize accordingly.

Two more keyword rules catch people, both from the same Apple reference. Each keyword has to be “greater than two characters”, and there is a duplication rule with a reason attached: “Your app is searchable by app name and company name, so you shouldn’t duplicate these values in the keyword list. Names of other apps or companies aren’t allowed.” Putting a competitor’s name in your keyword field breaks a stated rule.

On the Play side, the 30-character title sits in policy. The sentence “Your app title must be 30 characters or less” appears in Google’s Metadata policy, so a longer title breaks a rule instead of merely wrapping badly. The images on both listings carry their own constraints, fixed sizes that vary by store and by device, and that is a separate job from the words.

Choosing a category

The category is a required field on both stores, and it is one of the reversible ones. On Apple it lives in App Information as a primary and an optional secondary category, with subcategories if you pick Games or Stickers. On Play, Google’s instructions put it under Grow users, then Store presence, then Store settings, where you pick an application type and then a category.

Apple’s own advice for picking the primary one is a single sentence and it is the right instruction: “Your primary category should be the one that best describes the main function or subject matter of your app.” Pick the category that describes what the app does, not the one that looks least crowded. A budgeting tool filed under Utilities because Finance looked busy is a tool nobody browsing for a budgeting tool will scroll past.

One category decision does harden, and it is the one aimed at children. Apple states that once an app marked as Made for Kids is approved by App Review, that selection cannot be changed and all later updates have to follow the Kids category guidelines. Treat that tick box with the same care as the bundle ID.

Whether anybody finds the listing afterwards is a different subject, with its own rules and its own arguments, and none of it changes the fact that the category field is asking a plain question about what your app is.

A description that survives review

Structure first. Apple’s product page guide gives the shape in one line: “The ideal description is a concise, informative paragraph followed by a short list of main features.” The same guide notes that the first sentence carries the most weight, because it is what people read before tapping to read more. Apple’s reference adds a detail worth knowing when you write it: the description “will be used for web engine search results once you release your app”, so the first two lines are doing double duty.

Then the rules. Both stores publish metadata policies, and these are the clauses that actually bounce listings:

• Apple’s guideline 2.3.7 opens: “Choose a unique app name, assign keywords that accurately describe your app, and don’t try to pack any of your metadata with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system. App names must be limited to 30 characters.”
• The same guideline bars prices, terms, and descriptions that do not belong to the metadata type they are sitting in, across app names, subtitles, screenshots and previews, and bars subtitles that reference other apps or make unverifiable product claims.
• Apple’s guideline 4.1(c): “You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer.”
• Google’s Metadata policy: “Don’t use emojis, emoticons, or repeated special characters in these metadata elements.”
• Also Google: “Avoid ALL CAPS unless it is part of your brand name.”
• And the one that catches launch copy: “Don’t use text or image in the app title, icon, or developer name that indicate store performance or ranking, price or promotional information, or that suggests relations to existing Google Play programs.” Google’s examples include App of the year, #1, Best of Play 20XX, and award icons.
• Google does not allow unattributed or anonymous user testimonials in the app’s description, so a wall of unnamed five-star quotes is a policy problem.

There is a trap specific to apps built with an AI tool, and it has nothing to do with policy wording. The fastest way to fill a 4000-character description is to paste the marketing copy the builder generated during the build, which describes the app as it was specified rather than as it shipped. Every feature in that text that the current binary does not actually do is a metadata accuracy problem, and a reviewer opening the app with your description beside it will find the gap faster than you will. Read your own description with the app open, feature by feature, before you submit it.

When a listing does come back, what a metadata rejection looks like and how the guideline number maps to a fix is the faster route than rewriting the whole page on instinct.

Common questions about app store names and listings

Can I change my app’s name after it is published?

Yes, with one condition on the Apple side. Apple’s app information reference states that you can edit the name until you submit the app to App Review, and afterwards when you create a new version or when the status of the app version permits editing that property. Apple’s properties reference agrees from the other direction: it leaves Name’s editable column blank, so the change rides on a version rather than landing the moment you save it. On Google Play the title is part of the store listing, and store listing changes go through the normal review and publishing flow with no new build. Neither store treats the name as permanent.

What happens if the app name I want is already taken?

It depends on who holds it. If an app in your own account already uses the name, Apple gives two options: submit an update to that app to change its name, or remove the app from App Store Connect so the name frees up. If a different developer holds it and you have trademark rights, Apple’s route is a claim through its intellectual property dispute forms. Without a trademark there is no route, and the practical answer is a different name.

Does a Google Play app title have to be unique?

No published rule requires it. As of 16 August 2026, Google’s store listing best practices page advises making the title unique and avoiding common terms, and its Metadata policy caps the title at 30 characters and bars titles that mislead people into downloading the wrong app. Neither document reserves a title to one app or promises exclusivity.

Can I change the bundle ID or the application ID later?

No, on both stores. Apple states you can’t change the bundle ID after you upload a build, and it has to match the bundle ID set in the Xcode project. Google’s build documentation says never to change the application ID once the app is published. Along with the Apple SKU, these are the fields where a rushed choice sticks, so decide them before the first upload.

How many characters can an app name be?

Thirty on both stores. Apple requires at least two characters and no more than 30, and repeats the 30-character cap in review guideline 2.3.7. Google’s Metadata policy says the app title must be 30 characters or less. Apple’s subtitle gets its own 30 characters and Google’s short description gets 80, so the line under the name comes out of a separate budget.

Do I need a trademark to use an app name?

Not to publish under it. A trademark matters when someone else is using the name and you want to challenge that use, because Apple publishes an intellectual property dispute route. It also matters in reverse: guideline 4.1(c) bars using another developer’s brand or product name in your app’s icon or name without their approval. Apple does not publish a general first-come rule for names held by different developers.

What is the difference between the app name and the app title?

They are the same field with two vendor names. Apple calls it Name in App Store Connect, Google calls it the app title in Play Console, and both cap it at 30 characters. Apple then adds a Subtitle of up to 30 characters beneath it. Play has no subtitle; its nearest equivalent is the 80-character short description, which sits elsewhere on the listing.

Can I use the same name on both stores?

Yes. Nothing in either store’s published documentation prevents the same name appearing on both, and the 30-character cap is identical, so a name that fits one fits the other. The identifiers underneath are separate: an Apple bundle ID and an Android application ID are set independently, and neither store reserves anything on the other’s behalf.

The name is worth an afternoon and no more, because it is the field the stores let you change. The identifiers are the ones you will live with, and they get typed in a hurry during a step that feels like paperwork. Decide them before the first upload, write them down somewhere that is not the build tool, and the rest of the listing stays negotiable for the life of the app. The pass to run over everything else on the form is worth doing in one sitting instead of field by field, before you submit.