Expo SDK 55 Brownfield support

Expo just made a very specific promise to native iPhone teams: you can drop an Expo-built screen into an existing iOS app without turning your whole build system into a JavaScript project. In Expo software development kit 55, the new brownfield workflow packages an Expo app as a native dependency instead of making the host app build React Native itself. (expo.dev) That solves a problem that has slowed React Native adoption for years. A company with a large Swift or Objective-C iPhone app usually does not want to rebuild its native pipeline around Node.js, Yarn, and JavaScript bundling just to ship one cross-platform feature. (expo.dev) The industry name for this setup is “brownfield.” It means adding a new technology to an app that already exists in production, instead of starting from scratch with a “greenfield” app where the whole architecture is chosen on day one. (expo.dev) In a greenfield Expo app, React Native is usually the center of the project. In a brownfield app, the native iPhone app stays in charge, and the React Native or Expo part shows up as one feature area, one screen, or one embedded view inside the larger product. (expo.dev) Expo’s new approach is called “isolated” brownfield integration. The React Native code is developed separately, then packaged as an XCFramework on iPhone or an Android Archive library on Android, and the native app consumes that package like any other prebuilt dependency. (docs.expo.dev) That packaging detail is the key change. Expo says native developers using the isolated workflow do not need Node.js, Yarn, or React Native build tooling on the native side, because they can consume prebuilt artifacts rather than compiling the JavaScript stack inside the host app’s build process. (docs.expo.dev) Expo shipped this in software development kit 55, which it officially released on February 25, 2026. The SDK 55 changelog says the release “improves the support for Brownfield apps” and introduces the new `expo-brownfield` package for the isolated approach. (expo.dev) The new package is more than a wrapper. Expo’s documentation says `expo-brownfield` includes a command-line interface for building and publishing Android libraries to Maven repositories and iPhone packages as XCFrameworks, plus built-in messaging APIs so the native host app and the Expo side can send data back and forth. (docs.expo.dev) That communication layer matters in real apps. A native checkout flow might need to open an Expo-built rewards screen, pass in account data, then receive a result back when the user finishes, and Expo’s brownfield toolkit includes message-based APIs for exactly that two-way handoff. (docs.expo.dev) Expo is also careful not to present this as the only route. Its documentation now describes both an “integrated” approach, where React Native is wired directly into the native project, and an “isolated” approach, where the Expo codebase stays separate and is delivered as a library. (expo.dev, docs.expo.dev, docs.expo.dev) The isolated model fits a common org chart inside larger companies. One team can build the Expo feature in a separate repository, publish a versioned artifact, and another team can add that artifact to the iPhone app without becoming responsible for JavaScript tooling, Metro bundling, or React Native internals. (docs.expo.dev, expo.dev) That is why this release is more practical than flashy. Expo is trying to make adoption feel less like “rewrite your app around a framework” and more like “add one library for one feature,” which is a much easier sentence to get approved in a company that already has millions of users on a native codebase. (expo.dev) There is still a JavaScript side somewhere in the process. Expo’s isolated-approach guide says the team creating the Expo package still needs a JavaScript development environment with Node.js and Yarn, but the native host app team can stay on the other side of that boundary and consume the finished build artifact. (docs.expo.dev) So the news is not that Expo suddenly replaced native iPhone development. The news is that, in software development kit 55, Expo gave native teams a cleaner seam: build cross-platform features with Expo on one side, ship them into an existing iPhone app as a framework dependency on the other, and leave Node.js out of the host app’s day-to-day build pipeline. (expo.dev, docs.expo.dev)