Flutter Package Name Change and App Signing: Fixing Mistakes

You are halfway through rebranding a Flutter template. The new logo is in, the colours are yours, and then something goes wrong that no tutorial warned you about. Play Console rejects the upload. Google Sign-In fails with an error code and no explanation. Or you notice the build you shipped last month still carries com.example, or the template author's ID, and the keystore that signed it is on a laptop you no longer have.

Most guides on how to change the package name and set up app signing in Flutter assume you are starting clean. This one is for when you are not. It covers the mistakes that most often stop a reskin halfway, what each one costs, and which ones can be undone. Some cannot, and it is better to know that now than after another week of trying.

These mistakes also compound. A leftover author ID or demo content does not only break builds. It is the kind of thing App Review notices under the App Store 4.2.6 template rejection rules, which also expect the app to come from your own developer account, not the seller's. Fixing identity and passing review are largely the same job.

We will not repeat the step-by-step rename or the first signed build here. Both are in our Help Center and linked below. This post is about recovery.

Work out which mistake you have

Match the symptom to the cause before changing anything. Half the time people fix the wrong layer.

Symptom	Likely cause	Recoverable?
Play Console refuses the upload because of the package name	com.example left in applicationId, or an ID already taken	Yes, if nothing is published
App is live under the wrong ID	ID changed too late, or never changed	Not in place
Play says the bundle is signed with the wrong key	A different upload keystore from the one Play has on record	Yes, with Play App Signing
Keystore or its passwords are gone	No backup	Yes with Play App Signing; no if you held the signing key yourself
Google Sign-In fails with error 10, Maps shows a grey grid, Firebase goes quiet	New ID or key not registered with Google's services	Yes
Xcode reports a provisioning or signing error	Bundle ID, App ID, profile and certificate disagree	Yes

You published with the wrong package name or bundle ID

Start with the honest answer. Android's documentation says that once you publish, you should never change the application ID, because Google Play treats the upload as a completely different app. App Store Connect says the bundle ID can't be changed after you upload a build. No setting or support ticket renames a live app. You have three options.

Live with it. Users rarely see the ID; it shows in the Play Store URL and in device settings. If it is merely ugly, keeping it costs nothing. If it is the template author's own ID, think harder, because you have shipped someone else's name inside your app.

Publish a new app under the right ID. You start again at zero installs, ratings and reviews, and existing users get no updates from the new listing. The old ID is not freed either: Google's page on deleting an app says a package name with any lifetime installs can never be reused, even by your own account. Apple will not let you delete an explicit App ID once an app using it has been uploaded to App Store Connect.

Transfer, if the real problem is the account. A common version of this mistake: a freelancer or the seller published the app from their own developer account. The ID may be fine; it is just in the wrong place. Play's app transfer is requested from the original account and approved by yours, and carries over users, ratings and reviews. Apple's app transfer is started by the original Account Holder and keeps the bundle ID, ratings and reviews. Both need the other party's cooperation. Who owns the accounts and the keys is one of the questions to settle before you pay anyone, and it is one of the line items that separate a cheap quote from a complete one in our breakdown of app reskinning cost for a template you bought.

Leftover com.example or the original author's ID

com.example is the ID flutter create generates, and it survives in more templates than you would expect. Play Console refuses it. The error is widely reported as "com.example is restricted", though we could not find that wording in Google's own help pages. Some authors swap in their own ID instead, which is worse: if they have published under it, Play will not accept it from you, and if they have not, you are about to make their ID permanent in your app.

The applicationId is rarely the only copy. Templates hide the old ID in Kotlin folder paths, a manifest package attribute, deep-link hosts, method channel names, ProGuard rules, Firebase config files and the iOS test target. Search the whole project for the old string before you build anything you intend to upload.

You lost the keystore, or the passwords

First work out which key you lost. Android apps on Play have two. The upload key signs the bundle you send to Google. The app signing key signs what users download, and with Play App Signing, Google holds it.

Since August 2021, new apps must publish as an Android App Bundle, and Google's help page says apps uploading bundles are enrolled in Play App Signing by default. So if your app went live recently as an .aab, the key you lost is almost certainly the upload key, and Google says plainly that you are not locked out of your app. The recovery is an upload key reset:

1. Create a new upload keystore, exactly as in creating your upload keystore and first signed release.
2. Export its certificate to a .pem file with keytool.
3. In Play Console, open the app's Play App Signing page, choose Request upload key reset, give a reason and upload the .pem file.

You need admin permission to configure Play App Signing. Google does not say how long a reset takes and forum reports vary, so do not promise anyone a release date until it is approved. The page also moves between menus; on 26 October 2026 Google's help puts it under Protected with Play.

The other case is worse. If you managed the app signing key yourself, which was possible for apps first published as APKs, Google's page is direct: that key cannot be reset if you lose it. The app can no longer be updated, and you are back to a new listing under a new ID. Lost passwords count as a lost key, because there is no supported way to recover a keystore password.

Add it up. A rename across Gradle, Kotlin folders and Xcode, a keystore that has to outlive your laptop, and then every Google service re-registered against the new ID and keys, as the next section shows. For a first-timer that is several evenings at best, and the one mistake that reaches the store cannot be undone. If you would rather not spend that week, we do this as part of reskinning: package name and bundle ID, an upload keystore created and handed to you with its passwords, Android and iOS signing, Firebase and API keys re-registered, and store-ready builds, from $150 on the Pro tier.

Firebase, Google Sign-In or Maps broke after the ID change

This is the most confusing failure, because the app builds, installs and runs. Then sign-in fails, the map is a grey grid, or notifications stop. Google services identify an Android app by its package name and the SHA fingerprint of the certificate that signed it. Change either and the registration no longer matches.

Firebase

A Firebase Android app's package name cannot be changed after registration, and neither can a Firebase Apple app's bundle ID. Register new Android and iOS apps under the new IDs, then run flutterfire configure again. A stale google-services.json gives a loud "No matching client found" build error. That is the easy case.

The fingerprints you actually need

The quiet failures come from fingerprints. Most people register one SHA-1, the debug key on their own machine, and stop. A store app has three keys:

Fingerprint	Signs	Where to get it
Debug key	Builds you run from your IDE	./gradlew signingReport
Upload key	Release builds you install yourself	keytool -list -v on your upload keystore
App signing key	What Play users download	Play Console, Play App Signing page

Google's client authentication guide notes that under Play App Signing the upload certificate differs from the app signing certificate. Register only your debug SHA-1 and sign-in works on your phone and fails for everyone who installed from Play.

# Upload key: prints SHA-1 and SHA-256
keytool -list -v -keystore /absolute/path/to/upload-keystore.jks -alias upload

# Debug and release variants Gradle knows about
cd android && ./gradlew signingReport

Add them in Firebase under Project settings, in the SHA certificate fingerprints field of the new Android app. Some features want SHA-256: App Check's Play Integrity provider asks for it, and phone authentication uses it for Play Integrity too. Add both hashes for each key and you will not have to come back. An upload key reset changes the upload fingerprint, so register the new one afterwards.

Google Sign-In and Maps

Google Sign-In on Android uses an OAuth client created with the package name and SHA-1. When those do not match the installed app, you get ApiException: 10, which Google's reference lists as DEVELOPER_ERROR: the app is misconfigured. It is not a bug in your Dart code, so do not go looking for one. On iOS the OAuth client is tied to the bundle ID, and the reversed client ID has to be in Info.plist as a URL scheme.

Maps keys fail the same way. Google's API security guidance restricts Android keys by package name plus SHA-1 and iOS keys by bundle ID, so a key restricted to the old ID rejects the renamed app.

iOS bundle ID, provisioning profile and certificate mismatches

iOS signing has three pieces that must agree. The App ID in your Apple Developer account must match the bundle ID in Xcode. The provisioning profile ties that App ID to a certificate; an App Store profile contains a single distribution certificate. And the certificate must be usable on the Mac doing the build.

Change the bundle ID and the old profile no longer applies. With automatic signing on and your team chosen under Signing & Capabilities, Xcode creates what it needs once the new App ID exists. Most errors at this point have one of three causes: the App ID was never registered, the wrong team is selected (often the author's or a freelancer's), or a literal bundle ID is hard-coded somewhere Xcode does not update, such as Info.plist or the RunnerTests target.

Certificates cause a different panic. If your distribution certificate expired or was revoked, Apple says apps already on the App Store are not affected while your membership is valid. You cannot upload new builds signed with it, so create a new certificate and carry on. Unlike a self-managed Android key, nothing here locks you out of your own app.

Change the Flutter package name and app signing in the right order

If nothing is live yet, you are in the cheap part of this. Five checks catch most of the mistakes above:

• The ID is final. Reverse domain, a name you own, no com.example, no author ID.
• The accounts are yours. Play Console and the Apple Developer Program, in your name or your company's.
• The keystore is backed up, with both passwords and the alias, somewhere you will still have in three years.
• Every Google service knows the new ID, with debug and upload fingerprints now and the app signing fingerprint as soon as Play shows it.
• A release build works on a real phone, including sign-in, maps and notifications.

If you are already past one of these and stuck, send us the template, the ID you want to keep and what is failing, and we will tell you which of the options above you actually have: send your reskin brief for a fixed quote. If nothing is live yet and you would rather do it yourself, the Help Center walks through renaming a Flutter app's package and bundle ID one file at a time.