DEV Community: Asta Silva

How to Fix Expo Doctor Errors in Expo

Asta Silva — Mon, 07 Sep 2026 11:14:04 +0000

If you work with Expo long enough, you will probably run into expo-doctor.

You run:

npx expo-doctor

and instead of everything being green, you get something like:

✖ Check Expo config
✖ Check dependencies
✖ Check package versions

Sometimes there is one problem.

Sometimes there are several.

And sometimes the output looks much worse than the actual problem.

The good thing is that expo-doctor is usually pretty clear about what it does not like. The tricky part is knowing what the warnings actually mean and which ones you need to fix.

Here is how I usually work through Expo Doctor errors without immediately changing half of the project.

First, run Expo Doctor by itself

Start with:

npx expo-doctor

Let it finish and read the full output.

Do not immediately start changing dependencies just because you see a red ✖.

Expo Doctor runs several checks, and a failure in one check does not necessarily mean your entire project is broken.

For example, you might see:

✖ Check that packages match versions required by installed Expo SDK

That is very different from:

✖ Check for common project configuration problems

The first one points toward dependency versions.

The second could require looking at your Expo configuration.

So the first step is simply figuring out which check actually failed.

Check your Expo SDK version

A lot of Expo Doctor problems come down to package versions not matching the Expo SDK you are using.

You can check your Expo version in package.json:

{
  "dependencies": {
    "expo": "~54.0.0"
  }
}

The exact version will depend on your project.

You can also run:

npx expo --version

and:

npx expo config --type public

The important thing is to know which Expo SDK your project is actually using before changing dependencies.

This matters because Expo packages are not completely independent of the SDK.

You cannot always just install the newest version of every package and expect everything to work together.

Fix packages that are on the wrong version

One of the most common Expo Doctor messages is related to package versions.

For example:

✖ Check that packages match versions required by installed Expo SDK

Expo may tell you that some packages are expected to be on different versions.

If that happens, do not manually guess which version to install.

For Expo-managed projects, use:

npx expo install

Expo can use your current SDK to install compatible package versions.

You can also check the project with:

npx expo install --check

If it reports packages that are out of date, you can usually let Expo correct them with:

npx expo install --fix

This is generally safer than doing something like:

npm install package-name@latest

because the latest package version is not necessarily the version your current Expo SDK expects.

Do not blindly update everything

This is worth mentioning because it is an easy mistake to make.

Suppose Expo Doctor tells you that three packages have version mismatches.

You might think:

Fine, I'll just update everything.

Then you run something like:

npm update

and suddenly you have five new errors.

You have now changed many things at once, which makes it harder to figure out what actually caused the problem.

If Expo is telling you that a package should be on a specific version, start with that package.

For example:

npx expo install react-native-screens

rather than manually searching for the newest version and installing it.

Make one meaningful change at a time when possible.

It makes debugging much easier.

Check `package.json` for old dependencies

Another common situation is an old dependency that you no longer use.

Over time, a project can collect packages from old features, experiments, tutorials, or libraries you tried and later removed.

Your package.json might contain:

{
  "dependencies": {
    "some-old-package": "^1.2.3"
  }
}

even though nothing in your application imports it anymore.

If Expo Doctor complains about that package, first check whether you still need it.

Search your project for:

some-old-package

If there are no imports or references and you know you do not need it anymore, removing the dependency may be the correct fix.

For npm:

npm uninstall some-old-package

For Yarn:

yarn remove some-old-package

Then run Expo Doctor again.

Check for packages that are not compatible with your project

Sometimes the problem is not simply that a package is old.

A package may require native code or a setup that does not fit the way your Expo project is configured.

This becomes especially important when adding React Native libraries that were designed with bare React Native projects in mind.

You may install a package successfully with npm, but that does not automatically mean your Expo project is configured to use it correctly.

If Expo Doctor starts complaining immediately after adding a new library, that timing is useful information.

Try to remember:

What changed right before the error appeared?

If you just installed a package and Expo Doctor started failing, investigate that package first.

Check your Expo configuration

Expo Doctor can also complain about your project configuration.

Depending on your setup, this information may live in:

app.json

or:

app.config.js

or:

app.config.ts

For example, your configuration might contain something like:

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

If you recently changed your configuration, added a plugin, changed an Android or iOS setting, or installed a package that requires an Expo config plugin, check those changes carefully.

A configuration problem can sometimes look like a dependency problem because several parts of the Expo toolchain depend on the same project configuration.

Check Expo config plugins

Config plugins are another area that can cause confusion.

If you have something like:

{
  "expo": {
    "plugins": [
      "some-package"
    ]
  }
}

make sure that package is actually installed and that the plugin is valid for your current setup.

A common situation is:

You install a package.
You add its plugin to the Expo configuration.
Later, you remove the package.
The plugin entry stays behind.

Now Expo may still try to process something that no longer exists.

If you recently removed a native package, check app.json or your app config for leftover plugin entries.

Check for duplicate dependencies

Another useful thing to investigate is duplicate versions of the same package.

For example, your project might end up with different parts of the dependency tree using different versions of a React Native package.

You can inspect the dependency tree with npm:

npm ls

Or check a specific package:

npm ls react-native-screens

If you see multiple versions where you expected one, that can be a clue.

This does not automatically mean that multiple versions are wrong. Some projects legitimately have them.

The important part is to understand why they are there before trying to force everything onto one version.

Check your React Native version too

Expo SDK and React Native versions are closely related.

If you manually changed your React Native version, or upgraded one without properly upgrading the Expo SDK around it, Expo Doctor may start reporting compatibility problems.

For example, if your package.json contains:

{
  "dependencies": {
    "expo": "~54.0.0",
    "react-native": "..."
  }
}

make sure those versions belong together.

If you are upgrading Expo, follow the Expo upgrade process instead of manually changing a bunch of package versions and hoping they line up afterward.

A partially upgraded project is often harder to fix than a project that was left alone.

Run `expo-doctor` again after fixing something

This sounds obvious, but it is an important part of the process.

After making a change, run:

npx expo-doctor

again.

You want to know whether the change actually fixed the problem.

For example:

Before:
✖ Check package versions

After:
✔ Check package versions

Now you know that particular problem is gone.

If another check is still failing, you can work on that one separately.

This is much easier than making ten changes and running Expo Doctor once at the end.

What if Expo Doctor still fails?

If you have corrected the obvious dependency and configuration problems but Expo Doctor is still reporting an error, look at the exact check that is failing.

For example:

✖ Check for common project configuration problems

is not enough information by itself.

Read the lines underneath it.

Expo Doctor normally provides additional information about what it found.

That information is much more useful than the ✖ itself.

Copy the complete section of the output, not just the first line.

Clear the cache if the project still behaves strangely

Clearing caches is not usually the first fix for an Expo Doctor warning.

Expo Doctor is checking your project configuration and dependencies, so a cache reset will not magically fix an incorrect package version.

However, if you have already fixed the reported problem and the project is still behaving as if the old state exists, clearing the Metro cache can help.

For Expo:

npx expo start -c

This is particularly useful after changing dependencies, imports, or other files that Metro may have cached.

Just keep in mind that clearing Metro's cache and fixing Expo Doctor are two different things.

When reinstalling `node_modules` makes sense

If your package configuration looks correct but your installation itself seems broken, reinstalling dependencies can be worth trying.

Delete:

node_modules

Then reinstall:

npm install

Afterward:

npx expo-doctor

And if necessary:

npx expo start -c

I would not delete your lockfile automatically.

Your package-lock.json or yarn.lock records the dependency versions that your project is using. Removing it can cause a completely new dependency tree to be installed, which may introduce more changes than you wanted.

If you specifically need to regenerate the lockfile, that is a different situation.

Be careful when upgrading an Expo project

If the reason for your Expo Doctor errors is that you are trying to move to a newer Expo SDK, do not treat it like a normal dependency update.

An Expo SDK upgrade can involve:

Expo packages
React Native
React
native dependencies
config plugins
Android configuration
iOS configuration
other packages tied to the SDK

If you upgrade only one or two pieces, you can end up with a project where everything is technically installed but the versions do not belong together.

If your goal is specifically to upgrade Expo, follow the upgrade process for the target SDK rather than trying to fix every warning individually.

A simple way to approach Expo Doctor

When I get an Expo Doctor error, I usually work through it in this order:

1. Run Expo Doctor

npx expo-doctor

2. Find the failed check

Do not worry about every line yet. Find the actual ✖ checks.

3. Read the details underneath

That is usually where the useful information is.

4. Check what changed recently

Did you:

install a package?
update Expo?
update React Native?
remove a package?
change app.json?
add a config plugin?
switch branches?

Recent changes are often the best clue.

5. Fix the smallest thing first

If a package version is wrong, fix that package.

If a plugin is left behind, remove it.

If a dependency is no longer needed, uninstall it.

6. Run Expo Doctor again

npx expo-doctor

Then see what remains.

This gives you a much cleaner debugging loop.

One example

Imagine you run:

npx expo-doctor

and get a dependency version warning.

You check package.json and notice that you manually installed a newer version of an Expo-related package a few days ago.

Instead of immediately reinstalling everything, you can try:

npx expo install

or, if Expo identifies the package as needing a correction:

npx expo install --fix

Then run:

npx expo-doctor

again.

If the check passes, you have your answer.

If it does not, you now have a smaller problem to investigate.

That is the part that makes debugging much easier: change something, test it, and use the new output to decide what to do next.

Final thoughts

Expo Doctor is there to help you find problems before they turn into much bigger issues.

The important thing is not to treat every warning as a reason to rebuild your entire project.

Start with the exact check that failed.

If it is a dependency problem, check the package versions.

If it is a configuration problem, check your Expo config.

If you recently installed or removed a package, investigate that change.

And if you are upgrading Expo, make sure you are upgrading the related dependencies together instead of manually mixing versions.

Most importantly, avoid making a dozen changes at once. When you do that, even if the error disappears, you have no idea which change actually fixed it.

If your Expo Doctor output is more complicated—especially when several checks fail at the same time—you can paste the full error into FixMyError and use it to break down what the output is actually telling you.

You can try it at https://www.fixmyerrorapp.com.

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

Asta Silva — Fri, 28 Aug 2026 13:33:58 +0000

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

If you have been working with React Native or Expo for a while, there is a good chance you have seen an error that looks something like this:

Unable to resolve module ./components/Header from App.js

None of these files exist:
  * components/Header(.native|.ios|.android|.js|.jsx|.ts|.tsx)
  * components/Header/index(.native|.ios|.android|.js|.jsx|.ts|.tsx)

Or maybe:

Unable to resolve module react-native-safe-area-context from App.js

Or the error is buried somewhere inside a much larger Metro bundler log, making it harder to see what is actually wrong.

The annoying part about this error is that "Unable to resolve module" does not always mean the same thing.

Sometimes the file path is wrong. Sometimes the package was never installed. Sometimes it is installed, but your dependencies are in a bad state. And sometimes everything looks correct until you notice that one letter in a filename has the wrong capitalization.

I've run into all of these before.

So instead of randomly deleting node_modules and hoping for the best, here is how I usually work through this error.

First, read the exact module Metro cannot find

This sounds obvious, but the first line of the error usually tells you exactly what Metro is looking for.

For example:

Unable to resolve module ./components/Header from App.js

Metro is trying to find:

./components/Header

relative to:

App.js

That immediately gives you something to check.

Ask yourself:

Does that file actually exist?
Is the path correct?
Is the filename spelled correctly?
Are you importing it from the correct folder?

For example, imagine your project looks like this:

my-app/
├── App.js
└── components/
    └── Header.js

Then this import should work:

import Header from "./components/Header";

But this will not:

import Header from "./component/Header";

One missing s is enough to break the build.

When the error points to a local file, I usually start here before doing anything else.

Check the file name and capitalization

This one can be surprisingly annoying, especially if your app worked on one machine but suddenly fails during a build or after pushing the project somewhere else.

Imagine your file is named:

header.js

But your import says:

import Header from "./components/Header";

Depending on the operating system and environment, this can cause problems because:

header.js

and:

Header.js

are not always treated as the same file.

The same thing can happen with folders:

Components/

vs:

components/

If Metro says it cannot find a local module and the path looks correct at first glance, check every part of the path carefully.

I have lost more time than I would like to admit because of a single capital letter.

Make sure the package is actually installed

Sometimes the missing module is not one of your own files.

For example:

Unable to resolve module react-native-safe-area-context

In that case, check whether the package exists in your project.

You can look inside package.json and see whether it is listed under dependencies.

For an Expo project, it is usually better to install Expo-compatible packages with:

npx expo install react-native-safe-area-context

For a regular React Native project, you would normally use:

npm install react-native-safe-area-context

or:

yarn add react-native-safe-area-context

The exact command depends on your project, but the important part is this:

Do not assume a package is installed just because you used it in your code.

It is also possible that you copied code from another project, tutorial, or GitHub repository without installing all of the required dependencies.

Check if the package name is correct

Another simple but common problem is importing the wrong package name.

For example, you might write something like:

import Something from "react-native-something";

but the actual package name could be slightly different.

Before reinstalling everything, check:

The package name in your import.
The package name in package.json.
The package name from the package documentation.

One small typo can produce the same "Unable to resolve module" error as a completely missing dependency.

Reset the Metro cache

If the file or package exists and the import looks correct, the next thing I would try is clearing Metro's cache.

For Expo:

npx expo start -c

For React Native, you can try:

npx react-native start --reset-cache

Metro caches information to make development faster, but occasionally the cache gets in the way after things change.

For example, you might have:

renamed a file,
moved a folder,
installed a new package,
changed an import,
switched branches in Git.

If the project is still behaving like the old version exists, clearing the cache is a quick thing to try.

I would not start by deleting half the project, though. Resetting the cache is much less destructive.

Check your `node_modules`

Sometimes the dependency is listed in package.json, but something went wrong during installation.

This can happen after:

switching branches,
changing package versions,
interrupting an installation,
moving the project to another computer,
or getting dependency conflicts.

A common approach is to reinstall your dependencies.

First, remove node_modules.

Then run:

npm install

Or, if you use Yarn:

yarn install

After that, start the project again and clear Metro's cache.

For Expo, that could look like:

npx expo start -c

Try to use the same package manager consistently. If your project uses package-lock.json, randomly switching between npm, Yarn, and other package managers can create confusing dependency problems.

Check whether you are importing from the correct location

This is especially easy to miss after moving files around.

Imagine you originally had:

src/
├── screens/
│   └── HomeScreen.js
└── components/
    └── Header.js

Inside HomeScreen.js, you might import:

import Header from "../components/Header";

Then later, you move HomeScreen.js somewhere else:

src/
├── app/
│   └── screens/
│       └── HomeScreen.js
└── components/
    └── Header.js

The old import path may no longer be correct.

You would need to update it accordingly:

import Header from "../../components/Header";

When you see an "Unable to resolve module" error after reorganizing your project, check whether the import path still matches the new folder structure.

Be careful with relative paths

Relative imports can become difficult to read when your project grows.

You might end up with something like:

import Something from "../../../../components/Something";

At that point, it becomes much easier to accidentally use one ../ too many or too few.

If the error points to a long relative path, carefully trace it from the file where the import is written.

For example:

import Header from "../../../components/Header";

Do not just count the dots and slashes quickly. Actually check the location of the current file and follow the path step by step.

It is boring, but it is often faster than trying random fixes.

Check whether the package is compatible with Expo

This is more important if you are using Expo.

You may find a React Native package online, install it successfully, and then run into problems because the version does not match your Expo SDK or the package needs native setup that your project does not currently support.

When possible, use:

npx expo install package-name

instead of blindly installing the latest version with npm.

Expo can choose a version that is compatible with your current SDK.

You can also run:

npx expo-doctor

to check your project for dependency and configuration issues.

If Metro suddenly cannot resolve something after installing or updating a package, compatibility is worth checking.

Watch out for renamed or removed files

Another situation that can cause this error is when your code still imports something that no longer exists.

For example, you rename:

OldButton.js

to:

CustomButton.js

but somewhere in the project, you still have:

import OldButton from "./OldButton";

The error might not happen immediately if that file is not loaded until you visit a specific screen.

This is why I would search the project for the old filename.

Your editor's global search is useful here. Search for:

OldButton

and see whether any old imports are still left behind.

Check `index` files

Sometimes the missing module is actually caused by an index.js or index.ts file.

For example:

components/
├── Button/
│   ├── Button.js
│   └── index.js

You might import it like this:

import Button from "./components/Button";

That usually depends on Metro being able to resolve the folder's index file correctly.

If index.js was deleted, renamed, or contains a broken export, your import setup may stop working.

Check whether the folder contains the file Metro expects.

For example:

export { default } from "./Button";

Or:

export { Button } from "./Button";

The correct setup depends on whether you are using default or named exports.

The important part is to check the whole import chain, not just the first file.

Default exports and named exports are a different problem, but still worth checking

This usually causes a different error, but it can easily appear around the same time.

For example, this is a default export:

export default Header;

And it is imported like this:

import Header from "./Header";

A named export looks like this:

export const Header = () => {
  return null;
};

And it should be imported like this:

import { Header } from "./Header";

If you have already fixed the module resolution error but the app still fails afterward, this is one of the next things I would check.

Sometimes you fix one problem and Metro finally gets far enough to show you the next one.

That is just part of debugging.

Monorepos can make module resolution more complicated

If you are using a monorepo, workspaces, shared packages, or code outside the main app folder, Metro module resolution can become more complicated.

Your project might look something like this:

my-project/
├── apps/
│   └── mobile/
└── packages/
    └── shared/

Then the React Native or Expo app might need to import code from:

packages/shared

In these cases, a normal relative import may not be enough. Metro may need additional configuration to watch or resolve files outside the main project directory.

If you only started seeing the error after introducing a workspace or shared package, I would focus on your Metro configuration instead of repeatedly reinstalling dependencies.

Monorepo issues usually need a more specific fix because the correct setup depends heavily on how the project is structured.

If you use Expo Router, check your imports and project structure

Expo Router adds another layer to how files are organized.

For example, your routes may live inside:

app/

and you may have layouts, route groups, and nested folders.

If you recently moved or renamed route files, double-check your imports and references.

Also make sure the required Expo Router packages are correctly installed for your current Expo setup.

When something goes wrong inside a routing setup, the error message may make it look like a general Metro problem when the real issue is simply an incorrect import somewhere inside a route or layout.

Again, start with the exact module Metro says it cannot find.

Do not immediately delete everything

When developers hit a module resolution error, a common reaction is to do all of this at once:

Delete node_modules
Delete package-lock.json
Clear Metro
Clear npm cache
Reinstall everything
Restart the computer

Sometimes that works.

But it can also make debugging harder because now you have changed five different things and do not know what actually fixed the problem.

I would usually check the error in this order:

Read the exact missing module.
Check whether the file or package exists.
Check the spelling and capitalization.
Check the import path.
Check whether the dependency is installed.
Clear the Metro cache.
Reinstall dependencies if necessary.
Check Expo or React Native version compatibility.
Investigate Metro configuration for more complex project setups.

This is usually much faster than throwing random commands at the project.

A quick example

Imagine you get this error:

Unable to resolve module ./components/ProfileCard from App.js

You check your project and see:

components/
└── Profilecard.js

The problem is the capitalization.

Your import says:

import ProfileCard from "./components/ProfileCard";

But the actual file is:

Profilecard.js

Rename the file so it matches:

ProfileCard.js

Then restart Metro if necessary:

npx expo start -c

That is a simple example, but it shows why reading the exact error matters.

The error is not always asking you to reinstall your entire project. Sometimes Metro is simply telling you that it cannot find something because the path does not exactly match what exists on disk.

Final thoughts

"Unable to resolve module" errors can look more serious than they really are.

Most of the time, the problem comes down to one of these things:

A wrong import path
A missing package
A typo in the package name
A filename capitalization problem
A stale Metro cache
Broken or missing dependencies
A file that was moved or renamed
A more complex Metro configuration issue

The biggest thing I have learned is to start with the exact module Metro says it cannot find.

Do not start by reinstalling the entire project.

Check what Metro is looking for, where it is looking from, and whether that file or package actually exists. In many cases, the answer is much simpler than the size of the error message makes it seem.

If your error is much messier than this—especially if the missing module is buried inside a large Expo, Metro, dependency, or build error—you can also paste the full error into FixMyError and get help breaking down what is actually causing it.

Sometimes the hard part is not finding a fix. It is figuring out which part of a long error log actually matters.

Try it here: https://www.fixmyerrorapp.com

How to Fix EAS Build Failed Errors in Expo

Asta Silva — Tue, 11 Aug 2026 11:45:09 +0000

There is a particular kind of Expo error that I think almost every developer eventually runs into.

You make a change to your project, run your usual build command:

eas build

and instead of getting a nice .apk or .aab at the end, you get:

Build failed

And that's it.

Well, not really.

If you open the build logs, you get several hundred lines of output containing Gradle tasks, Android dependencies, warnings, stack traces, environment information, and somewhere in the middle of all of that is the actual reason your build failed.

I've been there more times than I'd like to admit.

The frustrating part is that "EAS Build failed" isn't really an error by itself. EAS is just telling you that something went wrong during the build. The actual problem can be a completely different issue.

It might be an Android dependency conflict.

It might be a missing environment variable.

It might be an invalid app.json configuration.

It might be a native package that doesn't work with your current Expo SDK.

Or it might be something as simple as a credentials problem.

So instead of trying random fixes, let's go through how I approach these failures and how to find the actual cause.

First: Don't Focus on "EAS Build Failed"

When you see:

Build failed

it's tempting to search for that exact phrase.

The problem is that thousands of completely different problems can end with the same message.

EAS Build is responsible for building your application. It isn't necessarily responsible for the thing that broke.

For example, your log might eventually contain:

Execution failed for task ':app:mergeDexDebug'

That's an Android dependency/build problem.

Or:

Could not resolve all files for configuration

That's pointing toward dependency resolution.

Or you might see something related to:

Missing environment variable

That's an environment/configuration problem.

And if you see something related to signing credentials, you're dealing with an entirely different category of failure.

The first thing I do is therefore ignore the generic "Build failed" message and find the first meaningful error underneath it.

1. Open the Full EAS Build Logs

Start by looking at the failed build in the EAS dashboard.

You can also list recent builds from your terminal:

eas build:list

Find the failed build and open its logs.

Don't just look at the last few lines.

The last line might say:

Build failed

but that doesn't tell you much.

Instead, search through the logs for terms such as:

ERROR
FAILURE
Error:
Caused by:
Exception
Could not
Unable to

The useful error is often somewhere above the final failure message.

For example, imagine the bottom of your log looks like this:

> Task :app:mergeDexRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDexRelease'.

> com.android.builder.dexing.DexArchiveMergerException:
  Error while merging dex archives

BUILD FAILED

Build failed

The useful information isn't really:

Build failed

It's:

Execution failed for task ':app:mergeDexRelease'

and whatever caused the DEX merge to fail.

That distinction saves a lot of time.

2. Check Whether the Problem Is Actually Your Expo Configuration

One of the first things I check after an EAS build fails is the project's configuration.

Depending on your setup, this can include:

app.json
app.config.js
app.config.ts
eas.json

A small configuration mistake can prevent the native project from being built correctly.

For example, if you've recently changed:

{
  "android": {
    "package": "com.example.myapp"
  }
}

or added a plugin:

{
  "plugins": [
    "some-native-package"
  ]
}

and the build immediately started failing, that change is worth investigating.

The same applies to permissions, native configuration, app identifiers, and Expo config plugins.

If the failure started immediately after a configuration change, don't assume the EAS service itself is broken.

Look at what changed in your project first.

3. Check Your Expo SDK and Native Dependencies

This is one of the biggest sources of trouble I've encountered with Expo projects.

Expo SDK versions are tied to specific versions of React Native and a collection of native dependencies.

You can have a perfectly valid JavaScript project and still break the native build by installing a package that doesn't fit your current environment.

For example:

npm install some-package

looks harmless.

But if that package contains native Android or iOS code, it becomes part of your native build.

That's where things can get interesting.

Before randomly upgrading packages, check your project:

npx expo-doctor

This can identify common dependency and configuration problems.

If you're using Expo, I also recommend using Expo's package installation command when appropriate:

npx expo install package-name

rather than blindly installing a version with npm.

Expo can select a version that is compatible with your current SDK.

4. If the Error Mentions Gradle, Investigate the Android Build

Sometimes an EAS failure is actually an Android build failure hiding underneath Expo.

For example:

Execution failed for task ':app:mergeDexRelease'

or:

Could not resolve all files for configuration

or:

Duplicate class found

These are not really "Expo errors."

They're Android/Gradle dependency problems occurring during your Expo build.

This distinction matters because searching for:

EAS Build failed

will give you a huge number of unrelated results.

Searching for:

Execution failed for task mergeDexRelease React Native

is much more useful.

That's generally how I approach these logs: follow the most specific error rather than the generic EAS failure.

5. Check Your Environment Variables

Another surprisingly common cause of failed builds is an environment variable that exists locally but doesn't exist in EAS.

For example, your application might expect:

API_URL
SUPABASE_URL
SUPABASE_ANON_KEY

Your local development environment works because those variables exist in your .env file.

Then you create an EAS build and suddenly something breaks.

Why?

Because the remote build environment doesn't automatically have every variable from your local machine.

Check your EAS environment configuration:

eas env:list

Make sure the variables your application actually needs are available in the environment being used for the build.

This is especially important if the failure happens only on EAS while:

npx expo start

works perfectly locally.

6. Check Your EAS Build Profile

Your eas.json determines how your builds are configured.

A typical configuration might look something like:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

If the problem only happens with one profile, compare that profile with the one that works.

For example:

eas build --profile preview

might work while:

eas build --profile production

fails.

That immediately gives you another clue.

The problem may not be your entire project. It may be something specific to the build profile.

7. Don't Ignore Credentials Errors

If the log mentions things such as:

credentials
keystore
provisioning profile
certificate
signing

don't start changing Gradle dependencies.

You're probably dealing with app signing or build credentials instead.

For Android, EAS can manage your app signing credentials for you.

You can inspect the credentials with:

eas credentials

If the error is specifically about signing, work through the credential configuration rather than treating it like a code or dependency problem.

This is one of those situations where identifying the category of the error is much more useful than knowing a particular command.

8. If It Worked Before, Ask What Changed

This is probably my favorite debugging question:

What changed immediately before the build started failing?

Don't underestimate how useful this is.

If yesterday you had:

EAS build → SUCCESS

and today you have:

EAS build → FAILED

something changed.

Maybe you:

installed a package
upgraded Expo
changed app.json
changed eas.json
modified environment variables
changed an Android dependency
added a config plugin
changed native code

Start there.

For example, if the failure appeared immediately after:

npx expo install some-package

I would investigate that package before touching ten unrelated parts of the project.

9. Clean Up Before Rebuilding

If you've already made changes trying to fix the problem, make sure you're not debugging an old local state.

For a native project, a clean build can sometimes help:

cd android
./gradlew clean
cd ..

For Expo projects using prebuild, you may also need to regenerate native projects depending on your setup.

But don't use cleaning as your first response to every error.

If the build is failing because a dependency is genuinely incompatible, cleaning won't magically make the dependency compatible.

It only removes cached/generated build artifacts.

The Most Important Part: Find the Root Error

This is the part that took me the longest to appreciate.

When a build log contains hundreds of lines, the error at the bottom isn't necessarily the error you need to fix.

For example:

Task :app:assembleRelease FAILED

is not particularly useful.

Neither is:

Build failed

The useful part might be 30, 50, or even 200 lines above it.

You might eventually find:

Duplicate class androidx.lifecycle.ViewModel

And suddenly the whole situation makes sense.

Or:

Could not resolve com.google.firebase:...

Now you're dealing with a dependency resolution problem.

Or:

Missing environment variable: API_URL

Now you know exactly where to look.

The final error tells you that the build stopped. The underlying error tells you why.

What If Your Error Doesn't Match Any Of These?

This is where things get much more frustrating.

You can search the exact error message and find ten different Stack Overflow answers.

One says to upgrade Gradle.

Another says to delete node_modules.

Another says to run expo prebuild --clean.

Someone else says to downgrade React Native.

And suddenly you're changing five different things without knowing which one actually matters.

I've made that mistake myself.

The problem with large React Native and Expo build logs is that they often contain a lot of information but very little prioritization.

You don't necessarily need another list of 15 possible fixes.

You need to know:

Which part of this particular log is actually causing the failure?

That's also the problem I wanted to solve with FixMyError.

Instead of manually digging through a huge React Native or Expo error log and trying to decide which line matters, you can paste the log into FixMyError and get a focused diagnosis aimed at identifying the most likely cause and the first fix worth trying.

It's particularly useful when your error doesn't fit neatly into one of the common categories above and you're staring at a wall of Gradle, Expo, or native build output wondering where to even start.

You don't need to use it for every error. If the log clearly tells you what's wrong, fix it and move on.

But when the useful information is buried somewhere inside a massive build log, that's exactly when a diagnostic tool becomes useful.

A Simple Workflow I Use Now

When an Expo EAS build fails, I don't immediately start changing dependencies or upgrading packages.

I go through this:

1. Find the actual failure

Don't stop at:

Build failed

Find the underlying error.

2. Identify the category

Is it:

configuration?
dependency?
Android/Gradle?
iOS/Xcode?
environment variables?
credentials?
native module compatibility?

3. Ask what changed

What did you install, upgrade, or modify immediately before the failure?

4. Check the full log

Don't assume the last error line is the root cause.

5. Run the relevant diagnostic tools

For example:

npx expo-doctor

and inspect your EAS configuration and dependencies.

6. Change one thing at a time

Don't simultaneously upgrade Expo, downgrade Gradle, delete node_modules, regenerate native projects, and change your dependencies.

If the build starts working afterward, you won't know what actually fixed it.

7. If the log is still unclear, diagnose the log itself

That's where a tool like FixMyError can save time.

Final Thoughts

An EAS Build failed message can look like a single problem, but it really isn't.

EAS is just the environment where the failure becomes visible.

The actual cause might be hiding in:

Expo configuration
native dependencies
Gradle
Xcode
environment variables
credentials
config plugins
or a package that isn't compatible with your current SDK

The biggest improvement you can make to your debugging process is to stop treating:

Build failed

as the error.

Treat it as the symptom.

Then work backward until you find the first specific failure that actually explains what happened.

And if you're staring at a huge build log and can't tell which of the hundreds of lines actually matters, that's precisely the kind of situation where having something analyze the error for you can be useful.

Happy debugging.

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

Asta Silva — Tue, 04 Aug 2026 12:26:30 +0000

You make a small change to your React Native project, install a new package, or upgrade a dependency. Everything looks fine until you try to build your Android app.

Then Gradle stops with something like:

Execution failed for task ':app:mergeDexDebug'.

> com.android.builder.dexing.DexArchiveMergerException:
Error while merging dex archives

Or maybe you see:

Cannot fit requested classes in a single dex file

or:

Duplicate class found

At first glance, this error feels confusing because it happens during the Android build process, not inside your JavaScript or React Native code.

Your components are fine. Your logic is fine.

The problem is usually somewhere inside your Android dependencies.

In this guide, we will go through what causes mergeDexDebug failures, how to identify the real problem, and the fixes that actually work.

What Does `mergeDexDebug` Actually Mean?

When you build a React Native Android app, your JavaScript code is not the only thing being packaged.

Your project also includes native Android dependencies from:

React Native modules
Expo packages
Firebase libraries
AndroidX libraries
Third-party native packages

During the Android build, Gradle converts these Java/Kotlin dependencies into DEX files that Android can run.

The mergeDexDebug task is the step where Android combines those generated DEX files together.

When this step fails, it usually means:

there are too many methods to fit into one DEX file
two dependencies contain the same classes
dependency versions are conflicting

Cause 1: Your App Has Too Many Methods (64K Limit)

One of the most common reasons for this error is Android's method limit.

A single DEX file can only contain around 65,536 methods.

If your project includes many libraries, you can eventually exceed this limit.

The error usually looks like:

Cannot fit requested classes in a single dex file

or:

The number of method references in a .dex file cannot exceed 64K

This happens frequently in projects using packages like:

Firebase
Google Play Services
Maps
Analytics libraries
Multiple native modules

Fix: Enable Multidex

Open:

android/app/build.gradle

Find:

defaultConfig {
}

Add:

defaultConfig {
    multiDexEnabled true
}

Then add the multidex dependency:

dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

After that, clean your build:

cd android
./gradlew clean
cd ..

Then rebuild your app.

Cause 2: Duplicate Classes Between Dependencies

Another common reason is dependency duplication.

You may see something like:

Duplicate class androidx.lifecycle.ViewModel found in modules:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

and

androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1

This means two libraries are trying to include different versions of the same Android classes.

Gradle does not know which one should be used, so the build fails.

Fix: Align Dependency Versions

Check your Android dependencies.

You can inspect your dependency tree with:

cd android
./gradlew app:dependencies

Look for libraries that appear multiple times with different versions.

For example:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

androidx.lifecycle:lifecycle-viewmodel:2.6.1

The solution is usually to make all related dependencies use the same version.

After updating dependencies, run:

./gradlew clean

and rebuild.

Cause 3: A Recently Installed Native Package Introduced Conflicts

Sometimes the problem appears right after installing a package.

For example:

npm install some-native-library

Everything works until the next Android build.

This happens because native packages are not only JavaScript code. They also add Android dependencies.

A new package can introduce:

conflicting AndroidX versions
outdated libraries
duplicate classes

If the error appeared immediately after installing something new, that package is the first thing I would investigate.

How To Find The Real Cause Faster

Instead of guessing, get more information from Gradle.

Run:

cd android
./gradlew app:assembleDebug --stacktrace

The important part is usually not the final error line.

The useful information is often several lines above it.

Look for:

duplicate class names
conflicting library versions
dependency names

The last line often only says:

Execution failed for task ':app:mergeDexDebug'

but the actual reason appears earlier.

Clean Your Android Build Cache

After changing dependencies, Gradle may still use old build files.

Run:

cd android
./gradlew clean
cd ..

For React Native CLI projects:

npx react-native run-android

For Expo projects:

npx expo run:android

A surprising number of build problems disappear after a proper clean rebuild.

Preventing Future `mergeDexDebug` Errors

A few habits can save a lot of debugging time:

Keep dependencies updated

Old native dependencies are a common source of Android build conflicts.

Avoid installing unnecessary packages

Every native package increases the complexity of your Android dependency tree.

Check changes after adding native libraries

If your build breaks immediately after installing a package, don't start changing random Gradle files.

First check what dependency that package introduced.

Understand the error before applying fixes

A mergeDexDebug failure is not one single problem.

It is a symptom.

The real cause could be:

too many methods
duplicate classes
incompatible versions
a broken native dependency

Finding the cause is usually faster than trying random fixes.

Need Help Diagnosing React Native Errors?

Sometimes build errors are frustrating because the important clue is buried inside hundreds of lines of Gradle output.

That is exactly why I built FixMyError — a tool designed around the real debugging process developers go through.

You can paste your React Native or Expo error log and get a focused diagnosis that explains what is likely causing the problem and what fix is worth trying first.

Instead of searching through dozens of similar Stack Overflow answers, you can start with a clearer direction.

You can check it out here:

FixMyError

React Native Android build errors can look intimidating, but once you understand where the failure happens, most mergeDexDebug problems become much easier to diagnose.

The key is not memorizing commands.

It is learning how to read what Gradle is actually telling you.

How to Fix "Duplicate class ... found in modules" in React Native & Expo

Asta Silva — Thu, 23 Jul 2026 12:35:12 +0000

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason.

Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always...

Instead, Gradle greets you with something like this:

Execution failed for task ':app:checkDebugDuplicateClasses'.

Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar

Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar

Duplicate class ...

At first glance, the error looks straightforward: there are duplicate classes. Easy enough, right?

Not exactly.

In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different.

Let's break down what's actually happening and, more importantly, how to fix it.

Why this error happens

Every Android library included in your project contains compiled Java or Kotlin classes.

When Gradle builds your application, it combines all of those libraries into a single APK or AAB.

If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged.

Instead of guessing, it stops the build with a Duplicate class error.

The difficult part is that the dependency causing the conflict usually isn't the one shown in the error.

Very often, it's another package pulling in an older or incompatible version behind the scenes.

The most common causes

After seeing this error many times, these are usually the culprits.

1. Two libraries depend on different versions of the same package

This is by far the most common scenario.

For example:

Library A requires:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

while Library B depends on:

androidx.lifecycle:lifecycle-viewmodel:2.6.1

Both versions get added to your dependency graph, eventually leading to duplicate classes.

2. An outdated React Native package

Older React Native libraries often haven't been updated for newer AndroidX or Google Play Services versions.

Even though your project is current, that one dependency may still reference libraries released years ago.

3. Expo SDK upgrades

After upgrading Expo, many native dependency versions change.

If one third-party package hasn't caught up yet, Gradle may end up resolving incompatible versions.

This is especially common immediately after major SDK releases.

4. Mixing manual native configuration with Expo-managed dependencies

Sometimes developers manually add Android dependencies that Expo already manages internally.

The result is two copies of essentially the same library.

How to fix it

There isn't one universal solution, but these steps solve the majority of cases.

Step 1 — Read the duplicated class carefully

Don't focus on the entire error.

Look specifically for the two modules involved.

For example:

lifecycle-viewmodel-2.8.2

lifecycle-viewmodel-ktx-2.6.1

Those names usually point you toward the conflicting dependency.

Step 2 — Find who is importing it

Run:

./gradlew app:dependencies

./gradlew app:dependencyInsight --dependency lifecycle-viewmodel

This shows which package is pulling each version into your project.

It's much faster than guessing.

Step 3 — Update outdated packages

If one library is significantly behind, updating it often resolves the conflict immediately.

Always check whether a newer version exists before trying complicated Gradle workarounds.

Step 4 — Clean the project

Sometimes Gradle continues using cached artifacts.

Try:

cd android

./gradlew clean

Then rebuild.

Step 5 — Regenerate native files (Expo)

If you're using Expo Prebuild:

npx expo prebuild --clean

This recreates the native Android project using your current configuration.

Step 6 — Force dependency versions (only if necessary)

Sometimes you need to force Gradle to use one specific version.

For example:

configurations.all {
    resolutionStrategy {
        force "androidx.lifecycle:lifecycle-viewmodel:2.8.2"
    }
}

Use this carefully.

If two libraries genuinely require incompatible versions, forcing one version may create runtime problems later.

How to avoid this error in the future

While duplicate class errors can't always be prevented, these habits reduce the chances considerably.

Keep Expo SDKs reasonably up to date.
Avoid abandoned React Native libraries.
Update dependencies together instead of one at a time.
Review package compatibility before major upgrades.
Avoid manually adding Android dependencies unless absolutely necessary.

When the error isn't actually the problem

One thing that makes this error frustrating is that the duplicate classes are often just a symptom.

The real issue might be:

an outdated library,
conflicting Firebase dependencies,
mixed AndroidX versions,
incompatible Google Play Services packages,
or an incomplete Expo migration.

That's why simply searching the duplicated class name doesn't always lead to the correct fix.

Understanding why those dependencies ended up together is usually more important than the class itself.

How FixMyError can help

Instead of manually digging through Gradle output, dependency trees and dozens of forum posts, you can paste the full error into FixMyError.

The tool analyzes the build log, identifies the likely source of the conflict, explains what's happening in plain English, and suggests fixes based on the specific dependencies involved.

Rather than treating every duplicate class error as identical, it tries to narrow the problem down to the actual cause behind your particular build failure.

Final thoughts

Duplicate class errors are among the most frustrating Android build issues because the message rarely points directly to the package that's responsible.

The good news is that, in most cases, the problem comes down to dependency resolution rather than something fundamentally broken in your project.

Once you identify which libraries are introducing conflicting versions, the fix usually becomes much more straightforward.

If you're currently staring at a wall of Gradle output wondering where to begin, start by identifying the conflicting modules, trace where they're coming from, and work outward from there.

It takes a bit of patience, but it's almost always easier than blindly trying random fixes from different Stack Overflow threads.

How to fix `global._getAnimationTimestamp is not a function` After Upgrading to Expo SDK 55

Asta Silva — Thu, 16 Jul 2026 09:50:43 +0000

I recently spent far more time than I'd like to admit chasing down a hard crash after upgrading a project from Expo SDK 54 to 55.

The app launched fine. Navigation worked. Everything looked normal.

Then the moment a Reanimated animation fired, the app exploded with a red screen:

Render Error

global._getAnimationTimestamp is not a function (it is undefined)

In my case, the crash happened inside a useEffect that called withTiming() on a shared value when a tab gained focus.

My first assumption was a dependency mismatch between react-native-reanimated and react-native-worklets. I checked versions, verified the dependency tree, and even started looking for Babel configuration issues.

Everything looked correct.

As it turns out, the problem wasn't in the JavaScript code at all.

What Is Actually Happening?

At first glance, this error looks like a breaking change inside Reanimated or a bad project configuration.

In reality, it's usually a sync problem between your JavaScript bundle and your native application binary.

The important clue is the function name itself:

_getAnimationTimestamp

This isn't a function your application calls directly. It's one of the internal functions Reanimated expects to find in the native runtime.

Reanimated relies heavily on JSI (JavaScript Interface) to bridge JavaScript directly to native C++ code for performance-critical animation work.

When you upgrade to Expo SDK 55, Reanimated gets upgraded as well (typically from 4.1.x to 4.2.x, depending on your project).

Your Metro server immediately starts serving the updated JavaScript bundle.

The problem is that your custom development client is still running the native code that was compiled before the upgrade.

Now you have two different versions talking to each other:

The JavaScript side expects the newer Reanimated runtime.
The native side is still exposing the older implementation.

The updated JavaScript bundle expects _getAnimationTimestamp to exist.

Your older native client doesn't provide that function yet.

The moment Reanimated tries to use it, the app crashes.

Why Reinstalling Dependencies Doesn't Help

I went through the usual checklist first:

Reinstall dependencies
Verify package versions
Check Babel configuration
Clear node_modules
Run npm install again

None of it fixed the issue.

That's because the problem isn't living in your JavaScript dependencies.

Your packages can be perfectly correct while your device or simulator is still running an outdated native binary.

As long as the native client wasn't rebuilt after the upgrade, the crash will continue to happen.

When You'll Usually See This Error

One thing worth mentioning is that this mostly shows up when you're using a custom development client.

If you're using Expo Go, Expo manages the native runtime for you, so JavaScript and native code generally stay in sync.

This issue is much more common when you're working with:

Custom dev-clients
expo run:android
expo run:ios
Development builds generated through EAS

In those environments, it's entirely possible for Metro to be serving new JavaScript while your device is still running an older native build.

The Fix

A normal JavaScript reload won't solve this.

Pressing r in the Metro terminal only refreshes the JavaScript bundle. It does not rebuild the native application.

To fix the issue, you need both sides of the application running the same version.

Step 1: Clear Metro's Cache

Stop Metro completely and restart it with a clean cache:

npx expo start -c

This removes the possibility of Metro serving stale transformed files.

Step 2: Rebuild the Native Client

If you're building locally, generate a fresh native application:

npx expo run:ios

# or

npx expo run:android

This recompiles the native code using the versions currently installed in your project.

Step 3: Rebuild Your Development Build (EAS)

If you're using EAS development builds, you'll need to generate a completely new build and install it on your device.

eas build --profile development

Once the build finishes, install the new IPA or APK and launch the updated client.

Why This Fix Works

After rebuilding, both sides of the application are finally using the same version of Reanimated:

Metro serves the updated JavaScript bundle.
The native binary contains the matching JSI bindings.

Once those versions line up again, Reanimated can find the functions it expects and the crash disappears.

A Quick Note on Debugging

This was one of those bugs that initially looked like a dependency issue, then a Babel issue, then a Reanimated issue.

In reality, it was just an out-of-date native build.

Problems like this are one of the more frustrating parts of React Native because the error message rarely points to the actual cause. It's easy to spend hours looking at package versions when the real fix is simply rebuilding the native client.

After spending enough evenings digging through stack traces, GitHub issues, and old forum threads, I ended up building a small tool called Fix My Error.

You paste in the error output, and it helps narrow down likely causes and fixes without having to bounce between ten different tabs looking for someone who hit the same problem three years ago.

For this particular error, though, the fix turned out to be much simpler than I expected: clear Metro, rebuild the native client, and make sure your JavaScript bundle and native runtime are actually running the same version.

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Asta Silva — Thu, 09 Jul 2026 12:44:37 +0000

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

If you recently upgraded a project to React Native 0.73+ or bumped your Expo SDK to version 50+, you may have run into an Android build error that looks something like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':react-native-some-old-library'.

> Namespace not specified for group 'react-native-some-old-library'
  and version '1.0.0' as per the Android Gradle Plugin 8.0+ guidelines.

At first glance, it looks like something is wrong with your app. In most cases, it isn't.

The error is usually coming from an older dependency inside node_modules.

Here's what's actually causing it and how to fix it properly.

The Root Cause

Before Android Gradle Plugin (AGP) 8.0, Android libraries could define their package name inside AndroidManifest.xml.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.someoldlibrary">

Starting with AGP 8.0, that is no longer enough.

Every Android module is now expected to define a namespace inside its build.gradle file.

When you upgrade React Native or Expo, your Android tooling gets upgraded as well. The problem is that many older React Native libraries haven't been updated to follow the new requirement.

As soon as Gradle encounters one of those libraries, it stops during configuration and the build fails.

This started showing up much more frequently after Expo SDK 50 and newer React Native releases adopted newer Android tooling.

Before You Change Anything

Look closely at the error message.

Most of the time you'll see something like:

A problem occurred configuring project ':react-native-some-old-library'

That project name is usually the library causing the issue.

A common mistake is to start editing your app's own Gradle files. In most cases, the problem is actually inside the dependency listed in the error.

The Fix: Use patch-package

Since the problem comes from a third-party library, editing files directly inside node_modules isn't a real fix.

The next time you run npm install, your changes will be overwritten.

Instead, make the change once and save it using patch-package.

Step 1: Find the Package Name

Navigate to the library's manifest file:

node_modules/react-native-some-old-library/android/src/main/AndroidManifest.xml

Look for the package attribute:

<manifest
    package="com.someoldlibrary">

Copy that value.

You'll use it as the namespace in the next step.

Step 2: Add the Missing Namespace

Open:

node_modules/react-native-some-old-library/android/build.gradle

Find the android {} block and add the namespace at the top:

android {
    namespace "com.someoldlibrary"

    compileSdkVersion safeExtGet('compileSdkVersion', 34)

    defaultConfig {
        minSdkVersion safeExtGet('minSdkVersion', 21)
        targetSdkVersion safeExtGet('targetSdkVersion', 34)
    }

    // ...
}

Make sure the namespace exactly matches the package name from the manifest.

Step 3: Generate a Patch

From your project root, run:

npx patch-package react-native-some-old-library

This creates a file inside a new patches directory containing the modification you just made.

Commit that file to Git.

Step 4: Apply the Patch Automatically

Open package.json and add a postinstall script:

{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "postinstall": "patch-package"
  }
}

Now whenever someone runs npm install—whether it's you, another developer, CI, or EAS Build—the patch gets applied automatically.

That's It

Clear any caches if needed and run your Android build again.

The build should now complete normally.

More importantly, you won't have to keep making the same edit every time node_modules gets reinstalled.

If you're working with older React Native dependencies, this is usually the cleanest way to handle AGP 8 namespace issues without waiting for the library maintainer to release an update.

How to Fix Apple Silicon CocoaPods Errors Without Messy Terminal Aliases

Asta Silva — Mon, 06 Jul 2026 12:53:36 +0000

The Crash

You pull down a fresh React Native repo, or you upgrade your Expo project, navigate to your /ios directory, and run your standard installation command:

pod install

Instead of a clean build, your terminal drops a wall of text pointing to a compilation or architecture conflict:

LoadError - dylib library not found for ffi_c - /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.5/lib/ffi_c.bundle

Or you are hit with an explicit architecture clash during compilation:

Ignoring ffi-1.15.5 because its extensions are not built.
Arch mismatch: x86_64 vs arm64

Why the Common Internet Advice is a Trap

If you search for this error on Stack Overflow or Reddit, the top answers almost always tell you to run your terminal in Rosetta mode or force compilation with an architecture flag:

sudo arch -x86_64 gem install ffi
arch -x86_64 pod install

Do not do this.

While this might bypass the error temporarily, it introduces a highly unstable configuration to your machine. It forces an Apple Silicon Mac to use Intel x86 emulation for specific Ruby gems while running an underlying system interpreter that expects native ARM (arm64) code.

This mixed-architecture setup will inevitably break your bundler, conflict with Node native modules, and cause random, hard-to-diagnose failures during local builds.

The real problem isn't your hardware; it's that your environment is attempting to load global, system-level Intel configurations inside a modern ARM environment.

The Fix: Resolving the Conflict Natively

To resolve the issue permanently, you need to purge the conflicting configurations and ensure your dependency manager runs natively on Apple Silicon.

Step 1: Purge the Broken System Gems

First, clear out any global, system-level gems that were compiled incorrectly under mixed architectures.

Run the following command from your root directory to remove CocoaPods configurations managed by the system Ruby installation:

gem list --local | grep cocoapods | awk '{print $1}' | xargs sudo gem uninstall

Step 2: Install the Native ARM Version of CocoaPods via Homebrew

Instead of relying on the default macOS system Ruby interpreter to manage your gems, install CocoaPods through Homebrew.

Homebrew automatically detects your M-series architecture and fetches the dedicated, optimized native arm64 binary.

brew install cocoapods

Step 3: Isolate Your Ruby Environment (Optional but Highly Recommended)

Using the default pre-installed macOS system Ruby (/usr/bin/ruby) frequently causes permissions and architecture locks.

For a stable environment, switch to a local Ruby version manager like rbenv or chruby to handle your project dependencies cleanly.

# Install rbenv via Homebrew
brew install rbenv ruby-build

# Initialize rbenv in your shell configuration (~/.zshrc or ~/.bash_profile)
echo 'eval "$(rbenv init -)"' >> ~/.zshrc
source ~/.zshrc

# Install and set a modern native Ruby version
rbenv install 3.2.2
rbenv global 3.2.2

Step 4: Clear the Local State and Install Natively

Now that your environment relies on native binaries, clear your project's cached build configurations to ensure no stale artifacts remain:

cd ios
pod deintegrate
rm -rf Podfile.lock

Finally, run your installation command normally.

It will complete natively without requiring any arch -x86_64 prefixes or Rosetta terminal wrappers:

pod install

Wrestling with local environment drift, corrupted build paths, and conflicting architectures can pull you out of the development loop for hours.

If you are tired of decoding cryptic terminal logs and tracking down configuration bugs by hand, take a look at FixMyError. It is a clean diagnostic workspace built to parse your build outputs instantly, giving you clear solutions so you can get right back to building your app.

Fixing "JavaScript heap out of memory" during production builds

Asta Silva — Fri, 03 Jul 2026 11:31:13 +0000

If you are running a large production build or a data-heavy script in Node.js, you have probably run into this crash:

Plaintext

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

The V8 stack trace that follows usually doesn't show the actual file or line causing the issue, making it difficult to debug.

Here is why this happens and how to fix it across your local environment, build scripts, and CI/CD pipelines.

Why This Happens

By default, the V8 engine limits the memory a single Node.js process can allocate. Depending on your Node version and system architecture, this limit defaults to roughly 1.5 GB or 4 GB.

This is usually fine for standard applications, but modern build tools (like Webpack, Vite, Next.js, or the TypeScript compiler) build large abstract syntax trees (AST) in memory. If your dependency graph or codebase grows past a certain size, the bundler hits the default allocation limit and crashes.

The Fix: Increase `max-old-space-size`

The direct solution is to instruct the V8 engine to allocate more memory using the --max-old-space-size flag (defined in megabytes).

Common allocation values

4GB Allocation: --max-old-space-size=4096
8GB Allocation: --max-old-space-size=8192

1. Temporary Local Environment Fix

To unblock your local machine for a single run, set the environment variable before your build command:

Bash

# Unix/macOS
NODE_OPTIONS="--max-old-space-size=4096" npm run build

# Windows (Command Prompt)
set NODE_OPTIONS=--max-old-space-size=4096 && npm run build

# Windows (PowerShell)
$env:NODE_OPTIONS="--max-old-space-size=4096"; npm run build

2. Permanent Project Fix (`package.json`)

To ensure everyone on the team uses the same config, add it directly to your build scripts inside package.json. Use cross-env to avoid platform-specific syntax issues on Windows:

JSON

{
  "scripts": {
    "build": "cross-env NODE_OPTIONS='--max-old-space-size=4096' next build",
    "compile": "cross-env NODE_OPTIONS='--max-old-space-size=4096' vite build"
  }
}

Fixing the Error in CI/CD Pipelines

If your local builds pass but your deployment servers crash, you need to pass the memory variable to your runner or cloud provider.

GitHub Actions

Add the environment variable to your build step configuration:

YAML

- name: Run Production Build
  env:
    NODE_OPTIONS: --max-old-space-size=4096
  run: npm run build

Docker Containers

Pass it as an environment parameter within your Dockerfile:

Dockerfile

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
ENV NODE_OPTIONS="--max-old-space-size=4096"
RUN npm run build

Managed Hosting (Vercel, Netlify, Cloudflare Pages)

Go to your project settings dashboard.
Open the Environment Variables tab.
Add a new key: NODE_OPTIONS with the value --max-old-space-size=4096.
Trigger a new deployment.

Checking for Underlying Problems

If you allocate 8GB or more of RAM and the build still fails, you are likely dealing with a memory leak or an infinite compilation loop rather than just a large codebase. Check these three areas:

Disable Source Maps in Production

Generating source maps for massive third-party dependencies takes a lot of memory. If your server is constrained, disable them in your config file to see if memory usage drops.

JavaScript

// next.config.js example
module.exports = {
  productionBrowserSourceMaps: false,
};

Audit Circular Dependencies

Circular imports force compilers into recursive evaluation loops that drain memory. Use madge to audit your source directory for cyclical references:

Bash

npx madge --circular ./src

Inspect the Runtime Heap

If the crash occurs on a running backend server rather than during a build script, you have a runtime leak (e.g., event listeners not being cleaned up, or global cache arrays growing indefinitely).

Start your server with the inspector flag enabled:

Bash

node --inspect index.js

Open Chrome DevTools (chrome://inspect), target your Node process, and take a Heap Snapshot to see which objects are failing to garbage collect.

How to Fix FCM "MismatchSenderId" in Multi-Environment Expo (EAS) Builds

Asta Silva — Sat, 27 Jun 2026 09:02:52 +0000

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments

If you are managing multiple environments (Staging, Preview, Production) in a React Native Expo app, setting up Firebase Cloud Messaging (FCM) can quickly turn into a credential nightmare.

You set up separate Firebase projects for each environment, download your config files, and configure your service accounts. Everything looks right. But when you test push notifications on your staging build, you hit a wall:

Error: MismatchSenderId

This error doesn't mean your code is broken. It means you've hit a structural limitation in how Expo EAS handles push credentials.

Here is exactly why this happens and how to architect a clean solution.

Why the Mismatch Happens

The MismatchSenderId error occurs because of a strict identity mismatch:

The device token was generated by Firebase Project A, but the notification payload was dispatched using credentials from Firebase Project B.

In a standard web or backend setup, this is easy to manage. But in the Expo ecosystem, you run into the EAS Project Limit:

Expo maps push notification service accounts per EAS Project, not per EAS Build Profile (development, preview, production).

When you run eas credentials or use the automated CLI prompts, EAS expects one default push notification Service Account (SA) key for the entire project.

If you try to reuse or attach the same service account across different Google Cloud/Firebase projects via IAM permissions, FCM will reject the cross-project token request, throwing MismatchSenderId.

Solution 1: Split Your EAS Projects (Recommended for Clean Automation)

If you want to rely on Expo's automated push notification infrastructure without overriding credentials constantly, the cleanest architectural fix is to separate your environments at the EAS project level.

Instead of one EAS project with multiple build profiles, initialize separate EAS projects in your ecosystem:

your-app-staging
your-app-production

Implementation Steps

In your app.json, dynamically switch the expo.projectId and expo.slug based on an environment variable during your build step:

{
  "expo": {
    "name": "Your App",
    "slug": "your-app-production",
    "extra": {
      "eas": {
        "projectId": "YOUR-PROD-PROJECT-ID"
      }
    }
  }
}

Link your staging build profile to your staging EAS project.

Run eas credentials for each project separately. This allows you to upload the staging FCM Service Account to your staging EAS project, and the production FCM Service Account to your production EAS project.

Solution 2: Bypass EAS and Route Tokens on Your Backend

If separating your EAS projects isn't an option and you need to keep everything under a single Expo App ID, you have to stop relying on Expo's unified push notification server and handle routing downstream.

Implementation Steps

Tag Tokens by Environment

When your app requests a push notification token using Expo.getExpoPushTokenAsync(), append the current build environment metadata before sending it to your database:

const token = await Expo.getExpoPushTokenAsync();

// Save to backend alongside the environment flag
await saveTokenToBackend({
  token: token.data,
  environment: process.env.EXPO_PUBLIC_APP_ENV // 'staging' or 'production'
});

Handle Routing on Your Server

On your backend infrastructure, do not use a single global Firebase initialization instance.

Initialize multiple Firebase Admin SDK instances using the respective service account JSON keys for each environment.

When triggering a notification, check the token's environment tag and dispatch it explicitly through the matching Firebase Admin instance.

Verification Checklist Before Your Next Build

Before you trigger your next EAS build, double-check that your native configuration files aren't bleeding into each other:

Config Plugins: Ensure your app.json or app.config.js uses a dynamic config plugin to load google-services.json (Android) and GoogleService-Info.plist (iOS) based on the target build profile. If your staging build accidentally bundles the production google-services.json, your token identities will instantly mismatch.
Sender IDs: Verify that the sender ID inside your bundled client-side Firebase config explicitly matches the project ID of the service account used by your notification server.

I actually built a quick web tool called Fix My Error to automate troubleshooting these kinds of React Native, Expo, and Gradle build traps. If you're stuck on a cryptic error log, feel free to drop it in there to grab the configuration fix.

How to Fix Expo's Cryptic Upgrade Trap: Android Resource Linking Failed (splashscreen_logo not found)

Asta Silva — Sat, 20 Jun 2026 12:10:25 +0000

Upgrading your Expo SDK version to keep up with the latest App Store and Google Play requirements is usually a smooth process—until Gradle decides to punch you in the face with a cryptic asset compilation error.

If you just kicked off an Android build or ran a prebuild, and your terminal suddenly spit out a wall of red text looking exactly like this, you are not alone:

A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
> Android resource linking failed
error: resource drawable/splashscreen_logo (aka com.yourcompany.app:drawable/splashscreen_logo) not found.

The worst part about this error is that it doesn't give you a file name, a line number, or any mention of Expo.

It just drops a native Android resource compilation failure and leaves you to figure out the rest.

Let's break down exactly why this happens during Expo upgrades and how to fix it in two minutes flat.

Why This Happens: The Missing Asset Trap

This issue is a classic side effect of how newer Expo SDK versions handle Continuous Native Generation (CNG) via the expo-splash-screen plugin.

In older versions of Expo, if you only wanted a solid background color for your splash screen, you could get away with just defining backgroundColor in your config and skipping the logo image entirely.

The native generator would handle it gracefully.

However, in newer Expo SDK configurations, the prebuild engine has become much more strict.

If the image property is missing from your splash screen configuration, the Expo generator completely skips creating the native Android XML drawable references for the logo.

When the Android Gradle plugin compiles the app layer, it looks into the generated styles for the splash screen layout, tries to link the splashscreen_logo asset, finds a blank void, and crashes the entire build.

How to Fix It

To resolve this, we need to explicitly force the Expo prebuild engine to map a valid drawable resource so Gradle stops complaining.

Step 1: Update Your App Configuration

Open your app.json (or app.config.js) file and locate your plugins array.

Make sure the expo-splash-screen plugin block contains both a background color and an explicit path to a fallback image asset.

Even if you don't actually want a logo on your splash screen, you need to provide a placeholder image (like a tiny 1x1 transparent or solid pixel matching your background color) to satisfy the native compiler.

"plugins": [
  [
    "expo-splash-screen",
    {
      "backgroundColor": "#ffffff",
      "image": "./assets/splash-icon.png"
    }
  ]
]

Step 2: Clear and Regenerate Native Directories

Because native Android build directories heavily cache old configurations, simply changing app.json isn't always enough to clear out the corrupted Gradle state.

Run the following commands in your terminal to wipe the slate clean and force a fresh native generation:

# If you are testing local native builds:
npx expo prebuild --clean

# Or if you are running a fresh release compilation:
npx expo run:android --variant release --no-build-cache

Once the prebuild engine re-runs with the new configuration, it will successfully generate the splashscreen_logo.xml drawable file inside your native directories, and Gradle will breeze right past the linking stage.

Interactive Reference & Live Fix

If you want to view a fully verified configuration block or run this code through an interactive debugger to make sure your syntax matches up perfectly, you can check out the public resolution ledger here:

Fix My Error

Final Thoughts

Native Android build failures often look terrifying because the error message points to generated resources rather than the actual configuration mistake.

In this case, the root cause is usually a missing splash screen image definition after upgrading to a newer Expo SDK version.

Once you add a valid image path and regenerate your native directories, the build should proceed normally.

Have you run into any other weird compilation errors while moving your project up to the latest Expo SDK?

Drop them in the comments below and let's unblock them.

How to Fix "Module Could Not Be Found" in React Native & Expo

Asta Silva — Tue, 16 Jun 2026 11:38:43 +0000

We’ve all been there.

You find an awesome library, you run npx expo install, you import it into your code, and you start your development server.

You expect magic.

Instead, your simulator turns blindingly red with an error that looks something like this:

ERROR Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'RNGestureHandlerModule' could not be found.

Verify that your native modules are linked correctly.

Your app is completely bricked, your Metro bundler is acting confused, and you’re left wondering why a package you just installed is allegedly missing from the face of the earth.

Let's look at exactly why this happens and the 3-step checklist to clear it up without losing your sanity.

The Root Cause: JavaScript vs. Native Code

Modern Expo apps are beautifully split into two worlds:

The JS Bundle:

Your components, logic, and regular styles. Metro can hot-reload this in milliseconds.

The Native Layer:

The underlying Kotlin/Java and Swift/Objective-C code that actually talks to the phone's hardware.

When you install a package that uses native code (like react-native-gesture-handler, react-native-reanimated, or a map library), Metro cannot hot-reload native code into an active app binary.

If you are running a pre-built Development Client or using Expo Go, it only knows about the native modules that were compiled the last time you built the app.

It has no idea this new native module exists yet, so the registry panics and throws an Invariant Violation.

The Ultimate "Un-Brick My App" Checklist

Next time this red screen of death pops up, run through these three steps in order.

1. Rebuild the App Binary (The Absolute Must)

Simply restarting the Metro bundler won’t cut it.

You need to recompile your native code so the new library gets bundled into the actual simulator app.

Stop your server and run:

# For Android Simulators / Devices
npx expo run:android

# For iOS Simulators
npx expo run:ios

2. Force a Clean Prebuild (If Using Custom Native Directories)

If you are managing your own android or ios directories and things get desynced, force Expo to regenerate them with the new native dependencies linked:

npx expo prebuild --clean

This removes the generated native projects and recreates them from your Expo configuration, ensuring newly installed native packages are correctly integrated.

3. Nuke the Metro Cache

Sometimes Metro holds onto a stale dependency graph like a grudge.

If you’ve rebuilt the binary and it still complains, start your project while forcing a total cache clearance:

npx expo start -c

This clears Metro's cache and forces it to rebuild the dependency graph from scratch.

Final Thoughts

Native linking issues can feel incredibly frustrating because nothing appears wrong in your JavaScript code.

The problem is usually that your app binary and your JavaScript bundle have fallen out of sync.

Whenever you see errors like:

RNGestureHandlerModule could not be found
Native module cannot be null
TurboModuleRegistry.getEnforcing(...) failed
Module has not been registered

Run through this checklist:

Rebuild the app binary.
Run a clean prebuild if you're using native directories.
Clear the Metro cache.

Most of the time, one of those three steps will get you back up and running.

A Quick Sidebar for Tired Developers

If you're reading this at 2:00 AM while violently copy-pasting cryptic mobile stack traces into search engines, I feel your pain deeply.

I got so tired of hunting down hidden Gradle errors and obscure CocoaPods issues that I decided to build a tool to automate the headache.

It's called Fix My Error.

I set up a completely registration-free sandbox right on the homepage using this exact native linkage error so you can see how it works in real time without handing over your data.

If you like how it parses the logs, you can drop your own daily errors into the core engine with a free account (which gives you 5 free fixes per day), or check out the Pro tier if you're working in a heavy production environment.

Give the sandbox a spin next time Expo decides to ruin your afternoon, and let me know if it helps your workflow.

How do you usually handle these types of native linking bugs?

Drop a comment if this checklist worked for you, or let me know if there's an obscure Expo error that's currently driving you crazy.

DEV Community: Asta Silva

How to Fix Expo Doctor Errors in Expo

First, run Expo Doctor by itself

Check your Expo SDK version

Fix packages that are on the wrong version

Do not blindly update everything

Check package.json for old dependencies

Check for packages that are not compatible with your project

Check your Expo configuration

Check Expo config plugins

Check for duplicate dependencies

Check your React Native version too

Run expo-doctor again after fixing something

What if Expo Doctor still fails?

Clear the cache if the project still behaves strangely

When reinstalling node_modules makes sense

Be careful when upgrading an Expo project

A simple way to approach Expo Doctor

1. Run Expo Doctor

2. Find the failed check

3. Read the details underneath

4. Check what changed recently

5. Fix the smallest thing first

6. Run Expo Doctor again

One example

Final thoughts

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

First, read the exact module Metro cannot find

Check the file name and capitalization

Make sure the package is actually installed

Check if the package name is correct

Reset the Metro cache

Check your node_modules

Check whether you are importing from the correct location

Be careful with relative paths

Check whether the package is compatible with Expo

Watch out for renamed or removed files

Check index files

Default exports and named exports are a different problem, but still worth checking

Monorepos can make module resolution more complicated

If you use Expo Router, check your imports and project structure

Do not immediately delete everything

A quick example

Final thoughts

How to Fix EAS Build Failed Errors in Expo

First: Don't Focus on "EAS Build Failed"

1. Open the Full EAS Build Logs

2. Check Whether the Problem Is Actually Your Expo Configuration

3. Check Your Expo SDK and Native Dependencies

4. If the Error Mentions Gradle, Investigate the Android Build

5. Check Your Environment Variables

6. Check Your EAS Build Profile

7. Don't Ignore Credentials Errors

8. If It Worked Before, Ask What Changed

9. Clean Up Before Rebuilding

The Most Important Part: Find the Root Error

What If Your Error Doesn't Match Any Of These?

A Simple Workflow I Use Now

1. Find the actual failure

2. Identify the category

3. Ask what changed

4. Check the full log

5. Run the relevant diagnostic tools

6. Change one thing at a time

7. If the log is still unclear, diagnose the log itself

Final Thoughts

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

What Does mergeDexDebug Actually Mean?

Cause 1: Your App Has Too Many Methods (64K Limit)

Fix: Enable Multidex

Cause 2: Duplicate Classes Between Dependencies

Fix: Align Dependency Versions

Cause 3: A Recently Installed Native Package Introduced Conflicts

How To Find The Real Cause Faster

Clean Your Android Build Cache

Preventing Future mergeDexDebug Errors

Keep dependencies updated

Avoid installing unnecessary packages

Check changes after adding native libraries

Check `package.json` for old dependencies

Run `expo-doctor` again after fixing something

When reinstalling `node_modules` makes sense

Check your `node_modules`

Check `index` files

What Does `mergeDexDebug` Actually Mean?

Preventing Future `mergeDexDebug` Errors

The Fix: Increase `max-old-space-size`

2. Permanent Project Fix (`package.json`)