Quick answer: Use reverse-domain notation on a domain you actually own — com.yourdomain.appname. On Android this is the application ID; on iOS it is the bundle identifier. Both must be globally unique, and both are permanent once the app is published: Google states an application ID can never be changed or reused after publishing, even if you unpublish, and an iOS bundle ID cannot be changed once it is attached to a shipped app. Check the ID is free before you commit with the Google Play Name Checker, and register the matching domain first.
| Rule | Why |
|---|---|
Reverse-domain, e.g. com.acme.notes |
Guarantees global uniqueness via a namespace you control |
| Own the domain it is derived from | The ID is permanent; the brand it points at should be yours — check it |
| Lowercase, at least two segments | Required shape; each segment must start with a letter |
No example, test, myapp, or a builder's default |
You will be stuck with it forever |
| Never a real trademark you don't hold | The ID is visible and permanent evidence |
Almost everything in an app launch is reversible. You can rename the app, redesign the icon, rewrite the description, change the price, switch the category. The application identifier is the exception. Get it wrong and the only fix is a brand new listing with zero installs, zero ratings and zero reviews.
It is also, reliably, the field people fill in fastest — often with whatever default their build tool suggested.
What it is, on each platform
- iOS: the bundle identifier. Set in Xcode, registered against your Apple Developer account, and attached to the app record in App Store Connect. Once a version has shipped under it, it is fixed.
- Android: the application ID. Declared in your Gradle configuration. Google's own documentation is unambiguous: after your app is published on Google Play, the application ID cannot be changed, and it cannot be reused — not by another developer, not by you, and not after you unpublish.
Both use reverse-domain notation: com.acme.notes for acme.com and an app called Notes.
Why reverse-domain, and why the domain matters
The convention exists to solve uniqueness without a central registry. Domain names are already globally unique and already owned by someone, so borrowing that namespace means two developers who each control their own domain can never collide.
Nothing checks that you actually own the domain — there is no DNS lookup at build time. But consider what you are doing if you skip that part: you are permanently and publicly attaching your app to a namespace belonging to someone else, in a field you can never edit. If the domain is later bought by a competitor, or the name turns out to be a trademark, the identifier is fixed evidence of what you did.
Registering the domain first costs a few dollars and you need it anyway — Apple will not review your app without a working support URL, and both stores require a privacy policy URL.
Check the domain behind your package ID →
Composing it
Take acme.com and an app called Notes:
acme.com → com.acme → com.acme.notes
The shape rules, which trip people up more than the concept does:
- Lowercase. Mixed case is technically tolerated in places and consistently a source of bugs.
- At least two dot-separated segments.
- Every segment starts with a letter, then letters, digits or underscores.
- No hyphens.
smart-notes.combecomescom.smartnotes, notcom.smart-notes.
And the judgement rules:
- No
example,test,demo,myapp, or your builder's default.com.example.myappis the single most common permanent mistake in mobile. - No trademark you do not hold. The ID is permanent, public, and an unhelpful thing to point at in a dispute.
- Do not encode a version or a year.
com.acme.notes2026will outlive 2026.
Verify before you commit
A package ID that already exists on Play is gone — permanently, whether or not the listing is still live. Check it before your first release build, not after:
Check a package ID on Google Play →
The App Store Name Checker does the same check under Developer details, alongside the app name itself, the matching domains and the npm package name if you are publishing one.
Where this sits in the launch
The identifier depends on the name, and the name depends on what is actually free — so the order is: name, then domain, then ID, then everything visual. The Ship an App path lays out all eight steps in the order of how hard each one is to undo. This one is step four, and it is the point of no return.
