After an app is published, if I want to change the app name to a new brand name, do I also have to change the package name?

Conclusion first: After an app is published, what can usually be changed is the app name, subtitle, icon, screenshots, and description shown in the store, and you can resubmit for review after the change; what cannot be changed easily is the package name, meaning Android's applicationId and iOS's Bundle ID. Platforms generally treat it as the app's fixed identity, tied to the signing certificate, push, third-party login, payments, and store listing records. If you really want to change the package name, in most cases it is equivalent to releasing a new app, and existing users cannot directly upgrade over the old one. Whether it is worth changing depends on the scale of existing users, how deeply third-party capabilities are bound, and brand benefits, not just whether the name sounds good. Based on 2026 mobile delivery experience, a more common and stable path for rename requests is to change only the display name, keep the original package name, and reserve a package name change for a major version or a new product line.

1. What can and cannot be changed: start with two categories

The app name, subtitle, icon, screenshots, keywords, and description visible in the store are display-layer information. After changes are resubmitted for review, they update on the user side once approved, and the upgrade path is basically unaffected. The package name, by contrast, is a system-layer identity. After one launch, the platform identifies the app by it, and if it changes, the system treats it as another app.

Overwrite installation, push delivery, and third-party callbacks all rely on this identifier for matching. Once the identifier changes, the old version cannot be overwritten and upgraded by the new installation package, existing users can only uninstall and reinstall, and downloads, reviews, and search weight in the store will not automatically migrate. According to common practice in 2026, changes to display information still require resubmission for review, but the review scope is much smaller than changing the package name.

• Can be changed directly: app name, subtitle, icon, screenshots, keywords, description, version update notes.
• Can be changed but needs coordinated checks: server domain, privacy policy link, customer service entry, version number naming rules.
• Basically cannot be changed: package name / Bundle ID, signing certificate subject information, developer account subject of an already published app.
• Costly to change: third-party login, payments, push, maps, analytics, and other external capabilities registered by package name.

2. Once the package name changes, it affects more assets than expected

Behind one package name, several external systems are usually attached: push certificates, third-party login callbacks, map and analytics key whitelists, store listing links, and channel packaging scripts. If one item is missed during the change, post-launch symptoms can include login failure, push not being received, or share callbacks not responding, and troubleshooting often requires cross-platform joint debugging.

• Push: Platform push certificates and vendor channels are usually applied for by package name, and must be reconfigured after the name change.
• Login and payments: Callback addresses and app signatures are registered by package name; without changing them, callbacks may fail.
• Maps, analytics, risk control: Keys often include a package name whitelist, and changing the package name requires creating new apps.
• Store assets: Download links, distributed QR codes, and search listing records will not automatically follow.
• Server side: App identifiers in event tracking and APIs, along with rollout rules, also need to be adjusted in sync.

What is easily underestimated here is the troubleshooting cost of missed configurations. The technical actions themselves are not complex, but once spread across different platforms, they require checking across backends. According to typical range, when three to five or more third-party capabilities are bound, the overall cost of changing the package name usually already exceeds the brand benefit brought by one rename, and this becomes more obvious once existing user volume grows.

3. Delivery scenario: how rename requests are usually handled when budget and schedule are tight

In custom mobile delivery, a common situation is that the client proposes a brand rename near the end of the project and hopes to change the package name along with it. The constraints are usually that most of the budget has been used, only three to four weeks remain before launch, and third-party login, payments, and push have already been configured under the old package name. A stable approach is not to agree directly to changing the package name, but to first do an asset inventory, confirm which external capabilities are registered under the old package name, which can be reused, and which must be reapplied for, and then decide whether to change only the display name or create a new app.

A fairly common outcome is to first change only the store display name, keep the original package name for launch, and put the package name change into the next major version or new product line plan. This saves the effort of resubmitting for review, running two packages in parallel, and migrating users. The trade-off is a long-term mismatch between the old package name and the new name, so internal documents, customer service scripts, and channel materials must note that 'the package name is a historical legacy and does not affect use.' According to experience range, preparing and submitting only a display name change usually takes one to three business days plus the review cycle; creating a new app with a changed package name typically takes two to six weeks, and requires extra arrangements for user guidance and data continuity.

4. Four-step checklist framework: go through it before changing the identifier

The risk of renaming basically comes from invisible binding relationships, so the order should be inventory first, then assessment, then migration, and acceptance last, which can keep rework out of the schedule. The point is not to go through the motions, but to make each binding land on a specific backend and owner, avoiding missed configurations discovered only after launch.

1. Asset inventory: List package name, signing, push, login, payments, maps, analytics, deep links, and channel packages one by one, mark the binding method and owner, and make sure each item can be traced to a corresponding backend or configuration file.
2. Impact assessment: Score by existing user scale, number of bound external capabilities, and store listing and ad delivery status. The experience range is that when three to five or more third-party capabilities are bound, the overall cost of changing the package name usually already exceeds the brand benefit.
3. Choose a path: Change only the display name, commonly submitted in one to three business days plus the review cycle; create a new app with a changed package name, commonly two to six weeks for preparation and dual-platform launch; running two packages in parallel is feasible short term, but long-term maintenance costs rise.
4. Regression acceptance: Verify login, push, payments, sharing, and deep links item by item, and confirm whether existing users can overwrite and upgrade. Write the acceptance criteria into a checklist in advance, avoiding a standard where 'it opens, so it passes.'

5. Comparison of three approaches: rename only, create a new app with a changed package name, and keep it unchanged

Breaking the choice into three paths makes the decision much clearer. The main difference is not technical difficulty, but whether users can upgrade without noticing and whether two packages must be maintained later.

• Rename only: Done in the store backend; users only see the name change, with no change to the installation and upgrade path. Suitable when the name slightly deviates from the business or the brand is being fine-tuned. The main cost is resubmission time, with an experience range of one to three business days plus the review cycle.
• Create a new app with a changed package name: Equivalent to releasing a new app; existing users cannot overwrite and upgrade, so you need to guide downloads and handle account and data continuity. Suitable for a complete brand rebuild, a small existing user base, or projects where product lines are split by brand. Preparation and launch typically take an experience range of two to six weeks.
• Keep it unchanged: Zero changes, but the name and brand remain inconsistent long term. Suitable for projects where the package name already carries payments and login systems and the user base is large; in this case, a more cost-effective approach is to first polish the display name, icon, and store assets.

The judgment order is usually: whether existing users can accept re-downloading, whether all third-party capabilities need to be reconfigured, and whether you are willing to maintain two packages later. If two of the three lean toward 'cannot accept, need reconfiguration, not willing,' then keeping the original package name and changing only the display name is more stable.

6. Applicable scenarios and boundaries

When it is suitable to make the change: The app has not yet been officially published, or is only circulating during internal testing; at this point, the cost of changing the package name is basically just re-signing and repackaging. Channel packages and demo packages that are not aimed at public users can also be adjusted according to internal naming rules.

When it is not recommended to make the change: When the package name already carries a full set of capabilities such as payments, login, and push, and there is a stable user base, it is usually not worth changing the identifier for a single rename. If you only want to change the icon, change copy, or create a short-term campaign page, there is no need to touch the package name either.

To put it more directly: if the brand benefit of changing the package name cannot cover the costs of republishing, user migration, and long-term dual-package maintenance, keeping the original package name and changing only the display name is usually the more stable choice. The boundary should also be clear: changing only the display name solves display issues on the store and user side; it cannot solve rename needs at the level of brand domains, backend systems, or contract entities, which require separate planning.

FAQ

After an app is published, will changing only the app name affect existing users' updates?

Usually not. If only the store display name is changed and the package name remains the same, existing users can still receive version updates, and the desktop name refreshes with the store information.

After changing the package name, can the old app's push still be used?

It is not recommended to continue relying on push under the old package name. After changing the package name, the push certificate usually must be reapplied for; if the old app is no longer maintained, the old push channel generally needs to be separately disabled.

Is changing the package name equally difficult on iOS and Android?

After launch, neither platform allows changing the identifier directly. On iOS, changing the Bundle ID usually means creating a new app; on Android, changing the applicationId is also treated as a new app. Both require republishing.

If I change only the icon and screenshots, does it also need a new review?

Most stores still require resubmission for review of display information changes such as icons, screenshots, and descriptions. They take effect for users only after approval, and the review cycle is commonly a few hours to a few days.

If the package name is finalized during development, is there anything to confirm in advance?

A common practice is to name it with the company domain in reverse order plus the product line, and to confirm in advance whether third-party platforms can accept it and whether it conflicts with existing apps or trademarks, avoiding a passive situation after launch.

If the name only slightly differs from the brand, prioritize changing the display name in the store backend and update the wording on the official website, download page, and documents at the same time. If you really need to change the package name, do an asset inventory first and schedule third-party reconfiguration and user migration into the timeline. For projects where the package name is bound to many external capabilities, it is generally not recommended to change the identifier just for a single rename request.