Cut Android build times by 2.8x with one config flag in Expo SDK 56

How to Cut Android Build Times in Expo SDK 56 by 2.8x with One Config Flag

Seventeen minutes. That’s how long the Android CMake compile step can take on a large Expo React Native app, according to Expo’s own SDK 56 benchmark. That’s not “build and test quickly” territory — that’s “finish a coffee and forget your train of thought” territory. Expo SDK 56 changes this equation with a single configuration line. Their newly released android.usePrecompiledHeaders: true flag, added via expo-build-properties, shrinks the compile time for this CMake-heavy step from 17 minutes to just over 6 — a 2.81× improvement, with no code changes or tooling to learn. This is what a real build optimization looks like: one flag, massive time savings. If Android build times ever blocked your feedback loop, let's make that a memory.

What causes long Android build times in Expo SDK 56?

Android builds in Expo SDK 56 drag primarily because of heavy C++ compilation. In large React Native projects, especially those with multiple native dependencies, the :app:buildCMakeDebug task is where time vanishes. This job can occupy the bulk of your CI or local build, especially during cold builds — the builds that run on a clean slate, like a fresh CI job or after a full clean, with no prior cache to use.

Why does this step hurt so much? Each native dependency and every C++ source file needs to be compiled and linked. React Native and Expo both depend on several native modules, some of which are large or have their own CMake projects wired in. When these aren’t cached — the case for most continuous integration setups — build systems like Gradle and CMake start from scratch, increasing wall-clock time.

According to Expo's benchmark (which tested the new SDK 56 flag in a real-world CI scenario), this single CMake step ran for 17 minutes without optimization. If your build times feel interminable, you’re not alone: this is the baseline the new flag addresses.

What is the one config flag that cuts build times by 2.8x in Expo SDK 56?

The flag is called android.usePrecompiledHeaders. Turning it on is as easy as adding a single line to your Expo config via expo-build-properties. In Expo’s own CI benchmark on SDK 56, adding this flag dropped the :app:buildCMakeDebug task from 17 minutes to 6 minutes 6 seconds — that’s a 2.81× speedup for the slowest part of the Android build. No code changes or external tools required.

The difference is real:

• 17:00 → 6:06 (2.81x faster) on a large app in Expo’s benchmark

Here is the relevant config snippet:

// app.json (via expo-build-properties config plugin)
"expo-build-properties": {
  "android": {
    "usePrecompiledHeaders": true
  }
}

Once you set this, trigger a prebuild, then start your Android build as usual. The flagship advantage: it works out of the box in SDK 56, and you don’t need to touch any native code or Gradle internals. If you maintain a large React Native/Expo app and see Android builds dominating CI time, this is your best first lever.

How does this config flag work under the hood?

android.usePrecompiledHeaders flips a build system optimization for native C++ compilation on Android. Normally, each compilation unit (translation unit in CMake-speak) processes all its C++ headers separately. This redundancy wastes CPU and IO, especially when your app and dependencies share a heavy set of includes (typical in React Native and Expo projects).

With precompiled headers, the build system compiles commonly used headers once, producing a compact PCH file. Subsequent C++ files reference this, massively reducing repeated header parsing and compilation. The effect compounds in big projects: each native dependency with its own C++ code benefits, especially when many share the same bulky headers.

When enabled via expo-build-properties in SDK 56, this flag asks the underlying Gradle and CMake integration to auto-generate and use precompiled headers as supported. There’s no manual PCH management — the system infers which headers are best to precompile. While the change is “under the hood,” for cold builds (like those on CI), the difference is visible in reduced wall-clock time for the :app:buildCMakeDebug step.

Requirements:

• Expo SDK 56 or newer
• The latest expo-build-properties plugin installed and configured
• Minimum build tooling as specified in Expo’s official release notes

How do I apply this config flag in my Expo Android project?

The actual implementation is direct. Here’s how to get the full speedup:

1. Verify you’re on SDK 56 or newer.
   Check your package.json and ensure expo is at version 56.x.x or greater.

2. Install/upsert expo-build-properties.
   If you haven’t already:

   npx expo install expo-build-properties

3. Add the config flag.
   In your app.json or app.config.js (whichever you use), add this block:

   "expo-build-properties": {
     "android": {
       "usePrecompiledHeaders": true
     }
   }

   If the block or plugin already exists, just add the flag to the existing android section.

4. Re-run prebuild if needed.
   If your project is managed, run:

   npx expo prebuild

   If you're already using bare workflow, the plugin handles the change as part of the next build.

5. Build your app.
   For CI, trigger a clean cold build. Locally:

   npx expo run:android
   # or for production
   npx eas build -p android

6. Benchmark the impact.
   Use a fresh build (with caches wiped) to see the time delta. In CI, compare the before/after wall-clock times for :app:buildCMakeDebug.

Troubleshooting tips:

• The largest gains come during cold (fully clean) builds — expect smaller deltas if most builds are incremental/local.
• If you see build failures, verify expo-build-properties is up to date and compatible with SDK 56.
• Some environments may require clearing Gradle/CMake caches to get an apples-to-apples comparison.

Verification:
Watch the CI logs or local terminal for the time spent on :app:buildCMakeDebug before and after. Only the C++ step sees the biggest drop; don’t expect your total build to be 2.8x faster unless CMake was previously the majority of time.

Are there any trade-offs or limitations to using this flag?

The headline "2.8x" speedup is real, but applies most to large, dependency-rich apps on a cold CI build. If your app has few native dependencies, you may only see about a 1.3x improvement. For warm builds (where most outputs are cached), the savings shrink further.

Additional caveats:

• Only the CMake/C++ step accelerates. The flag does not impact JS/Metro bundling, assets, or other Gradle steps.
• Experimental status. Expo currently labels the feature as experimental. While Expo's benchmarks show no regressions, monitor your own for edge-case failures.
• CI environments shine. Local, incremental builds are already faster thanks to cache layers. This flag's biggest punch comes on CI where cold builds are the norm.
• Compatibility: Only available in SDK 56+, and only through expo-build-properties configured as above. If your project diverges from standard Expo templates, validate before rolling out at scale.

Reverting:
If you encounter incompatibilities, simply flip the flag back:

"expo-build-properties": {
  "android": {
    "usePrecompiledHeaders": false
  }
}

Monitor build times and CI stability after any change.

What are other ways to reduce Android build times with Expo and React Native?

While the android.usePrecompiledHeaders flag targets native build hot spots, there are other tactics every Expo developer should have in their toolbox:

• Incremental builds and caching: Use CI runners with persistent storage — services like GitHub Actions can cache ~/.gradle and node_modules.
• Metro bundler tweaks: Disable source maps or minification during development for faster JS bundling.
• Hermes JS engine: For release builds, enabling Hermes shrinks JS runtime and can slightly reduce bundle build time (but not native compilation).
• Modularizing dependencies: Prune unused native modules; every extra C++ dependency costs compile minutes.
• React Native and Expo upgrades: Stay current — every major Expo/React Native release brings build optimizations under the hood.
• Use managed workflow when possible: Managed Expo workflows abstract many native build pains, letting Expo’s infrastructure optimize regularly.

For deeper dives, see OTF’s guides on optimizing React Native build times, best practices for development vs production Expo builds, and configuring Metro and caching.

Cut your feedback loop by two thirds

One config line. That’s all it takes to drop Android build time for Expo projects from a frustrating 17 minutes to just over 6 — a 2.8x cut where it matters most. If your team waits on cold builds or watches CI pipelines eat into shipping time, android.usePrecompiledHeaders: true in SDK 56 isn’t just a new setting: it’s your shortcut to faster iteration. Ship it in your Expo config, measure your own before/after, and take back the minutes you’ve been burning on arbitrary waits — your focus (and your coffee break) will thank you.