Client wants a new name for a brand upgrade: after the app is live, should you change only the display name or also the package name?

Bottom line first: if you're only changing the name shown on the home screen, the icon, or the splash screen, and you leave the package name and signing key unchanged, existing users can usually keep receiving updates as before. Once you change Android's applicationId or iOS's Bundle ID, app stores treat it as a brand-new app, and the old version on users' phones generally will not auto-update to the new package. In 2026 projects, when a renaming request comes up, first separate whether you're changing the display layer or the identity layer, then decide whether to touch the package name.

First, separate them: changing the display name, changing the package name, and changing the signing key have completely different effects

In custom mobile development, the package name (Android's applicationId, iOS's Bundle ID) is the app's identity on the system and across platforms; the signing certificate is the developer's credential; the app name is just display-layer text. To decide whether two install packages are an update of the same app, app stores look at the combination of package name plus signature, not the name.

• App display name: the text under the home screen icon, the store listing title. Most platforms allow changing it with a version update, and existing users see the new name after updating.
• Package name / Bundle ID: the install package's identity. Most third-party SDKs and platform backends bind to it.
• Signing certificate: participates in update verification together with the package name; changing the signature can also prevent existing users from installing the new package.

The package name is not a brand name; it's the app's ID number in the system: changing the display name is usually safe, while changing the package name is close to re-releasing the app. To decide whether to touch it, first ask whether what changed is brand exposure or app identity.

If you only change the brand name, icon, and splash screen, existing users usually update as normal

If the client is only doing a brand upgrade, changing the icon, or changing the app display name, you usually keep the original package name and signature and submit the new version for review. When the old package on a user's phone recognizes a new version with the same package name and signature, the app store pushes it as a normal update, and the home screen name and icon change after the update.

Note that stores have somewhat different rules for changing app names: some allow it with a version update, while others may require trademark or authorization documents. If the name involves someone else's trademark, it may be rejected. This is not a technical issue but a matter of store review and compliance checking.

When you only change the display layer, the cost is usually lowest, and the risk falls mainly on store review and name compliance, not on the user update path.

After changing the package name, why existing users won't auto-upgrade

The system identifies apps by package name. If the new package name differs from the old one, the system treats them as two independent apps that can be installed side by side, but they won't replace each other, and store updates won't automatically be pushed to users of the old package.

• The update path is broken: store updates and in-app update prompts point to the old package name, so the new package is not on the same path.
• Local data does not migrate automatically: login state, cache, and some order drafts stay in the old package's sandbox.
• Third-party bindings must be reconfigured: push, payment, WeChat login, maps, analytics, and more are mostly applied for by package name and signature.

Changing the package name is not renaming; it's releasing a new app. Existing users need to be actively guided, and you can't rely on the system to complete the migration automatically. The larger the user base, the higher the notification cost and churn risk on this path.

When you don't need to change the package name, and when you should seriously evaluate it

You can draw the line this way: if what changed is brand exposure, you usually don't need to change the package name; if what changed is the development entity, store account ownership, or a conflict with the package name itself, then you need to evaluate it seriously.

• Usually no change needed: only changing the display name, icon, launch screen, in-app copy, or campaign pages.
• Usually no change needed: the company name changes, but the developer account, signing certificate, and store entity can still be used.
• May need to change: the package name is taken, the platform determines a conflict, or the original package name involves compliance issues.
• Usually needs to change: the app must be separated from the original entity, the original account cannot be transferred, or the original package name has been banned.

Most renaming requests are not worth changing the package name for; the cost of changing the package name is not editing one line of config, but going through listing, bindings, and user migration all over again. First separate what must change from what can be negotiated, then decide how to spend the budget.

If you really need to change the package name: common paths and experience ranges in 2026

Based on common project delivery practices in 2026, you can first judge by three paths. The core issue is not technical difficulty, but whether you can preserve the update path for existing users.

• Path 1: Keep the original package name and change only the display name. Suitable when you already have existing users and are only rebranding. Cost is usually low, and the timeline is close to a normal release; the experience range is a few days to one or two weeks, depending on store review. The trade-off is that the package name cannot reflect the new brand, but users update without noticing.
• Path 2: New package name plus migration prompts from the old package. Suitable when the entity must change or the original package can no longer be maintained. Keep a transitional version of the old package and use pop-ups to guide downloads of the new package. The trade-offs are dual-package maintenance and some user churn; the typical migration window is 1 to 3 major versions or a few months.
• Path 3: Run both packages in parallel and switch gradually. Suitable when the old package still has channel contracts or service-period constraints. List both packages at the same time and control entry points through server-side configuration. Long-term maintenance costs are higher, and the old package's stop-update time should be agreed in advance; the typical range also needs to be assessed based on contracts and user volume.

The main basis for choosing a path is not technical difficulty, but the size of the existing user base and the migration window; the larger the user base, the more you should prioritize evaluating the option of keeping the original package name.

A common constraint on delivery is that the budget only allows one release, the timeline is stuck right before a campaign launch, and the client suddenly asks to change the package name from the company's pinyin abbreviation to the brand name. A safer approach is to keep the original package name for the current cycle and change only the display name, then schedule the actual package change for the next version. The result is saving one re-review and multiple third-party backend reconfigurations, at the cost of delaying brand exposure under the new package name by about one version. In terms of experience range, the backend reconfiguration and migration guidance from a package change usually add one to several weeks compared with a normal release, depending on the number of payment, push, and login bindings.

Applicable and non-applicable boundaries

Scenarios suited to evaluating with this article's approach: the app is already live, has existing users, and the client proposes renaming, rebranding, or adjusting the entity. At that point, first separate the display layer from the identity layer, then decide whether to touch the package name.

Non-applicable scenarios: the app is not yet live, or is still in beta with no third-party bindings or real users; in that case the package name is a one-time choice, and you can just package it according to the new naming rules—discussing migration has little meaning. Boundary reminder: for apps with payment, login, push, and order data and a large user base, prioritize evaluating keeping the original package name.

Before launch, the package name can be set according to the new rules; after launch with users, avoid changing the package name if possible. This boundary matters more than the technical approach itself.

FAQ

If I only change the app display name, do existing users need to re-download?

Usually no. Submit the new version with the original package name and signature, and the app store pushes it as a normal update. Existing users see the home screen name change after updating, and login, push, and payment bindings are generally unaffected.

After changing the package name, will the old and new versions be installed on the phone at the same time?

Yes. With different package names, the system treats them as two independent apps that can coexist; but data from the old package does not migrate automatically to the new one, so you need a separate migration or to guide users to log in again.

Can the iOS Bundle ID still be changed directly after launch?

Once created, a Bundle ID basically cannot be changed directly; you usually have to create a new one and use a new app record. Existing users cannot directly update to the package with the new Bundle ID.

After changing the package name, can push and payment configurations still be used?

Most cannot be reused directly. Push, payment, WeChat login, and similar services are applied for by package name and signature. If the package name changes, you need to re-register or create a new app, and the old configuration generally no longer works.

How long is it appropriate to maintain the old package?

The experience range is to keep the old package for 1 to 3 major versions, or a few months. During that time, the old package only handles migration guidance and necessary security fixes, with no new features added.

If you're the product owner, first confirm whether this change is the display name or the app identity; when only the name changes, keeping the package name is usually less trouble. If you really need to change the package name, put existing-user migration, third-party bindings, and store re-review on the same plan, reserve a longer window than a normal release based on common 2026 delivery timelines, and align early with operations, payment, and marketing teams.