Change the Bundle Identifier and Application ID

Change the iOS bundle identifier and Android application id, and re-register everything the change silently breaks.

This guide covers changing a React Native app's iOS bundle identifier and Android application ID, and everything downstream that breaks silently when you do.

Quick Answer

Set a unique, reverse-DNS identifier (e.g. com.yourcompany.yourapp) in app.json under ios.bundleIdentifier and android.package for Expo, or in the Xcode target and android/app/build.gradle for bare React Native; then re-register that identifier everywhere else it's referenced, since it's the primary key for most third-party integrations.

1. This Identifier Is Permanent Once Published

Once an app is live on the App Store or Play Store under a given bundle identifier / application ID, you cannot change it for that store listing; changing it means shipping what the stores treat as a brand new app, with reviews, install counts, and history starting from zero. Get this right before your first release, not after.

2. Where to Set It

Expo, in app.json:

{
  "expo": {
    "ios": { "bundleIdentifier": "com.yourcompany.yourapp" },
    "android": { "package": "com.yourcompany.yourapp" }
  }
}

Bare React Native: the iOS value lives in the Xcode target's Signing & Capabilities (Bundle Identifier field); the Android value is applicationId in android/app/build.gradle.

3. Everything That Breaks When You Change It

This identifier is how most third-party services recognize your app. Changing it invalidates or disconnects, silently, until you redo each of these:

• Firebase: your GoogleService-Info.plist / google-services.json were issued for the old identifier; re-register the app in Firebase and download new config files (see Link Firebase Account to Your App).
• Google Sign-In: the OAuth client's registered package name/bundle ID no longer matches; update it in Google Cloud Console (see Add Google Sign-In).
• Apple provisioning: your existing provisioning profile was issued for the old bundle ID; Xcode will need to generate a new one.
• Push credentials: APNs keys and FCM/Expo push registrations are tied to the identifier and app signing; they need to be reconfigured.

Common Issues

Firebase "silently" stops authenticating or writing data after the change the config files still reference the old bundle ID/package; regenerate and replace them.

Xcode build fails with a provisioning profile error after the change expected; let Xcode automatically manage signing, or manually generate a new profile for the new bundle ID.

Google Sign-In starts failing with DEVELOPER_ERROR the OAuth client in Google Cloud still points at the old package name/fingerprint pairing.

Realized after the first store release that the identifier needs to change there's no clean fix; you'd be publishing what the stores treat as a new app. Double-check this value carefully before your first submission.

Verification Checklist

• the identifier is set consistently in both the iOS and Android configuration;
• it follows reverse-DNS format and is unique to you;
• Firebase config files are regenerated for the new identifier, if used;
• Google Sign-In (and any other OAuth provider) is re-registered with the new identifier;
• a clean rebuild succeeds on both platforms with valid signing.

Next Steps

• Link Firebase Account to Your App
• Add Google Sign-In