Setting the file. One moment.
Subchapter 11.6
references/version-compatibility.mdMarkdown4 KBView on GitHub
Keep the workflow version-aware rather than pinning every host to one SDK. Existing projects retain their SDK unless an upgrade is part of the task. New producers should use the current stable Expo release when the host and toolchain can support it.
package.json and lockfile; record resolved expo, react-native, and expo-brownfield versions. Check the host’s deployment targets, Xcode/Node versions, and native dependency graph, including any existing RN runtime.npm view expo dist-tags --json can confirm the current stable latest version. Do not infer stability from the highest SDK number or select canary/next by default.sdk-<major> native template. Install modules with npx expo install; run npx expo install --check before native builds. For an SDK upgrade, use expo-upgrade, preserve the host, and apply native diffs selectively.build:ios --help / build:android --help, plugin schema, generated Swift/Kotlin wrappers, and Package.swift. Flags, prebuilt defaults, import names, and binary products can change within a major release.To scaffold a small new feature after those checks:
npx create-expo-app@latest my-project --template blank@latest
cd my-project
npx expo install expo-brownfield typescript @types/reactThis avoids adding a Router shell just to export one component. For an existing Router app, preserve it and add the root-props adapter described in feature integration. If selecting an older SDK, use a verified template tag such as blank@sdk-55; the scaffolder’s own @latest version does not determine the template’s SDK. Commit the producer’s lockfile for repeatable builds.
| Surface | SDK 55 | SDK 57 |
|---|---|---|
| React Native family | 0.83 | 0.86 |
| iOS minimum in the Expo template | 15.1 | 16.4 |
| Documented minimum Node / Xcode | 20.19.x / 26.2 | 22.13.x / 26.4 |
| Brownfield React Native build default | Source | Prebuilt |
| Precompiled Expo modules | Version/configuration dependent | Enabled by default in the native template |
| Swift Package products | 55.0.28: separate feature and Hermes products | 57.0.18: one aggregate product when precompiled modules are detected; otherwise separate products |
React Native prebuilt binaries and precompiled Expo modules are separate settings. Set React Native source mode on expo-brownfield‘s ios.buildReactNativeFromSource. Expo module precompilation is controlled by expo-build-properties‘ ios.usePrecompiledModules. Do not disable defaults as a generic build fix; first inspect the failing dependency and toolchain requirement.
In 57.0.18, precompiled builds suffix the generated package/product with its configuration (MyAppPackage-release or MyAppPackage-debug). They do not rename the generated Swift module: continue to import the configured target, such as MyBrownfield. Inspect the emitted manifest instead of constructing an assumed package path.
SDK 56 introduced additional brownfield capabilities carried into SDK 57, including experimental multiple isolated frameworks and registering host Turbo Module classes. Load the selected SDK’s API and installed interfaces only when the task needs them. Do not enable experimental multi-framework support for a single feature or assume two independently packaged RN runtimes can be linked together without collision handling.
Sources: SDK requirements (opens in a new tab), SDK 57 Brownfield API (opens in a new tab), SDK 57 native template (opens in a new tab), SDK 56 brownfield additions (opens in a new tab), published Brownfield package (opens in a new tab).