Measurements from 19–20 October 2026 on one Windows 11 PC; framework facts checked against Expo's SDK 57 template.

There is no error message here. The symptom is a release build that just takes long. On our own machine (8 cores, 31.6 GB RAM, NVMe disk, Windows Defender real-time protection on), Gradle alone took 28 min 40 s on a real app, and the whole bundle command, including a password sweep, took 2,244 s. A small test app took 665 to 864 s depending on the night. Here is where the time goes, what we tried, and the one thing that made a clear difference.

We tried six ideas. Four didn't pay off, and we say so below with the numbers.

Where the time goes

A release build compiles the native code of your app and of every native module for each CPU architecture. The Expo SDK 57 template builds four of them by default: 

reactNativeArchitectures=armeabi-v7a,arm64-v8a,x86,x86_64

On a real app (FoosArena, with reanimated and worklets) the Gradle profile of an arm64-v8a/armeabi-v7a build showed CMake as the dominant cost. That run's total time is one we discarded (see the cautions below), so take the split as indicative: about 1,820 s of task work in total, :app:buildCMakeRelWithDebInfo alone 596 s for armeabi-v7a and 347 s for arm64-v8a. Two more fixed costs show up on every run on this machine:

  • Gradle's own start-up, 1.5 to 2.5 minutes, even when the Gradle distribution is already on disk.
  • Windows Defender, which scans freshly written files the first time they're read. In our password sweep, the first read of freshly written files cost about ten times more than a read with a warm cache. We did not measure the effect of excluding the build folder from scanning, because that needs an administrator's decision.

What we tried, in order of payoff

1. Build fewer architectures: yes

The Expo template says you can override the list from the command line: 

cd android
.\gradlew.bat app:bundleRelease -PreactNativeArchitectures=arm64-v8a,armeabi-v7a

That is the manual recipe. Two things to know: the 64-bit arm64-v8a has to stay in the list, and dropping x86 and x86_64 means the bundle no longer contains the architectures used by the Android emulator on a PC and by x86 ChromeOS devices. WinBuild's verify requires arm64-v8a in the result.

What it bought us:

  • FoosArena: --abi store (the same two architectures) took the bundle command from 2,244 s to 1,428 s, 36% less. Both runs included the password sweep. They were measured on different nights and the app source was at different commits, so read it as one data point, not a benchmark.
  • Test app: 2 architectures took 427 s against 665–823 s for 4. Repeated on a second night, 2 architectures took 730 s against 864 s for 4, 16% less; averaged with the first run, 578 s, which is 30% under the 823 s median for 4. The gain is real but noisy.

2. Reuse downloaded dependencies: not worth it for us

Pointing Gradle at a read-only copy of a previous run's dependency cache (GRADLE_RO_DEP_CACHE) meant 0 bytes downloaded. The time saved, across three runs: median −7% (766 s against 823 s). Our threshold to build it was 20% or 3 minutes, so we postponed it. On a slow connection it would count more. Ours isn't slow.

3. Gradle's parallel mode: no

--parallel with 8 workers: one run failed after 424 s with a compilation error that didn't repeat, two ran clean and were no faster than the baseline (863 s and 824 s against 864 s). The bottleneck here is CMake and the disk, not the number of workers. We dropped the idea. (Expo's own template sets org.gradle.parallel=true, so you probably have it on already.)

4. Combining the three: nothing extra

Dependencies in a read-only cache plus 2 architectures plus parallel took 420 s, the same as 2 architectures alone (427 s).

5. Excluding the build folder from Defender: not measured

This is the idea we most want to test, and the one we haven't. It needs an administrator to change a Windows security setting on purpose, and it has a cost: Gradle plugin code would run in a folder that isn't scanned. WinBuild never changes it; doctor --perf only reports whether the folder is under real-time scan, and a guide explains the trade-off.

6. Make the other steps cheaper

The 20 October rewrite of WinBuild's password sweep (list the files first, then read them with 4 workers) took the scan of 39,615 files from 61.4 s to 21.3 s with a warm disk cache. Right after a build it's slower: 282 s for 39,920 files. In the 1,428 s FoosArena run, about 9.5 of the 23.8 minutes of the bundle command were the sweep of the older version.

Two cautions before you trust any number

  • Variance is big. The same configuration gave 665, 823 and 864 s on three nights. Our night runs overlapped with Windows maintenance (03:04–03:20) and a quick Defender scan (04:24–04:31). The first --abi store run on FoosArena took 3,541 s because Docker Desktop and WSL were running for another job. We discarded it as a measurement. Nothing else should run when you time a build.
  • One machine, one real app. Results on yours will differ, particularly the size of the Defender share.

How WinBuild handles it

WinBuild doesn't make Gradle faster. It makes the choices above explicit and measurable:

  • bundle --abi store builds arm64-v8a and armeabi-v7a; --abi also takes a list from arm64-v8a, armeabi-v7a, x86, x86_64. Nothing in your project files is changed: the list goes to Gradle as -PreactNativeArchitectures. verify checks that the AAB contains exactly the requested architectures.
  • bundle --gradle-profile writes Gradle's HTML profile locally, and the workspace metadata records the time of each phase, so you can see where your minutes go instead of guessing. doctor --perf lists cores, RAM, disk type, file system and whether Defender real-time protection is on.
  • Daemon off, 4 workers at most, a fresh Gradle home for each attempt. That costs start-up time (see above). The reason is isolation: a running daemon would keep the signing passwords in memory between attempts.

Sources

External sources consulted on 20 October 2026. Figures about WinBuild come from our own build records.

Private alpha

Building Expo Android releases on Windows?

WinBuild is in private alpha. Testers get the package directly and help validate different machines and Expo projects.

Request alpha access →No checkout yet · direct founder feedback

← All articles