React Native developers know the pain: every clean iOS build recompiles your entire dependency tree from scratch. React Native core, Expo modules, third-party libraries — everything rebuilds, every time.
Expo SDK 56 changes this by shipping Expo modules as precompiled XCFrameworks. Your app links these binaries directly instead of rebuilding from source. Clean builds become dramatically faster with zero configuration.
This also marks the start of a bigger shift: moving the entire ecosystem from CocoaPods to Swift Package Manager, Apple's modern dependency system.
What precompiled XCFrameworks do for you
Previously, every iOS build meant compiling these items from source:
- React Native core
- All Expo modules
- Every third-party library with native code
SDK 56 distributes many Expo modules as precompiled XCFrameworks through npm. Your build process links these binaries instead of recompiling source code.
The results: fewer compilation steps, faster local development, faster EAS Builds, and more predictable build environments.
No migration needed. This works automatically in existing apps.
XCFrameworks explained: Apple's format for distributing precompiled native libraries. Instead of source code that every app compiles locally, you get binary artifacts already compiled for iOS devices, simulators, and multiple architectures. React Native already uses XCFrameworks internally — SDK 56 extends this to Expo modules.
Two problems this solves
This work addresses major long-term issues in React Native development.
CocoaPods is going away
React Native and most RN libraries currently depend on CocoaPods for dependency resolution, native autolinking, project integration, and build orchestration.
CocoaPods is Ruby-based legacy infrastructure. It becomes read-only in December 2026.
Swift Package Manager is Apple's standard tooling for native dependencies, builds, and package distribution. React Native itself has started moving toward SPM support, including distributing parts of RN as precompiled XCFrameworks.
SDK 56 continues this direction.
Native builds are expensive and slow
As apps grow, native build times increase. This hurts especially in CI environments, EAS Build, and large monorepos with many native dependencies.
Precompiled XCFrameworks move compilation work earlier in the pipeline. Frameworks get compiled once, packaged, then reused across builds. This eliminates repeated native compilation work.
Why this was technically difficult
React Native and Expo were originally built around CocoaPods and source-based compilation. That environment is permissive: headers are globally available, source files can import almost anything, pod targets have loose isolation.
XCFrameworks impose strict rules. Every framework must be fully modular, self-contained, and isolated from implementation details outside its module boundary.
Many assumptions that work in CocoaPods break when building distributable XCFrameworks.
Rewriting the native architecture from scratch wasn't realistic. We built incremental compatibility layers and new build infrastructure instead.
Build time improvements
These numbers come from an Apple M4 Max with 64 GB memory, running clean iOS builds of a stock Expo app while enabling each layer of precompiled XCFrameworks:
| Build configuration | Reduction vs previous | Reduction vs from-source |
|---|---|---|
| Everything from source | — | — |
| + React Native core | ~44% | ~44% |
| + Expo modules prebuilt | ~10% | ~50% |
| + Third-party libraries prebuilt | ~30% | ~65% |
Larger projects see benefits based on coverage: React Native and Expo modules are always precompiled, but only widely-used third-party libraries are included. Projects using uncommon native dependencies will compile those from source and see smaller reductions.
Making Expo Modules Core work with SPM
The first step was adapting expo-modules-core. Nearly every Expo module depends on it, so it sits at the root of the dependency graph. If it can't build as a modular XCFramework, nothing else can.
This required solving several architectural problems.
Removing illegal header exports
Some Expo Modules Core public headers exposed React Native headers directly:
#import <React/RCTView.h>
This works in CocoaPods because all headers are globally available during compilation. Framework interfaces don't allow this.
A framework cannot publicly expose headers from another framework unless those dependencies are themselves modularized correctly.
We solved this by refactoring public interfaces, isolating React Native internals, and restructuring APIs so non-modular dependencies don't leak into exported interfaces.
Breaking Swift ↔ Objective-C cycles
Swift Package Manager is much stricter about mixed-language targets than CocoaPods.
Expo Modules Core had cyclic dependencies where Objective-C referenced Swift types while Swift referenced Objective-C types.
SPM requires clear dependency direction between targets. We introduced new interface abstractions, separated implementation layers, and refactored internal APIs.
In some cases, we used Objective-C runtime reflection to dynamically invoke Swift implementations without illegal compile-time dependencies.
Separating source trees for SPM
Swift Package Manager is strict about source ownership. The same source file cannot belong to multiple targets in the same package graph.
Expo's repository structure wasn't designed around this assumption. Rather than permanently reorganizing repositories, we generate temporary isolated source structures during builds using symlinks, generated folders, and build-time source separation.
This preserves the existing repository layout while satisfying SPM's isolation requirements.
React Native and Virtual File System overlays
Another challenge was React Native's header structure.
React Native's current XCFramework support still depends on the legacy CocoaPods-generated header layout. That layout doesn't naturally exist in Swift Package Manager builds.
To bridge this gap, we added support for Clang Virtual File System (VFS) overlays inside React Native.
A VFS overlay lets the compiler "see" a virtual header layout different from the physical filesystem structure.
This allows us to preserve existing include paths, avoid massive source refactors, and present a modular structure to the compiler without physically reorganizing React Native's source tree.
This is common when modernizing large legacy native codebases into distributable modular frameworks.
Auto-generating Package.swift files
Swift Package Manager uses Package.swift manifests to define targets, dependencies, platforms, and build settings. Maintaining these manually across Expo packages would become difficult and error-prone.
We added new tooling to expo-tools that automatically generates Package.swift manifests, isolated source structures, dependency graphs, and XCFramework packaging steps.
This infrastructure runs fully in CI and will eventually power large-scale precompiled package distribution.
Supporting both CocoaPods and SPM
This transition takes time.
The React Native ecosystem still depends heavily on CocoaPods, and many libraries aren't yet compatible with Swift Package Manager. SDK 56 focuses on coexistence rather than replacement.
Expo modules can switch between building from source or consuming precompiled XCFrameworks.
This lets existing apps continue working while keeping CocoaPods supported as the ecosystem gradually modernizes.
If needed, precompiled modules can be disabled:
EXPO_USE_PRECOMPILED_MODULES=0
Long-term, we expect more of Expo's autolinking, native integration, and build tooling to move into Swift Package Manager itself.
Part of broader modernization
Precompiled XCFrameworks are part of broader modernization in Expo SDK 56, which also introduces inline native modules, continued React Native modernization work, and infrastructure improvements for future native tooling.
Together, these changes move Expo toward faster native builds, cleaner modular architecture, and deeper integration with Apple's modern development ecosystem.
What's next
Our current focus is stabilizing compatibility, expanding package coverage, validating build performance improvements, and continuing upstream collaboration with React Native.
This is one of the largest infrastructure migrations we've undertaken on the iOS side of Expo. But it opens up a much more scalable future for React Native development on Apple platforms: faster builds, better tooling, cleaner native boundaries, and eventually a world without CocoaPods.
SDK 56 is the beginning of that transition.
This post is based on content from the Expo blog. Follow @expo for more React Native content.
