Precompiled React Native for iOS: Faster builds are coming in 0.81

Building for iOS is about to get dramatically faster. In React Native 0.81, Expo and Meta are introducing precompiled React Native builds for iOS — cutting down your compile times by up to 10x in apps with few other dependencies.

Compiling the React Native library and its dependencies has always been a significant contributor to build time. This problem was solved years ago on React Native for Android by using a precompiled version of the library by default, and providing the option for developers to build from source when needed. But what about iOS?

In React Native 0.81, you will also be able to use a precompiled version of React Native and its dependencies for iOS. This was made possible thanks to a collaboration between Expo and Meta — Riccardo Cipolleschi and Christian Falch have worked on this project since January, and we’re excited for it to ship in React Native 0.81 / Expo SDK 54. In the rest of the post, Christian will explain how this is built and how it works, how you might follow the same approach in your libraries, and what’s next.

The most important benefit with using precompiled packages is the reduced build time that every React Native developer will experience. Rather than every developer compiling React Native on every clean build, React Native will be compiled once for each release. You can compile it from source if you want to modify the internals. So we’ll be saving a lot of compile time on all computers - reducing the power consumption and making your batteries last longer - and even make our environment a little bit greener. We’ve found that this reduced clean build times for RNTester from about 120 seconds to 10 seconds (on an M4 Max — exact numbers will vary depending on your machine specs). While you’re unlikely to see a ~10x built time improvement in your app due to the number of other dependencies in most apps that will still need to be compiled, we expect there to be a noticeable improvement in build times in large projects and an even more pronounced improvement in smaller projects where React Native is responsible for a greater share of the build time.

We also expect this to make it easier to integrate with brownfield apps. Adding the react-native dependency to a large native project with a long build time was a bit painful — we’ve heard that introducing the package along with its dependencies into the build pipeline on brownfields project was not always very welcomed by engineers working elsewhere on these codebases.

Lastly, this work is necessary to prepare for the future deprecation of CocoaPods and migration to Swift Package Manager (SPM). CocoaPods is slowly moving towards closing the doors to new podspecs on December 2, 2026, and so React Native will be moving to SPM. Learn more about the plan.

The first step was precompiling React Native’s dependencies, followed by React Native itself.

First of all we created a simple JavaScript build system for the React Native third-party dependencies, so that these could be built by the CI build servers. The resulting ReactNativeDependencies.xcframework is built using a generated Swift package and then compiled to an XCFramework with architectures for iOS, MacOS, Mac-catalyst, tvOS and VisionOS (including simulator for all supported platforms). We also add any resources like privacy bundles to the package before compiling to satisfy the AppStore review guidelines.

Setting up the React Native precompiled XCFramework pipeline was mainly a repeat of how we created the dependencies precompiled, except that we now had the code spread in more than 50 CocoaPods podspec files with slightly different setup needed some massaging to be ready. After creating some helper functions in Ruby we were able to create a system for building with/without precompiled binaries on iOS through a huge Swift package that builds all the required archives (React Native is precompiled for iOS, iOS-simulator and Mac-Catalyst (for running iOS on MacOS).

We created some helper functions and classes in Swift to make it easier to set up and build the React Native Swift Package - it required a precise and accurate setup to make sure all headers were correctly set up. We even had to create a preparation script that recreated parts of the React Native Podfile header structure (in an installed application) to avoid having to change any includes in any source files!

The XCFrameworks for both the dependencies bundle and React Native itself are built on a nightly basis and released together with React Native itself. The binaries are hosted and downloaded from a Maven repository to your local React Native installation. React Native will continue to support building from source, because this makes it easier to develop and debug libraries. The solution we’ve created now is an opt-in (that will become default in the near future) making it easy to continue to build from source and make changes inline.

One of the benefits from creating the ReactNativeDependencies Swift Package was that we have now removed the need for configuring Folly in each and every podspec file that uses it. This is done by leveraging Folly’s optional configuration file that we’ve now added to both the installation and the precompiled version of Folly (if you know it, you know it!)

The following are two examples of build times we’ve recorded on apps that we commonly build to give you an idea of what you can expect.

Expo Go: Before and after using precompiled React Native

RNTester: Before and after using precompiled React Native

Enabling precompiled binaries for React Native is a huge step forward for developers. There will no longer be a need for every developer to build the same code day in and day out. Moving forward, we expect to be able to precompile our Expo Modules and React Native Community libraries on iOS, which will reduce build-times to a thing of the past.

If you have been around this space for a while, you may be asking yourself — “Wait, didn’t they used to ship precompiled Expo Modules for iOS? What happened to that?” This isn’t the Mandela effect, you are correct. We did, and then didn’t. We expect that the work done to precompile React Native and its libraries will unblock us from precompiling Expo Modules again in the near future. We will start using Swift packages with CocoaPods, before eventually converting exclusively to Swift packages when CocoaPods is deprecated.

We’ll always continue to support building from source, likely with the same buildFromSource API that Expo Modules supports for Android.

If you are a library author, you may soon need to start thinking about this since CocoaPods will be deprecated and removed from React Native (discussions-and-proposals#587). Before this happens, we’ll be providing a clear migration path for Expo and React Native libraries that will include using Swift packages for distribution. This will be a great opportunity for all our library developers to freshen up and simplify their build pipelines!

You can also chose to continue to distribute your library as source code, but expect that your users will start to demand precompiled binaries when they see the benefits in compilation speed.

In React Native 0.80, you can opt in to using a precompiled XCFramework for React Native’s iOS dependencies, such as GLog and Folly (learn more).

In React Native 0.81, you will also be able to use a precompiled version of React Native and its dependencies for iOS. You can try this in React Native 0.81 (in "rc" at the time of writing):

Using precompiled binaries is currently an opt-in, and is enabled by passing the correct environment variables when running pod-install:

RCT_USE_PREBUILT_RNCORE=1 RCT_USE_RN_DEP=1 bundle exec pod-install

We intend to make using the precompiled library and dependencies the default in SDK 54 (coming in late August or early September), which will use React Native 0.81.