Next.js build fails on Termux because @next/swc-android-arm64 is not a usable native binary in that environment.

If your project installs successfully but next build or even next dev crashes on Android via Termux, the problem usually is not your app code. The failure happens because Next.js tries to load a platform-specific SWC native package, and Android-on-Termux is a special runtime that often does not match the binary assumptions made by the published package.

Understanding the Root Cause

Next.js uses SWC, a high-performance compiler written in Rust, for transpilation, minification, and core build tasks. To make this fast, Next distributes precompiled native binaries such as @next/swc-linux-x64-gnu, @next/swc-darwin-arm64, and in this case @next/swc-android-arm64.

The issue appears when Next.js detects an Android ARM64 environment and attempts to load @next/swc-android-arm64. On Termux, that binary may still fail for one of several technical reasons:

• The package was compiled against a different expected C runtime or system ABI than what Termux provides.
• Termux does not behave exactly like a conventional Linux distribution, even if many tools look similar.
• The native binary may depend on linker behavior or shared libraries that are unavailable or incompatible in your Android userspace.
• Some Next.js versions and package manager combinations do not gracefully recover when the optional native dependency exists but cannot actually execute.

In short, the bug is a native runtime compatibility problem, not a React or application logic problem. The build breaks because the SWC binary cannot be loaded or executed correctly inside Termux.

This is also why the downloaded tarball itself is not enough proof that the package should work. A package can install correctly and still fail at runtime when Node tries to require the native binding.

Step-by-Step Solution

The most reliable fix is to avoid building a production Next.js app directly in Termux when your installed Next version expects a native Android SWC binary that does not work there. Use one of the solutions below, starting with the safest option.

Option 1: Build in a supported Linux environment

This is the best long-term fix. Build your app in a standard environment such as GitHub Actions, Docker, WSL, or a regular Linux server instead of Android Termux.

node -v
npm -v
npx next info

If you are using deployment automation, move the build step to CI/CD:

npm ci
npm run build

Why this works: Next.js officially behaves much more predictably on standard Linux targets where the correct SWC native binary is available.

Option 2: Force a WebAssembly fallback where possible

Some setups can work better by using the WASM version of SWC rather than the native Android binary. This is slower, but it avoids native loading issues.

First, remove cached modules and lockfile artifacts:

rm -rf node_modules .next
rm -f package-lock.json yarn.lock pnpm-lock.yaml

Then reinstall dependencies:

npm install

If your version of Next.js still insists on loading the Android native package, explicitly testing with an older or newer Next.js patch release is often necessary:

npm install next@latest react@latest react-dom@latest

Or pin to a known working release in your project if a regression was introduced:

npm install next@14.2.7 react react-dom

The exact working version can vary, so compare behavior between nearby patch versions.

Option 3: Prevent stale or broken optional binary resolution

Sometimes the wrong optional package remains in your dependency tree. Clean install everything and verify what got installed:

npm ls @next/swc-android-arm64
npm ls next

For Yarn:

yarn why @next/swc-android-arm64
yarn why next

If the binary is present but broken, remove dependencies and reinstall cleanly:

rm -rf node_modules .next
yarn cache clean
yarn install

If you use pnpm:

rm -rf node_modules .next
pnpm store prune
pnpm install

Option 4: Use a container or remote builder from Android

If Termux is your main device, keep editing there but offload builds to a proper Linux runtime. For example, push to a Git repository and let a CI system build the app, or connect to a remote VM.

Useful targets include GitHub Actions, Docker, or a cloud VM. This preserves your Android workflow without depending on an unsupported local native binary.

Option 5: Confirm Termux architecture and package toolchain

Before assuming the issue is purely in Next.js, verify your environment:

uname -a
arch
node -p "process.platform + ' ' + process.arch"
termux-info

You want to confirm that Node reports android arm64 and that your installed Node version is modern enough for your Next.js release.

Also upgrade Termux packages:

pkg update
pkg upgrade
pkg install nodejs-lts

Then reinstall dependencies again:

rm -rf node_modules .next
npm install
npm run build

Recommended practical fix

If you need a stable answer fast, use this sequence:

rm -rf node_modules .next
rm -f package-lock.json yarn.lock pnpm-lock.yaml
pkg update && pkg upgrade
pkg install nodejs-lts
npm install
npx next info
npm run build

If it still fails on @next/swc-android-arm64, stop trying to produce the final build inside Termux and move the build to a supported Linux environment. That is the most dependable resolution for this issue.

Common Edge Cases

• Node version mismatch: Newer Next.js releases can fail in unexpected ways on unsupported Node versions. Check with node -v.
• Corrupted lockfile state: If you switched package managers, an old lockfile may force a bad optional dependency resolution.
• Mixed architectures: Some Android devices report ARM64, but installed tools or userland packages may not align perfectly.
• Cached native modules: Even after changing Next versions, stale node_modules content can keep loading the same broken binary.
• CI works but local Termux fails: This strongly confirms the issue is environmental, not application-level.
• Optional dependency handling differences: npm, Yarn, and pnpm do not always treat optional native packages exactly the same way.

FAQ

Why does the package install if it cannot run?

Installation only means the tarball was downloaded and extracted. Native packages can still fail later when Node attempts to load the compiled binding on your actual runtime.

Can I safely ignore @next/swc-android-arm64 errors?

No. If Next.js cannot load a working compiler backend, your build pipeline is incomplete. You need either a functioning native binary or a supported fallback.

Is this a Next.js bug or a Termux limitation?

It can be both. From a user perspective, the bug surfaces in Next.js package resolution for Android ARM64. Technically, it is usually triggered by the gap between prebuilt native binary expectations and the real Termux Android runtime.

If you want the most reliable production workflow, develop on Termux if needed, but run Next.js builds on standard Linux or CI. That avoids the unstable path involving @next/swc-android-arm64 altogether.