How to Change App Name in React Native A Complete Guide for 2026

Changing your app's name in a React Native project isn't always straightforward. The path you take really depends on how your project is set up. If you're in an Expo-managed project, you're in luck—it's mostly a quick edit in your app.json file. But for bare workflow projects, you'll need to roll up your sleeves and dive into native files like strings.xml for Android and Info.plist for iOS.

Why and When to Change Your App Name

Your app's name is its first impression—a digital handshake with every potential user. A name change is a big decision, usually sparked by a real business need, not just a whim. Understanding the "why" behind the change is just as crucial as knowing the "how," because it sets you up for a smooth transition.

I've seen teams decide to rename for a few common reasons:

• Strategic Pivot: The app has evolved. The original name just doesn't fit the new features or direction anymore.
• Rebranding Initiative: The entire company is getting a new look, and the app needs to fall in line with the new brand identity.
• Trademark Conflicts: A legal headache has popped up. You've discovered your name is already trademarked and need to switch to avoid trouble.
• Improved Marketability: The first name was a bit of a dud. Maybe it's hard to spell, confusing, or just doesn't click with your target audience.

Display Name vs Identifier

Before you even think about opening a file, you have to understand the two different "names" your app has. Getting these mixed up is one of the most common ways developers end up with broken builds and a lot of frustration.

The Display Name is what everyone sees. It’s the name on your user's home screen, in the App Store, and on Google Play. Think of it as your public-facing, marketing-friendly title. This one is pretty easy to change.

Then there's the Package Identifier (on Android) and the Bundle Identifier (on iOS). These are your app's unique, unchangeable IDs—like a social security number for your code. Once you publish your app, you should never change these. If you do, the app stores will treat your update as a brand-new app, severing the link to your existing users and reviews.

Changing an app name might feel like a minor task, but I've seen developers lose 4-6 hours chasing down build errors just because of confusing docs and platform-specific quirks. React Native already gives teams a huge advantage, often cutting development costs by 30-35% compared to building two separate native apps. Mastering a fundamental process like this helps protect those gains.

In the Expo ecosystem, this process is much cleaner. Your single source of truth is the app.json or app.config.js file—update the name and slug fields there, and you're mostly done. With React Native now used by over 14.51% of the developer market, knowing how to handle these core tasks efficiently is more important than ever. If you want to dig deeper, you can find out more about what a full application name change entails.

Display Name vs Package and Bundle ID

To make it crystal clear, here’s a quick table breaking down the difference between these two critical pieces of information.

Key Takeaway: You can change the user-facing display name whenever you need to for branding or marketing. But the underlying package and bundle identifiers are set in stone once your app is live on the stores. Choose them carefully from day one.

Renaming Your App in an Expo Managed Project

If you’re working within the Expo managed workflow, you’re in luck. Renaming your app is remarkably straightforward. You won't have to dig through native project files like you would in a bare workflow. Instead, everything is handled in one central place: your app.json or app.config.js file.

This single configuration file is the source of truth for your app's metadata, which makes updates incredibly clean and consistent across both iOS and Android.

Understanding name and slug in Your Config

When you open your app.json, two properties are key for a rename: name and slug.

The name property is exactly what you'd expect—it's the display name that users will see under your app icon on their home screen. This is your app's public-facing identity.

The slug, on the other hand, is a URL-friendly identifier used internally by Expo's services. It's the unique string that appears in your project's URL (like expo.dev/@your-username/your-app-slug). A name can have spaces and special characters, but a slug can't.

Let's look at a real-world example. Here’s what your app.json might look like before and after changing the name.

Before:
{
"expo": {
"name": "My Old App",
"slug": "my-old-app"
}
}

After:
{
"expo": {
"name": "My Awesome New App",
"slug": "my-awesome-new-app"
}
}
The change is dead simple. You just update the string values. While the name and slug don't have to match, keeping them closely related is a good practice for brand consistency.

Applying Your Changes and Rebuilding

Just editing the config file isn't the final step. Expo uses this file to generate the native ios and android directories, so you need to tell it to apply your changes. If you skip this, your builds will stubbornly hang on to the old name.

To sync everything up, you need to regenerate your native project files. The best way to do this is by running:

npx expo prebuild --clean

This command completely deletes the old ios and android directories and rebuilds them from scratch using your updated app.json. This ensures files like Info.plist (iOS) and strings.xml (Android) get populated with the new name.

A Quick Tip from Experience: Always use the --clean flag after a rename. I've seen developers lose hours trying to figure out why an old name is still showing up, only to find a cached native directory was the culprit. This one flag forces a clean slate and saves you a ton of frustration.

Once the prebuild is done, you can get back to your regular development flow:

• For local testing: Just restart your development server with npx expo start. The new name should appear in the Expo Go app or your simulators.
• For a production build: Kick off a new standalone build with eas build for the App Store and Google Play.

Following this process makes sure your new app name is correctly applied everywhere. If you want to dive deeper into what the Expo ecosystem can do for you, our React Native Expo tutorial is a great place to level up your skills. Renaming an app is just one of the many complex tasks Expo makes easy.

Tackling a Manual Rename in Bare React Native Projects

Once you eject from Expo or start with a bare React Native project, you're in the driver's seat. This level of control is liberating, but it also means you're responsible for tasks that Expo once handled automatically—like renaming your app. Unlike the simple app.json tweak in a managed workflow, renaming a bare project requires you to roll up your sleeves and dive into the native iOS and Android files.

It’s a multi-step process that demands attention to detail, but mastering it is a rite of passage for any serious React Native developer. Let's break down how to get it done on both platforms.

This flowchart can help you visualize whether you should stick to the Expo method or prepare for the manual work of a bare workflow.

As you can see, the path forks early. If you're in an Expo-managed project, your work is contained in app.json. If not, you're heading straight into the native code.

How to Change the App Name on Android

On Android, there’s a key distinction: the display name (what users see) is stored separately from the applicationId (the app’s unique ID on the Google Play Store). You'll need to update both.

First, let's change what appears on the user's home screen. This is handled in your string resources.

• Navigate to android/app/src/main/res/values/strings.xml.
• Find the string named app_name.
• Update the text inside the <string> tags to your new app name.

That one change updates the name across the system UI. But you're not done yet.

Pro Tip: Never hardcode your app's name directly in AndroidManifest.xml. By referencing the strings.xml resource (@string/app_name), you keep your configuration clean, making future updates or translations a breeze.

Next up is the package name, or applicationId. This is your app's permanent, unique address in the Google Play ecosystem and should ideally be set once before you publish. If you absolutely must change it on an unreleased app, you'll find it in your Gradle file.

Open android/app/build.gradle and look for the defaultConfig block.

android {
// … other configurations
defaultConfig {
applicationId "com.yourcompany.newappname"
// … other properties
}
}
Change the applicationId here. Be warned: this is a significant change that touches your entire Android project structure, so proceed with caution.

How to Change the App Name on iOS

The iOS process feels a bit different. While you can edit the files by hand, I've found that using Xcode is a more reliable and visual way to handle it. You'll be focusing on the Bundle display name and the project target name.

Your first stop is Info.plist, which acts like a combination of Android’s manifest and string resources.

• Open your project’s .xcworkspace file (inside the ios directory) in Xcode.
• In the Project Navigator, click the main project folder, then select your app's primary target.
• Go to the "Info" tab.
• Look for the Bundle display name (CFBundleDisplayName) key and change its value.

If the key isn’t there, just click the + icon to add a new row, select "Bundle display name" from the list, and enter your new name. This is what a user will see on their iPhone's home screen.

For the sake of consistency and to avoid future headaches, it’s also good practice to rename the project's target. It's not strictly necessary for the display name, but it keeps things clean.

• In Xcode's Project Navigator, single-click your project target.
• Pause for a second, then click it again to make the name editable.
• Type in the new name. Xcode will offer to automatically update all related project entries—definitely say yes to this.

A Faster Way: The react-native-rename Tool

If hunting through config files sounds like a recipe for a typo-induced disaster, there's a popular CLI tool that can do the heavy lifting for you. The react-native-rename package is a fantastic utility that automates most of these manual steps.

Think of it as the perfect middle ground—faster than doing it by hand but more transparent than the abstraction of Expo. It's especially handy when you need to change both the display name and the bundle/package identifiers at the same time.

You can run it directly with npx, so there's no need for a global install.

npx react-native-rename "Your New App Name"

To get more specific and change the bundle identifier, you can add the -b flag:

npx react-native-rename "New Name" -b com.yourcompany.newappname

This command intelligently searches for and replaces the old names in Info.plist, build.gradle, strings.xml, and other relevant files. It dramatically cuts down on the risk of human error.

While it’s a huge time-saver, it’s not infallible. I always recommend reviewing the changes with a quick git diff before committing them. Custom project setups can sometimes throw it off. After running the tool, always clean your builds and reinstall your dependencies (npm install, then cd ios && pod install) to make sure everything is properly synced.

Updating Your App on the App Store and Google Play

You’ve done the technical legwork to rename your app in the codebase, but the job isn't done. The most important part is making sure that new name shows up correctly on the Apple App Store and Google Play. This is where your code meets your customer, and consistency is everything for a clean rebrand.

Updating your listing on App Store Connect and the Google Play Console isn't just about finding the right text box. Each platform has its own rules, character limits, and review quirks you need to navigate.

Prepping Your Google Play Store Listing

With Android apps, your main hub is the Google Play Console. The process is usually faster than Apple's, but that speed doesn't give you a license to be sloppy.

After you've built and signed your new APK or AAB file—the one containing your updated display name—you need to sync that change with the store listing itself.

1. Log in to your Google Play Console and select your app.
2. In the left-hand menu, head to the Store settings page, which you'll find under the "Grow" section.
3. The field you're looking for is App name. This is where you'll type in the new name that users will see.

Google gives you 30 characters to work with. That's not a lot of room, so your name has to be punchy and clear. Once you hit save, the changes often appear live within a few hours, sometimes even quicker, as long as your update doesn't flag a manual review.

Navigating Apple's App Store Connect

Apple's process is a bit more rigid because a name change is tied directly to a new app version. You can't just change the name on a whim; it has to be bundled with an update.

Here’s how you’ll handle it in App Store Connect:

• First, select your app and kick off a new version (e.g., from 1.2.0 to 1.2.1).
• In the "App Information" section for this new version, you’ll see the Name field.
• Update this field with your new name, sticking to Apple's 30-character limit.

Your app's name is your first and most powerful marketing tool. Believe it or not, research suggests it can sway up to 74% of hybrid app downloads on the App Store. A simple mismatch between the display name in your build and what’s shown on the store can create serious user confusion, sometimes causing bounce rates to spike by 15-20%. For a deeper dive, these insights on React Native migrations are worth a read.

Once you’ve submitted your new build and updated the name, you're in a holding pattern waiting for Apple's review. This can take anywhere from a day to a week, sometimes longer. Make sure you factor this delay into your launch or marketing schedule.

Best Practices for a Seamless Store Update

Making sure your in-app display name and your store listing are identical isn't just good practice—it's a must for passing review and giving users a good experience. Inconsistent naming looks sketchy to both Apple and Google and can come across as deceptive.

Before you submit anything, run through this final checklist:

• Double-check character limits: Is your new name under the 30-character cap for both platforms?
• Ensure consistency: Does the name in your strings.xml or Info.plist exactly match what you're entering in the console?
• Update marketing assets: Don’t forget about your screenshots, promo videos, and app description. A new name paired with old visuals sends mixed signals.

If you're just getting started on your developer journey, our guide on how to build an Android app offers great foundational knowledge that complements these store management tasks. By treating the store update with the same care as your code, you'll ensure your app's new identity rolls out without a hitch.

Syncing Your New Name with Third-Party Services

Getting your new name live on the app stores and in your code feels like crossing the finish line, but there's a critical lap left. Your app's identity doesn't just live in its own files; it's deeply tied into a web of third-party services that run everything from your analytics to push notifications.

Forgetting to update these services is a common and surprisingly costly mistake. It can silently break key integrations, leaving you with gaping holes in your data, undelivered notifications, and zero visibility into crashes. This is your guide to making sure every piece of your app’s ecosystem knows about its new name.

Your Firebase Configuration Files

For most React Native developers, Firebase is the central hub for analytics, authentication, and push notifications. The moment you change your applicationId on Android or Bundle Identifier on iOS, your existing Firebase configuration files are toast. They're the handshake between your app and Google's backend, and a name change breaks that connection.

Here’s how to fix it:

1. Head over to your Firebase project settings in the console.
2. You'll need to run through the "Add app" flow again, this time using your shiny new bundle and package identifiers. It feels a bit strange, but this is how Firebase generates fresh config files for your renamed app.
3. Download the new files: you’ll get a google-services.json for Android and a GoogleService-Info.plist for iOS.
4. Drop these new files into your project, overwriting the old ones. The Android file goes in android/app/, and the iOS one goes into ios/your-project/.

Once you've replaced the files, a clean build is non-negotiable. If you skip this, your app will stubbornly use the old, cached configuration, and Firebase will remain broken. You can get a much deeper look into setting up Firebase analytics in your React Native app in our dedicated guide.

Updating Your Wider Service Ecosystem

Firebase is just one piece of the puzzle. Your app probably relies on several other platforms, and each one needs to know about your app's new identity, especially if the package or bundle ID changed. An out-of-sync service is a broken service.

A critical mistake is underestimating the ripple effects of a name change. I've seen teams celebrate a successful store update, only to realize days later that their crash reporting tool stopped receiving data, leaving them blind to production bugs. A thorough audit is not optional; it's essential.

Grab a notepad or open a doc and create a checklist. Go through every single service your app talks to. Here are the usual suspects to get you started:

• Analytics Platforms: Services like Mixpanel, Amplitude, or Segment often key off your bundle or package ID. Dig into their project settings to find where to update this.
• Push Notification Providers: If you’re using something like OneSignal, you absolutely have to update your app’s credentials there. If you don't, push notifications will just stop working.
• Crash and Error Reporting: Tools such as Sentry or Bugsnag need the correct identifiers to receive and make sense of crash reports. Without it, you’re flying blind.
• Deep Linking and Attribution: Services like Branch.io depend on your app's unique identifiers to route users from a link directly into your app. A mismatch here will completely break your deep links.

Knowing how to change an app name properly is a huge advantage for any developer. It's one of those tasks where developers can easily burn 4-6 hours on a botched attempt. In contrast, a well-configured Expo project can get the job done in under 30 minutes. That kind of efficiency matters, especially when React Native already saves 30-35% in development costs compared to going fully native.

Common Pitfalls and Side Effects

Even with the best plan, a few tricky issues can pop up after a rename. Knowing what they are ahead of time will save you hours of frustrated debugging.

One of the most common headaches is cache-related bugs. Old build artifacts can hide on your machine or CI/CD server, causing the old app name to haunt you. The fix? Always run a full clean, delete your node_modules folder, and then reinstall with npm install and pod install to make sure everything is truly fresh.

Another classic problem is broken deep links. If your deep link scheme was tied to the old app name or bundle ID, every one of those links will fail. Make sure you test all your core user flows that rely on deep linking. This simple check turns a potential crisis into a manageable task and helps solidify your app's new brand identity across every single touchpoint.

Common Questions and Quick Answers

When you're knee-deep in a React Native project and need to change the app's name, a bunch of questions always pop up. Getting straight answers is the best way to avoid those frustrating pitfalls that can completely derail your progress. Let's tackle some of the most common queries developers run into.

Can I Change the Package Name or Bundle ID Later?

This is a big one, and the short answer is a hard no. Once your app is live on the stores, you absolutely must treat the Android package name (applicationId) and the iOS Bundle Identifier as permanent. They aren't just labels; they're the unique fingerprints the Google Play Store and Apple App Store use to track everything about your application.

Think of it like a car's VIN number. If you change it, the DMV considers it a completely different vehicle. For your app, changing this unique ID means:

• You'll lose your entire existing user base.
• All of your hard-earned ratings and reviews will vanish.
• Your current users won't get any updates for the old version.

You really have to nail down these identifiers at the very start of your project. They're foundational to your app's entire lifecycle.

What's the Difference Between Name and Slug in app.json?

If you're working in the Expo ecosystem, your app.json or app.config.js file is mission control. It has two fields that often trip people up: name and slug.

The name property is pretty straightforward—it's the public display name. This is what users see on their home screen under your app icon.

The slug, on the other hand, is a clean, URL-friendly string. It's used to create your app's web address on the Expo platform (like expo.dev/@username/your-app-slug). It can't have spaces or most special characters. While you can set them to be the same, you don't have to. For instance, your name might be "My Awesome App," but your slug would simply be "my-awesome-app."

Do I Need to Tell My Users Before Changing the App's Name?

Yes, you absolutely do. Imagine opening your phone to find an app you use daily has a completely different name and icon. It's confusing, and your first thought might be that you've downloaded some kind of malware. This erodes the trust you've worked so hard to build.

Clear communication isn't just a nice-to-have; it's essential for a successful rebrand. A surprise name change can feel like a bait-and-switch, leading to a flood of bad reviews and uninstalls.

To make this transition smooth and keep your users in the loop, announce the change well ahead of time. Hit them from a few different angles to make sure the message lands:

• In-app notifications: Pop up a message to active users right inside the app.
• Email newsletters: Reach everyone, even people who haven't opened the app in a while.
• App store release notes: Use the "What's New" section to explain the change when you ship the update.

Being transparent brings your users along for the ride. It shows you respect them, which helps reinforce their loyalty instead of pushing them away.

At React Native Coders, we publish tutorials and deep dives to help you master the entire React Native ecosystem. Whether you're just starting out or optimizing for performance, you can find everything you need to build and ship amazing apps faster.