概要
公開日: 2026-06-11
翻訳生成に失敗したため、原文をそのまま保存しています。
原文
Expo SDK 56 introduces support for precompiled Expo modules on iOS using XCFrameworks. This significantly reduces native build overhead for many projects. Precompiled XCFrameworks are enabled by default both locally and on EAS Build, with no configuration required. Behind the scenes, this is also the beginning of a much larger transition in the Expo ecosystem: moving away from CocoaPods and toward Swift Package Manager (Swift PM), Apple’s modern system for dependency management and native builds. This post dives into: - Why we’re making this transition - How precompiled Expo modules work - The architectural challenges involved - And what this unlocks for the future of Expo on iOS Faster builds without changing your app Historically, every Expo and React Native library on iOS has been compiled from source inside your app project. That means every local build and every EAS Build recompiles all of these items from scratch: - React Native - Expo modules - 3rd party libraries with native code Precompiled XCFrameworks in SDK 56 changes that. Many Expo modules are now distributed as precompiled XCFrameworks through npm and can be linked directly instead of being rebuilt during every app compilation. In practice, this means that we’ll have fewer native compilation steps, faster local iteration, faster EAS Builds, and more reproducible native build environments. The best part is that this happens automatically. No migration steps are required. 💡 What are XCFrameworks? An XCFramework is Apple’s format for distributing precompiled native libraries. Instead of shipping source code that every app compiles locally, a framework can be distributed as a binary artifact already compiled for: iOS devices, simulators, and multiple architectures. Each XCFramework contains independent framework “slices” for specific platforms and architectures. React Native already uses XCFrameworks internally, and Expo SDK 56 extends this model into the Expo ecosystem. Why precompiled XCFrameworks matter This work solves two major long-term problems in the React Native ecosystem. 1. CocoaPods is becoming legacy infrastructure Expo, React Native, and most React Native libraries currently rely heavily on CocoaPods. CocoaPods has historically handled dependency resolution, native autolinking, project integration, and build orchestration. But it’s an older Ruby-based system that will be deprecated eventually and will become read-only in December 2026. Swift Package Manager has become Apple’s standard tooling for native dependencies, builds, package distribution and build extensibility. React Native itself has already started moving toward SPM support internally, including distributing parts of React Native as precompiled XCFrameworks. Expo SDK 56 builds on that direction. 2. Native builds are expensive As apps grow larger, native build times continue to increase. This is especially noticeable in CI environments, in EAS Build, and in large monorepos with many native dependencies. Precompiled XCFrameworks let us move much of that work earlier in the pipeline. Frameworks are compiled once, packaged, and then reused across builds. This dramatically reduces repeated native compilation work. Why this is harder than it sounds React Native and Expo were originally built around CocoaPods and source-based compilation. That environment is extremely permissive: headers are globally available, source files can import almost anything, pod targets have loose isolation, and modular boundaries are blurry. XCFrameworks impose much stricter rules. Every framework must be: fully modular, self-contained, and isolated from implementation details outside its module boundary. Many assumptions that work perfectly in CocoaPods simply break when building distributable XCFrameworks. Rewriting the entire native architecture from scratch wasn’t realistic, so we focused on incremental compatibility layers and build infrastructure instead. Build time impact The following numbers were measured on an