The New Architecture as Default (and 'Bridgeless')

The earlier New Architecture lesson framed Fabric and TurboModules as the direction the platform was moving in. That framing is no longer the whole story: in current templates, the New Architecture is already how a new app runs on day one, and the legacy bridge has moved from "the old default" toward "a compatibility option on its way out." This lesson is the status update.

From opt-in to on-by-default

For most of its life, the New Architecture lived behind a flag. You created a project on the old bridge, then — only when you were ready and your dependencies were ready — flipped the switch to try Fabric + TurboModules. That shape is behind us.

In a project generated from the current Expo and React Native community templates, the New Architecture is on from the first run. There's no opt-in step; the question has flipped from "when should I turn this on?" to "is anything in my dependency tree keeping me from being able to turn it off?" — meaning, do any of the native modules the app depends on still lack New Architecture support.

For an existing app still on the old bridge, upgrading is still a real project — it's dependency work, mostly — but it's no longer an experimental or exotic path. The mental model to carry is that the old bridge is a compatibility surface for shipped code, not the architecture new work targets.

What "bridgeless" actually means

"Bridgeless" sounds like a separate thing; it's not. Bridgeless mode is the New Architecture with the old asynchronous bridge physically removed from the runtime, so there's nothing for a legacy module to fall back to. All JS-to-native communication goes through JSI. There is no message queue, no serialization layer, no legacy path kept around for older modules to pretend they're fine.

That's why the term exists at all: when both systems co-existed, apps could run under the New Architecture but still have the bridge sitting there for anything legacy. Bridgeless is the state where that scaffolding is gone. It's the end point of the migration the platform has been working toward for years, and it's the default behaviour of a new project today.

The practical consequence: in bridgeless mode, a legacy native module that hasn't been ported to the TurboModule interface is not "degraded" — it simply doesn't exist to the JS side. There's no fallback path. This is why "does every native module in my dependency tree support the new system?" is the only question that matters when upgrading.

The compatibility question is the whole game

If this lesson has one practical takeaway, it's this: the interesting decision in 2026 isn't whether to enable the New Architecture. It's what to do when a library you depend on hasn't caught up.

Three honest paths, in rough order of how often they're the right call:

1. Wait or pin. If the dependency is close to shipping New Architecture support, staying on the old bridge for one more release is a small, boring cost. Not every migration has to happen on your schedule.
2. Upstream a fix. Many popular libraries have New Architecture support waiting on a PR nobody's merged. A small amount of your time can be worth weeks of blocked downstream work for everyone, including future you.
3. Swap the dependency. Sometimes the library is unmaintained and the writing is on the wall. The migration itself is often the forcing function that reveals which dependencies have a future.

Guessing and hoping is not one of these paths. Before upgrading an app, read each native dependency's README or releases page — the status is usually stated explicitly.

What you actually feel in app code

The surprising part of the migration, for most people, is how little the component code changes. This is the same point the previous New Architecture lesson made, and it's worth repeating now that New Architecture is the default: the programming model is still the one you know. JSX, hooks, StyleSheet, state, effects — all identical.

The wins show up in the shape of the app, not the shape of the code:

• Startup is faster because native modules load lazily rather than all at once.
• Native UI updates feel tighter because rendering goes through Fabric's more direct pipeline instead of the batched, serialized bridge messages.
• Type mismatches at the native boundary are caught earlier because codegen builds native-side interfaces from the JS specification.

None of those are features you write code against. They're what a profiler, a startup trace, and a build log show you after the migration. That is what the architecture change is actually for.

What to remember

• In current Expo and React Native community templates, the New Architecture is on by default. The question for a new app is no longer whether to opt in.
• "Bridgeless" is the New Architecture with the old asynchronous bridge removed from the runtime entirely — the long-term default direction, and the shape of a new project today.
• The real migration cost is dependency compatibility, not flipping a flag. Wait, upstream, or swap are the honest three options.
• For most day-to-day application code, nothing changes: hooks, JSX, and StyleSheet look identical. The wins show up in startup time, UI smoothness, and type safety at the native boundary.
• The previous New Architecture lesson is still correct — this one is the status update: concepts unchanged, defaults shifted.