In a real app
In an up-to-date React Native project, ls ios/Pods shows .xcframework bundles for React Native, its third-party dependencies (boost, folly, glog, fmt), and Hermes; RCT_USE_PREBUILT_RNCORE=0 bundle exec pod install forces a return to source, useful for debugging inside core or applying a patch. With SwiftPM, the same XCFrameworks are consumed, plus two header-only bundles (ReactNativeHeaders, ReactNativeDependenciesHeaders) introduced in 0.87.
Typical errors show up at link time: “building for iOS Simulator, but linking in object file built for iOS” means a binary without an arm64 simulator slice, common with an old third-party SDK; the fix is an updated SDK, not the EXCLUDED_ARCHS=arm64 workaround that condemns you to a Rosetta simulator. A publisher-signed XCFramework can also fail signature verification if Xcode is configured to require it.
For an in-house library shipped as a binary, the question to ask is version compatibility: a Swift XCFramework built without library evolution (BUILD_LIBRARY_FOR_DISTRIBUTION) only works with the exact compiler version that produced it, and an XCFramework compiled against one React Native version does not necessarily link with the next. That is why core binaries are published per exact version and downloaded from the React Native Maven mirror, with Maven Central as fallback.
Related terms
Prebuilt (precompiled React Native)
React Native core shipped as precompiled binaries (iOS XCFrameworks, Android AARs) downloaded at build time instead of rebuilt from source.
Swift Package Manager (SwiftPM)
Swift’s official package manager, built into Xcode, which React Native is adopting to replace CocoaPods (experimental in 0.87 and 0.88).
CocoaPods
React Native’s historical iOS dependency manager (Podfile, pod install, .xcworkspace), in maintenance mode and being replaced by SwiftPM.
Hermes
Meta’s JavaScript engine for React Native, the default since 0.70, which precompiles the bundle to bytecode at build time.