The New Architecture stopped being a choice, and Hermes was never part of it.
React Native enabled the New Architecture by default in 0.76 and removed the off switch in 0.82. Expo followed the same line: SDK 54 is the last version where it can be disabled, and SDK 55 and later run entirely on it. Hermes is a separate thing. It is the JavaScript engine, it has been the default for longer, and you can still swap it for JavaScriptCore on either architecture. Almost every argument about this topic is two people quoting different years. If you are new to the stack, start with what React Native is and come back.
What follows is the version timeline, what Hermes is and is not, which parts of a project actually break, and the honest answer for someone who writes only JavaScript. Every version number and quote below was read from React Native's and Expo's own documentation on 10 October 2026.
Start hereIs the New Architecture the default yet, and from which version?
Yes, and the question is already out of date. React Native's documentation puts it plainly: with 0.76, the New Architecture is enabled by default in all React Native projects. Before that it was an experimental opt-in, available from 0.68, improved in every release after it. The team had been rebuilding these internals since 2018, so the default in 0.76 was the end of a long runway rather than a surprise.
The part that matters more today is the step after default. React Native 0.82 is the first version that runs entirely on the New Architecture, and starting with 0.82 the option to disable it was removed. That is the line that turns a migration you keep postponing into a migration that blocks your next upgrade. A leftover newArchEnabled setting on 0.82 and later is simply ignored, which is worth knowing because it looks like a working escape hatch in a diff and is not one.
Expo tracks the same boundary one layer up. New projects have been initialized with the New Architecture since SDK 52. Every expo-* package in the SDK has supported it, bridgeless included, since SDK 53. SDK 54 is the last SDK version where the New Architecture can be disabled, and SDK 55 and later run entirely on it, because SDK 55 uses React Native 0.83 and inherits what 0.82 did. The current release is SDK 57 on React Native 0.86, so for anyone starting a project this month there is no decision left to make.
On the versions where the switch still exists, it is two files. On Android, newArchEnabled in android/gradle.properties. On iOS, RCT_NEW_ARCH_ENABLED set to 0 in the Podfile, followed by a pod install. In an Expo project it is one newArchEnabled property in the app config instead, applied to both platforms or to one of them. None of that is useful on a current version, and that is the point.
React Native, About the New Architecture, read 10 October 2026
Check yours
Where your project actually stands
Pick the version in your package.json. Almost every argument about the New Architecture is really an argument about which of these rows the two people are on.
Mandatory, there is no switch
SDK 55 and later run entirely on the New Architecture. SDK 55 uses React Native 0.83, which inherits the behaviour 0.82 introduced. Expo Go supports nothing else.
What to do: Run expo-doctor before the upgrade, not after. A missing native view fails at runtime, not at install time.
Version boundaries read from React Native and Expo documentation on 10 October 2026.
Is Hermes part of the New Architecture or a separate thing?
Separate, and conflating them is the most common mistake on this topic. Hermes is the engine your JavaScript runs inside. React Native's Hermes guide, on the same documentation site, describes it as an open-source JavaScript engine optimized for React Native, and says it is used by default with no additional configuration required. The New Architecture is everything underneath your JavaScript: the renderer, the way native functions are called, and the build step that wires the two together.
The clearest proof that they are independent is that each can be changed without the other. React Native still supports JavaScriptCore as an engine, with the opt-out instructions published in a community repository, and that is true on current versions where the New Architecture cannot be turned off at all. The reverse held too: plenty of apps ran Hermes on the legacy architecture for years. Two switches, two different layers, and only one of them still moves.
Hermes also ships differently from how people assume. React Native comes with a bundled version of Hermes, built for each React Native release so the engine always matches the framework. The documentation calls that change fully transparent to users. If you want to confirm which engine you are on, a HermesInternal global is available in JavaScript, and the welcome view of a new app shows it too. One caveat the docs flag: the global can be present while you are still not running the precompiled bytecode, if you load your bundle in a non-standard way.
Where Hermes earns its reputation is the release build. React Native's documentation says a release build compiles JavaScript to Hermes bytecode during build time, which improves your app's startup speed on device, and that Hermes generally gives improved start-up time, lower memory use and a smaller app than JavaScriptCore. Fabric contributes from the other side, because host components are lazily initialized by default. Both land on the same number, so if you are chasing app startup time, measure a release build and not the one running off Metro.
React Native, About the New Architecture, read 10 October 2026
What actually breaks on a project that has not migrated?
Native code breaks. Your screens, your state, your navigation and your styles are not what fails. The failures come from dependencies that ship their own native views and native modules, written against the old interfaces. Since React Native 0.74 various interop layers are enabled by default, and Expo's documentation says this allows many libraries built for the old architecture to work on the New Architecture without any changes. It is equally direct about the limit: the interop is not perfect and some libraries will need to be updated, and the ones most likely to need it are those that ship or depend on third-party native code.
Two symptoms cover most of it. A build that fails on one dependency, where the fix is to read the log, find the library, and update it to its latest version before assuming it is incompatible. Or a build that succeeds and a screen that comes up empty, because a native view was never implemented for the New Architecture. The second one is worse because it passes CI. Expo's own wording for the first run after switching is that for most non-trivial apps you are likely to encounter some issues, most of them actionable.
There is a real checking tool, so guesswork is optional. Run npx expo-doctor@latest and it validates your dependencies against React Native Directory, flagging which ones are unmaintained and which are incompatible or untested with the New Architecture. You can exclude a package through a reactNativeDirectoryCheck block in package.json when you know better than the directory does. Expo also publishes a short list of swaps for libraries popular in its ecosystem: @react-native-community/masked-view to @react-native-masked-view/masked-view, rn-fetch-blob to react-native-blob-util, react-native-fs to expo-file-system, react-native-geolocation-service to expo-location. Managed Expo projects get a large head start here, because every expo-* package in the Expo SDK has supported the New Architecture since SDK 53, and anything built with the Expo Modules API supports it with no extra work.
One deadline is easy to miss. Expo Go supports only the New Architecture, so a project pinned to the legacy path cannot be run in it and needs a development build instead. That tends to be the moment a team discovers the migration is not optional, usually on the day a new contributor tries to run the app.
Does any of this matter if you never touch the native layer?
React Native answers this against its own interest, which is why it is worth quoting. Enabling the New Architecture may not immediately improve the performance or user experience of your app. Your code may need refactoring to use new capabilities. And data serialization may not have been a bottleneck for your app in the first place. If you expected a free frame rate from flipping a flag, that is the disappointment, stated by the people who built it.
What you get instead is access to things the legacy architecture could not do. Synchronous layout is the clearest one. Measuring a view with onLayout and setting state in the callback can apply after the previous render has already painted, which users see as a jump, and the usual victim is a tooltip or a popover positioned over something. With the New Architecture you measure inside useLayoutEffect and the measurement and the state update land in one commit. Next to that sits the concurrent renderer: Suspense for data fetching, Transitions for marking an update interruptible, and automatic batching that reduces re-renders without you writing anything. If this is the part you care about, the practical follow-up is app performance, because none of it helps an app that is slow for ordinary reasons.
Underneath all of it is one mechanical change. The New Architecture removes the asynchronous bridge between JavaScript and native and replaces it with the JavaScript Interface, which lets JavaScript hold a reference to a C++ object and call its methods without serialization. React Native's own illustration is a camera library processing frames in real time, where typical frame buffers are around 30 MB and the stream runs to roughly 2 GB of data a second. The bridge could not have carried that. Most apps are not doing that, which is exactly why the gain is uneven.
The cost of staying is the clearer number. Expo says the legacy architecture was frozen in June 2025, meaning no new features or bugfixes are being developed for it, and that new React and React Native features are landing on the New Architecture only, naming full Suspense support and new styling capabilities as examples the legacy path never got. Adoption matters too: Expo reported that as of January 2026 roughly 83% of SDK 54 projects built with EAS Build were on the New Architecture. Library authors read that number, and many popular libraries now support nothing else.
Five names, and which of them you can still change
These five words get used as if they were interchangeable. Four of them are parts of one thing. The fifth is a different layer with its own switch, and it is the only switch left.
| Name | What it is | Part of the New Architecture | Optional on a current version |
|---|---|---|---|
| Fabric | The renderer. A C++ core shared across platforms that builds and mounts your views. | Yes | No |
| TurboModules and JSI | How JavaScript calls native code. JSI replaced the asynchronous bridge with a direct memory reference. | Yes | No |
| Codegen | A build step that turns a TypeScript or Flow spec into native interfaces for Android and iOS. | Yes | No |
| Bridgeless mode | Running with the old bridge gone rather than idling alongside the new path. | Yes | No |
| Hermes | The JavaScript engine your code runs inside. Bundled with each React Native release. | No | Yes, JavaScriptCore is still supported |
Where this lands if a builder generated your app
A generated project is subject to the same version boundaries as a hand-written one, because the boundaries live in React Native and in the Expo SDK rather than in the tool that wrote your files. The useful question to ask any builder is which SDK it generates against. That one answer tells you whether the New Architecture is on, whether it can be turned off, and how much of the library ecosystem is open to you.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync so the code is not trapped anywhere. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to submit. It is $25 a month, with no free tier.
The thing worth knowing is where this question goes once the architecture is fixed. On a current SDK it is settled before you start, so the only decision left is your dependency list. Ask for a feature that needs a native library and that library has to work on the New Architecture. Before adding anything that ships native code, check it in React Native Directory, and prefer a package from the Expo SDK when one covers the job. That is not advice about builders, it is advice about any React Native project started this year.
Questions people ask about the React Native New Architecture
It passed default and became mandatory. React Native's own documentation says that with 0.76, the New Architecture is enabled by default in all React Native projects. Expo's documentation then adds the part most posts have not caught up with: React Native 0.82 is the first version that runs entirely on the New Architecture, and starting with 0.82 the option to disable it was removed. So on 0.76 through 0.81 it is on with an off switch, and on 0.82 and later there is no switch. Checked on 10 October 2026.
Start on a current version and skip the migration
Every project started on a current React Native or Expo release is already on the New Architecture. There is nothing to enable and nothing to migrate. The only list that still needs attention is the native libraries you add after that.
Start building