DEV Community: Asta Silva

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.

Why Your Mobile App Works Perfectly Locally But Crashes Instantly in TestFlight

Asta Silva — Thu, 11 Jun 2026 08:58:52 +0000

We’ve all been there. You spend weeks building a feature, testing it on your local simulator or a physical device running a development stream. Everything is butter. No lag, no warnings.

You confidently bundle the app, ship it to TestFlight, wait for Apple to finish processing, download it... and the moment you tap the app icon, it instantly flashes and closes. Hard crash.

Before you lose your mind or start blindly tweaking code, remember that production builds behave entirely differently than development environments.

Here are the four most common reasons your app dies the literal second it hits production, and exactly how to fix them.

1. The Missing Privacy Keys String (`Info.plist`)

If your app requests permissions for features like Location Services (maps, background location), the Camera, or the Photo Library, Apple requires you to explicitly state why in your Info.plist file using usage description keys (like NSCameraUsageDescription or NSLocationWhenInUseUsageDescription).

The Gotcha

In a local development environment, sometimes a framework will let a missing string slide, fallback to a default, or catch the exception gracefully.

The Production Reality

Apple’s iOS security layer will ruthlessly and instantly terminate the application binary on launch if your production code attempts to initialize a library requiring these permissions without the matching text string configured.

The Fix

Double-check your Info.plist (or your Expo app.json plugins). Make sure every single hardware or permission API your code imports has a clear, user-facing explanation string attached.

2. Missing Push Notification Entitlements

If your application includes code for push notifications (even if you haven’t fully wired up the backend yet), your binary needs specific clearance to launch.

The Gotcha

Local builds often bypass strict entitlement checks, or run using a wildcard development provisioning profile that covers everything loosely.

The Production Reality

When built for distribution, if your app contains code for handling remote notifications but the App Store Provisioning Profile doesn't explicitly have the Push Notifications entitlement enabled, the OS will trigger a fatal launch mismatch exception.

The Fix

Head to your Apple Developer Account under Identifiers, verify that your App ID has Push Notifications checked, and regenerate your production profile.

3. Dead Code Elimination & Aggressive Minification

When building locally, your JS bundling or native compilation keeps debug code, metadata, and helper functions intact.

When you build for production, optimization tools like ProGuard/R8 (for Android native engines) or aggressive tree-shaking strip away "unused" code to shrink the binary size.

The Gotcha

Sometimes, these optimization tools accidentally strip away native modules or reflection classes used by third-party packages, assuming they are dead code because they aren't explicitly referenced in the main thread.

The Production Reality

The app boots up, looks for a compiled native library or native method bridge, finds a missing reference, and triggers a fatal crash right during initialization.

The Fix

If you are using native dependencies, make sure your obfuscation/minify configuration files explicitly include rules to keep specific third-party library paths intact.

4. Broken Initialization Flow (Environment Variables)

How does your app determine its backend URL or third-party service tokens?

If you are relying on a local .env file that is git-ignored, those values might not be making it into your production build machine or CI/CD pipeline.

The Gotcha

The app builds successfully because the compiler doesn't care if a string variable is blank or null at build time.

The Production Reality

On launch, your application's root mounting sequence tries to parse an undefined API key or a null base URL during setup. If your code doesn't have a fallback check, it throws a fatal JavaScript or runtime error before the first screen even renders.

The Fix

Always verify that your build dashboard (like Expo Application Services, GitHub Actions, or local production scripts) has your production environment variables explicitly mapped before hitting compile.

How to Stop Guessing and Find the Proof

Stop guessing and changing random lines of code hoping for a miracle. Apple leaves an exact paper trail for immediate launch crashes.

On Your Test Device

Open up the TestFlight app on your iPhone, tap on the application name, scroll down to Crash Logs, and you can view or share the exact file.

Inside Xcode

Navigate to:

Xcode > Window > Organizer > Crashes

Apple aggregates logs directly from TestFlight users here, often highlighting the exact line of compiled code that triggered the crash (look for terms like SIGABRT or EXC_CRASH).

What's the absolute strangest "works locally, breaks in production" bug you've ever had to hunt down?

Let's talk in the comments!

The React Native Native-Dependency Trap: How to Fix Demanding Build Failures Without Nuking node_modules

Asta Silva — Tue, 09 Jun 2026 09:24:56 +0000

It’s the same story every time. You run a simple package upgrade, or you decide it's time to bump your Expo SDK version. Locally, JavaScript compiled perfectly. But the second you run a native build, your terminal explodes with hundreds of lines of red text.

On iOS, it’s a cryptic CocoaPods could not find compatible versions for pod or a sudden compilation failure in AppDelegate.mm. On Android, it’s a fatal Gradle lifecycle error or a missing namespace exception.

When native dependencies break, most developers fall back on the classic loop: delete node_modules, delete package-lock.json, clear cache, reinstall, and pray.

But blind-nuking your files rarely fixes the underlying architectural conflict. Here is how to actually diagnose and surgically resolve native dependency hell in modern React Native and Expo apps.

1. The Root Cause: Transitive Dependency Syncing

When you install a library like react-native-reanimated or a native camera module, that library relies on specific versions of underlying native libraries (Pods or Android libraries).

If two different third-party packages require the same native dependency but expect completely different versions, your package manager forces a compromise in JavaScript. But when the native build tool (Xcode or Gradle) steps in, it sees two conflicting native frameworks trying to occupy the same space.

For Expo Users: Always Prioritize the Pinned Versions

Running npm install can bypass Expo's guardrails. Always use:

npx expo install --fix

This forces Expo to look at your current SDK version and automatically downgrade or upgrade conflicting community packages to their exact validated native counterparts.

2. The iOS Podfile.lock Paradox

If your team introduces a package or you pull down main and suddenly iOS won't build, the culprit is usually an out-of-sync Podfile.lock. Running pod install blindly sometimes isn't enough if cached pods are conflicting.

The Surgical Fix

Instead of deleting your whole project configuration, clear the native iOS build cache specifically:

cd ios && pod cache clean --all
rm -rf Pods Podfile.lock
pod install

This forces CocoaPods to re-evaluate the dependency tree from absolute scratch based on your current package.json, without losing your local JS settings.

3. The Android Gradle Namespace Meltdown

With newer versions of Gradle and React Native, the way native Android modules declare their packages has changed (moving entirely to namespace inside build.gradle).

If you are using an older, unmaintained community package, Gradle will completely fail to compile the app on launch.

The Surgical Fix

Instead of waiting for an open-source maintainer to update a dead repository, you can use patch-package or Expo Config Plugins to alter the third-party library’s build.gradle file locally.

Alternatively, ensure your android/gradle.properties has the proper architecture properties enabled:

android.useAndroidX=true
android.enableJetifier=true

Triage Your Terminal Output

The biggest mistake developers make is trying to read the very bottom of a failed build log.

Xcode and Gradle put the actual error at the beginning of the failure block, while the bottom lines are just the generic system telling you the process exited with code 1.

Always scroll back up to locate the first root error flag.

I'm currently tracking down these weird native compilation bugs and building a database of exact solutions for them. If you are currently fighting a messy React Native or Expo native stack trace that makes absolutely no sense, I built a live beta engine to parse them and spit out precise resolutions over at fix-my-error-app.com. Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

How to Fix Xcode C++ Compiler Errors in React Native (Yoga / glog / constexpr)

Asta Silva — Sat, 06 Jun 2026 09:37:43 +0000

You just upgraded your local development environment, updated Xcode, or bumped a minor patch version in your React Native project. You open your terminal, run your standard iOS build command, and instead of a clean bundling process, the terminal throws a massive wall of raw C++ compiler text at you.

The error logs likely point to internal framework files like Yoga.cpp, glog, or the fmt library, screaming about constexpr or consteval issues, or complaining that a specific language standard identifier is missing.

This is one of the single most frustrating traps in mobile development. Your JavaScript is perfect. Your React components are clean. But your entire build is dead because an underlying C++ compilation standard is fighting your new Xcode tooling.

Why This Happens to JavaScript Developers

React Native relies heavily on a core C++ layout engine called Yoga under the hood. When Apple updates Xcode, they also update the underlying compiler tools (Clang) and shift the default C++ language dialect standard forward (for example, enforcing strict C++20 or C++23 rules).

If an older version of a library in your node_modules uses a syntax decoration that the new compiler now considers illegal or deprecated, the native compilation step fails instantly. Because most mobile developers do not actively write pure C++, looking at a raw Clang compiler failure feels like looking at alien code.

Nuking DerivedData or running pod install twenty times will not change the fact that the compiler rules have changed.

The Solution: Force the C++ Language Standard Backwards

Instead of attempting to manually modify source code deep inside your native node_modules dependencies (which will just get overwritten the next time you install packages), you can use a CocoaPods post-install hook to force the compiler to accept the specific language dialect your dependencies need to pass the check.

Open the Podfile located inside your project's native ios directory. Scroll down to the bottom where your post_install loop lives, and inject this compiler flag override block:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # Force the compiler to use the stable C++17 standard for all sub-dependencies
      config.build_settings['CLANG_CXX_LANGUAGE_STANDARD'] = 'c++17'
    end
  end
end

By adding this configuration script, CocoaPods will automatically modify the native build files for every single sub-dependency when you run your installation pipeline, forcing Xcode to evaluate the underlying C++ libraries under a compatible standard framework.

Clear the Native Caches and Rebuild

Once the project configurations are updated, you must completely destroy the old build artifacts that were compiled under the conflicting settings, or Xcode will continue to throw the same syntax exception.

Run this quick command chain in your project terminal to wipe the native cache layers and execute a clean compilation:

# Clear Xcode's local compilation cache
rm -rf ~/Library/Developer/Xcode/DerivedData

# Re-evaluate the Podfile with the new compiler hook
cd ios
pod install --repo-update

# Return to root and boot the iOS simulator
cd ..
npx react-native run-ios

As soon as the native build pipelines evaluate your sub-dependencies through the consistent compiler standard, the cryptic layout exceptions will vanish and your bundle will build cleanly.

How to Fix Gradle Error: Unsupported class file major version (React Native & Expo)

Asta Silva — Wed, 03 Jun 2026 08:43:14 +0000

If your React Native or Expo Android compilation suddenly crashes with a massive terminal stack trace pointing to an "unsupported class file major version" or claims a class file has the wrong version (e.g., wrong version 65.0, should be 61.0), your environment is caught in a silent version mismatch.

This error almost always triggers right after you upgrade your Expo SDK, bump your React Native core version, or update Android Studio.

Here is exactly why this happens, how to decode the cryptic internal version numbers, and how to get your build compiling cleanly.

Why Did This Happen Suddenly?

When React Native or Expo upgrades their framework architecture, they also upgrade the required version of the Android Gradle Plugin (AGP) inside your project.

Each version of AGP requires a strict minimum version of the Java Development Kit (JDK) to run the compilation pipeline. If your system's global terminal runtime environment or your IDE is still pointing to an older Java runtime, the build engine throws an immediate exception during the semantic analysis phase.

The Version Decoder Cheat Sheet

Java’s compiler doesn't map version numbers logically to their public marketing names. When the Gradle stack trace throws a decimal number at you, use this index to figure out what version your code is demanding:

Class file major version 66.0 = Requires Java 22
Class file major version 65.0 = Requires Java 21 (Common in newer 2025/2026 native modules)
Class file major version 61.0 = Requires Java 17 (The baseline standard for modern React Native)
Class file major version 55.0 = Requires Java 11 (Legacy)

If your terminal says wrong version 65.0, should be 61.0, your build script encountered a dependency compiled for JDK 21, but your system is executing the build toolchain using JDK 17.

Step 1: Find the Exact Path to Your Target JDK

Before making adjustments, you need to locate where the correct JDK version is actually installed on your machine.

On macOS

If you use Homebrew or standard installers, your JDK runtimes are stored under the virtual machine path. You can list all installed environments by running:
/usr/libexec/java_home -V

Copy the path to the required version. It will look similar to this:
/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

On Windows

By default, standard Java installers or Android Studio bundle their JDK environments inside program directories. Check these common locations:

C:\Program Files\Java\jdk-17\
C:\Program Files\Android\Android Studio\jbr\ (Android Studio's embedded Java runtime)

Step 2: Apply the Explicit Project Override (Recommended)

Instead of fighting global system environment variables that might break older projects on your machine, you can force this specific React Native project to use the correct runtime directory.

Navigate to your project's native android folder: cd android
Open the gradle.properties file.
Add the following property at the bottom, supplying the absolute path you copied in Step 1:

org.gradle.java.home=/Insert/Your/Actual/Target/JDK/Path/Here

(Note: Windows users must escape backslashes in this file, format it like: C:\\Program Files\\Java\\jdk-17)

Step 3: Align Android Studio with Your Terminal

A massive source of frustration is when the project builds fine in the terminal via CLI, but crashes the second you open it in Android Studio (or vice versa). You must align the IDE's build path:

Open your project folder inside Android Studio.
Navigate to Settings (or Preferences on macOS) > Build, Execution, Deployment > Build Tools > Gradle.
Locate the Gradle JDK dropdown menu.
Change it from the default system runtime to match the exact version your project requires (e.g., JDK 17 or JDK 21).
Click Apply and hit Sync Project with Gradle Files.

Step 4: Clear the Aggressive Build Cache

Gradle caches compilation footprints deeply. If you change your Java version without clearing the cache, Gradle will try to read the old, mismatched class files and throw the same error again.

Wipe the execution deck completely by running these commands in your root directory:

Clean the native android directories

cd android
./gradlew clean

Return to root and clear bundler caches

cd ..
npx react-native start --clear

Once the development server reboots and paths match up seamlessly across your terminal, properties file, and IDE, run your run command (npx react-native run-android or npx expo run:android) and the version mismatch error will be gone.

DEV Community: Asta Silva

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

Why this error happens

The most common causes

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

2. An outdated React Native package

3. Expo SDK upgrades

4. Mixing manual native configuration with Expo-managed dependencies

How to fix it

Step 1 — Read the duplicated class carefully

Step 2 — Find who is importing it

Step 3 — Update outdated packages

Step 4 — Clean the project

Step 5 — Regenerate native files (Expo)

Step 6 — Force dependency versions (only if necessary)

How to avoid this error in the future

When the error isn't actually the problem

How FixMyError can help

Final thoughts

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

What Is Actually Happening?

Why Reinstalling Dependencies Doesn't Help

When You'll Usually See This Error

The Fix

Step 1: Clear Metro's Cache

Step 2: Rebuild the Native Client

Step 3: Rebuild Your Development Build (EAS)

Why This Fix Works

A Quick Note on Debugging

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

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

The Root Cause

Before You Change Anything

The Fix: Use patch-package

Step 1: Find the Package Name

Step 2: Add the Missing Namespace

Step 3: Generate a Patch

Step 4: Apply the Patch Automatically

That's It

How to Fix Apple Silicon CocoaPods Errors Without Messy Terminal Aliases

The Crash

Why the Common Internet Advice is a Trap

The Fix: Resolving the Conflict Natively

Step 1: Purge the Broken System Gems

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

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

Step 4: Clear the Local State and Install Natively

Fixing "JavaScript heap out of memory" during production builds

Plaintext

Why This Happens

The Fix: Increase max-old-space-size

Common allocation values

1. Temporary Local Environment Fix

Bash

2. Permanent Project Fix (package.json)

JSON

Fixing the Error in CI/CD Pipelines

GitHub Actions

YAML

Docker Containers

Dockerfile

Managed Hosting (Vercel, Netlify, Cloudflare Pages)

Checking for Underlying Problems

Disable Source Maps in Production

JavaScript

Audit Circular Dependencies

Bash

Inspect the Runtime Heap

Bash

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

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

Why the Mismatch Happens

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

Implementation Steps

Solution 2: Bypass EAS and Route Tokens on Your Backend

Implementation Steps

Tag Tokens by Environment

Handle Routing on Your Server

Verification Checklist Before Your Next Build

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

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

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

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

1. The Missing Privacy Keys String (`Info.plist`)