An Android rebrand is two jobs, and only one of them is cheap

A dev.to post walks through what actually happens when an Android app gets a new public name but keeps its package identifier, and the useful part is the taxonomy: an Android application carries several identities at the same time, including the name users see, the package identifier Android uses internally, the signing certificate, version information, and the metadata shown by distribution platforms ^[1]. That matters because rebrands are usually scoped as asset work, and only one of those identities is an asset.

The cheap layer is real and it is genuinely cheap. In a typical project the visible name lives in strings.xml as a single `app_name` string, and changing it changes what users see in places such as the launcher ^[2]. From the user's side the app now looks like a different product, while Android still recognises it through other identifiers ^[2][1].

The expensive layer is the application ID, declared in Gradle's `defaultConfig` and fundamentally different from the visible name ^[3]. You can rename Original App to New App and leave `com.example.originalapp` alone, and that is a perfectly normal thing to do ^[4]. Android uses the application ID as part of deciding whether an APK represents the same application: same ID plus compatible signing information, and a new release is recognised as an update ^[5]. Change the ID to `com.example.newapp` and Android normally treats it as a completely separate application, which can leave two apps on the same device ^[6]. Signing behaves the same way. Production APKs are signed with a developer certificate, and changing that certificate can stop Android accepting the APK as an update to an existing installation ^[7], which is the whole argument for guarding production keys ^[8].

Put those together and the consequence is arithmetic rather than opinion: a rebrand that touches the application ID or the certificate does not migrate anyone. Existing users keep the old package, and the renamed build arrives with no installed base to inherit ^[9]. The identity layer is effectively immutable once you have shipped; the cosmetic layer is the only part you can revise for free ^[10].

The same logic runs through version metadata. The post's recommendation is to continue the existing release sequence across a rebrand, versionCode 23 and versionName 2.3 becoming 24 and 2.4, so the public branding changes completely while the technical application stays part of one release history ^[11].

Store listings are where the seams show. A listing can hold a title, description, developer name, screenshots, URL slug, package identifier, version history and older metadata, and some of those fields update immediately while others keep reflecting the previous branding, so the public page can temporarily mix old and new ^[12]. The post points to the Sisal app listing on Uptodown as an example of a public name and a technical history that did not change at the same moment ^[13]. URLs are the stickiest field: platforms tend to preserve them so existing links keep working, which does not affect the installed package but does mean users meet both names for a while ^[14].

Two things to watch on any rebrand of a shipped Android app. First, whether the plan quietly includes a new application ID, because that decision is made by whoever edits the Gradle file and is paid for by whoever owns retention ^[6][9]. Second, custody of the production signing key, since losing it removes your ability to update the installed base at all ^[7][8].