How to Name an App

First: does the app need its own name at all?

Before naming anything, settle whether this app is your company wearing a different hat or a genuinely separate product. If the app is the business, give it the company name and stop: one name is cheaper to build, cheaper to defend, and easier for customers to hold. If it is one product among several, it earns a name of its own and everything below applies.

That decision has a whole framework behind it, including what every extra name costs you forever, in naming a product vs. naming a company. Do not skip it. The most expensive app naming mistake is creating a second brand that nobody asked for.

The constraints the stores impose

These are the rules of the surface your name lives on. They are unusual enough that a name which works perfectly on a website can fail here.

• The visible name is about thirty charactersBoth major stores cap the app name shown on your listing at around thirty characters, and they have done for years. That is the hard ceiling on the string a customer reads, and it has to hold your brand name and any qualifier you were planning to attach. Check the current developer guidelines before you commit, because store policies do change.
• The home screen shows far lessUnder the icon, a phone displays roughly a dozen characters before it truncates, and the exact figure varies by device, font size, and language. That is the name most customers will actually look at every day, so read your candidate as its truncated form and see whether it still reads as a word rather than a fragment.
• The subtitle carries the explanationBoth stores give you a short line under the name, again around thirty characters. This is the single most useful thing about app naming: you do not need a self-explanatory name, because the store gives you a dedicated field for the explanation. Put the brand in the name and the category in the subtitle.
• Search fields are separate from the nameOne store gives you a hidden keyword field, the other reads your descriptions. Either way, the discovery text is not the name, so stuffing categories into the name buys you less than it costs you in brand clarity. Do not repeat words in the keyword field that already appear in your title.
• Two apps can share a nameUnlike domains, store names are not unique. Somebody else can publish an app called the same thing tomorrow, in a different category or the same one. Your defence is distinctiveness and a trademark, not the store’s uniqueness rules, because there are none to rely on.

The third constraint is the one to internalise. Because the store hands you a dedicated line for the explanation, an app name is free to be short and brandable rather than descriptive, which is not true of a company name that has to survive alone on a business card.

Brandable or findable? Use both fields

The old app-store advice was to cram category words into the name, because store search weighted the title heavily and nobody was searching for your brand yet. The instinct is understandable and it is a bad trade today. Stores restrict keyword-loaded names, customers read them as spam, and a name assembled from category words is exactly the generic name that cannot be found later, once you finally have brand demand of your own.

The resolution is structural rather than clever: brand in the name, category in the subtitle. You get the distinctiveness that compounds and the words that describe, in two fields the store already gives you. If your name is failing the findability tests rather than the store’s rules, the deeper diagnosis is in is your brand name too generic.

The parts you cannot rename later

Everything visible about an app name is editable. Several invisible things are not, and they are decided long before anyone thinks the naming conversation has started.

• The bundle or package identifierThe reverse-domain string that identifies your app to the platform is set once and effectively permanent after publishing. Renaming your app later is a marketing exercise; changing this identifier means shipping a different app and asking every user to reinstall. Choose it from your company domain rather than the product name, so a future product rename never touches it.
• The store listing URL slugThe web address of your listing is derived from the name at creation time on at least one store, and it does not always follow a later rename. It will keep quoting the original name in links, analytics, and shared URLs for the life of the app.
• Custom URL schemes and deep linksThe scheme your app registers for deep links is baked into every link anyone else has published, every integration, and every email template. It can be added to, but the old one has to keep working, so treat the first choice as a commitment.
• The name your first users learnedLess technical and just as sticky: the string in their home screen search, their saved shortcuts, and their recommendations. Renaming an app leaves a trail of people who cannot find something they installed under a different word.

The practical rule takes one line: identify by company, present by product. A bundle identifier built from your company domain survives every rename the product ever goes through, and costs nothing to choose correctly on day one.

Five checks before you submit

Run these in order. The first four take an afternoon between them, and the fifth turns the remaining argument into a score.

1. Read it truncated, on a phonePut the name on a real device under a real icon, in your longest supported language, and see what survives. If the truncated form reads as a random syllable, either shorten the name or accept that your icon is doing all the recognition work.
2. Search the store for itType your candidate into both stores. If an established app already owns that word in search results, you are launching into a fight for your own brand query, and no amount of store optimisation reliably wins it back.
3. Say it, then have someone spell itApp discovery runs on word of mouth and store search, which means someone has to hear the name and type it. Any ambiguity between hearing and typing sends that customer to a competitor with a similar name, because store search is unforgiving about spelling.
4. Check the other markets you ship toApps are global by default: you publish once and appear in every storefront you enable. That makes cross-language screening less optional than it is for a local business, and it is worth doing before launch rather than after a support ticket explains the problem to you.
5. Score the name against the checkable propertiesDomain availability still matters, because an app needs a website for support, privacy policy, and deep links. Run the candidate through the same four checks any brand name deserves, and treat the store constraints above as an extra filter on top rather than a replacement.

Step four deserves more than a glance, because an app is published into every storefront you enable rather than into one market. The screening method is in the cross-language safety checklist, and the general pre-launch battery is in how to test a brand name.

Four ways app names go wrong

Two of these get an app rejected, and two of them are slower and more expensive.

• Stuffing the name with categoriesNames like “Notes, To Do List, Tasks, Planner” are a bet on a search algorithm rather than a brand, and both stores restrict irrelevant or keyword-loaded names. The title and subtitle split exists precisely so you do not have to do this.
• Borrowing someone else’s brandIncluding another company’s trademark in your app name, even as “for X” or “X client”, is one of the most common rejection reasons and one of the most common takedowns. If your app works with a platform, say so in the subtitle or description, not in the name.
• Naming the app after the current feature setAn app called for the one thing it does today becomes a liability the first time you add a second thing. Names ship for years; feature sets do not.
• Tying the bundle identifier to the product nameThe one genuinely irreversible decision in this list, and it gets made in five seconds during project setup. Base it on your company domain, keep the product name out of it, and you can rename freely later.

Worth repeating because it is the one with no undo: the identifier decision is made in the first minute of a new project, usually by whoever ran the setup command, and it outlives every name the app ever wears.

Frequently asked questions

How do you name an app?

Pick a short, distinctive brand name that survives truncation under an icon, and let the store’s subtitle field carry the explanation of what the app does. Check that no established app already owns the word in store search, make sure the name can be heard and typed without ambiguity, and base your bundle identifier on your company domain rather than the product name so a future rename stays possible.

How long can an app name be?

Both major stores cap the visible app name at around thirty characters, and the home screen under the icon shows far less, roughly a dozen characters depending on the device, language, and font settings. Store policies change, so check the current developer guidelines, and in practice design for the truncated form rather than the maximum.

Can two apps have the same name?

Yes. App store names are not unique the way domains are, so another developer can publish an app with your name in the same category. Your protection comes from distinctiveness and from trademark rights, not from the store, which is a reason to avoid generic names for anything you intend to build a brand on.

Should I put keywords in my app name?

Sparingly at most. Both stores restrict names loaded with irrelevant terms, and a keyword-stuffed name trades brand clarity for a short-term ranking effect. The subtitle field and the keyword or description fields exist for discovery text, so put the brand in the name and the category words where they belong.

Can I change an app name after launch?

The display name yes, the identifiers mostly no. You can update the store listing name and the label under the icon, but the bundle or package identifier is effectively permanent after publishing, listing URLs may keep the original name, and existing deep links have to keep working. Rename the presentation freely, and choose the identifiers as though they are forever.