React Native 0.85: A Polished Upgrade Built on the New Architecture

When React Native 0.85 was released, the official messaging did not frame it as a “revolutionary” release, because this update is essentially a systematic refinement of core infrastructure — animations, debugging, testing, and related tooling — on top of the new architecture that has already landed.

If you are currently evaluating mobile technology choices, or considering an upgrade from an older version, the signal from this release is clear: the new architecture can now be treated as the default assumption, and future work will focus more on experience and ecosystem quality.

Below, we’ll look at this from three angles: the core changes introduced in 0.85, the key ideas behind the current React Native architecture, and how it compares with Flutter, Ionic, and fully native development in terms of performance and ecosystem maturity.

What does 0.85 bring?

A unified animation backend: bringing the critical path back under “official control”

The most notable change in 0.85 is the introduction of a Shared Animation Backend. For a long time, React Native’s built-in Animated API and the community-driven Reanimated library effectively lived in two separate worlds: one targeted simpler scenarios, while the other took over much of the underlying logic to achieve better performance and expressiveness.

In 0.85, the low-level animation execution logic has been moved down into RN Core. The official team and Software Mansion have worked together to consolidate animation scheduling and execution into a shared backend. Architecturally, this has several practical implications:

• Animation scheduling no longer relies entirely on “third-party magic”. Core logic now lives in the main repository, allowing it to follow React Native releases for consistency testing and performance optimisation.

• Native driver coverage has expanded. Layout-related properties can now be driven by the native driver, which used to be an area that was “possible to write, but risky to rely on heavily”.

• For product teams, the pressure around choosing an animation stack is reduced. You can more confidently combine official APIs with leading animation libraries, without worrying too much about which one might fail to keep up with the new architecture in the future.

If your app does not use many animations, this may not immediately change the user experience. But for complex interactions and animation-heavy products, it is a positive signal for long-term platform health.

Debugging pipeline cleanup: multiple clients, TLS, and separated test presets

Several other changes are less eye-catching on the surface, but they affect daily development experience:

• Multiple debugging clients based on the Chrome DevTools Protocol can now coexist. In simple terms, React Native DevTools, IDE plugins, and even automated debugging or AI tools can be attached at the same time, without competing for a single “only debugging connection”.

• Metro dev server now supports TLS configuration. For many enterprise projects that require HTTPS/WSS throughout the development flow, local debugging previously required either configuration hacks or self-signed proxy setups. Now this can be addressed directly at the framework level.

• The Jest preset has been split into a standalone package. This may look like a directory structure change, but it is valuable for monorepos and cross-platform projects: test configuration is no longer tightly coupled to the main RN package, upgrade timing can be more flexible, and it is easier to standardise testing inside internal scaffolding.

The shared characteristic of these changes is that they do not suddenly unlock flashy new capabilities, but they reduce the time wasted fighting the toolchain.

Core understanding of the current React Native architecture

If you hide the version number, it is now difficult to discuss React Native without mentioning the “new architecture”. A quick review of its key points helps when comparing frameworks at the architectural level.

From Bridge to JSI: a new communication model

Older React Native relied on a “bridge”: JavaScript and native code communicated through serialised message queues. This was inherently asynchronous, and data crossing the language boundary had to be packed and unpacked at a JSON-like level.

The new architecture replaces this layer with JSI. JavaScript can obtain references to C++ objects, allowing both sides to interact in a way that is much closer to “direct calls”.

The direct results are:

• Calls no longer have to be designed as asynchronous tasks by default. You can choose synchronous or asynchronous execution depending on the scenario.

• A large amount of serialisation and deserialisation overhead is removed, which makes a clear difference in CPU-constrained or high-frequency call scenarios.

• Work can be distributed across multiple threads more naturally, instead of pushing everything into a poorly described “bridge queue”.

For technology selection, this means the old impression that “the bridge is the performance bottleneck” should be updated to: “it depends on how you use JSI and TurboModules”.

TurboModules and Fabric: rebuilding modules and rendering

The other side of the new architecture consists of TurboModules, the new native module system, and Fabric, the new renderer.

• TurboModules emphasise lazy loading and type-safe cross-language calls. Together with Codegen, they generate C++ binding code from TypeScript/Flow types, reducing the maintenance cost of glue code.

• Fabric replaces the old UI management layer, making the rendering process more consistent, including Yoga layout, diffing, and commits, while also improving multi-platform adaptability.

For product teams, the direct impact is:

• The cost and mental overhead of writing native modules are reduced, especially in large projects where multiple platforms and versions coexist.

• In scenarios involving lists and large numbers of view updates, Fabric can deliver more stable and predictable performance, reducing some occasional stutters and strange rendering bugs.

React Native 0.85 does not introduce another dramatic architectural rewrite. Instead, it assumes you are already on this new architecture and starts moving toward a “normal maintenance phase”. This is the key signal for technology selection: the framework’s core structure has largely stabilised, and future focus will shift toward experience and ecosystem quality rather than another full-scale reconstruction.

Performance: where does React Native 0.85 stand?

Performance is unavoidable in technology selection, so let’s compare React Native with the other major routes.

Compared with Flutter: rendering control and predictability

• Flutter ships with its own rendering engine, such as Skia, and controls everything from layout to painting. Its performance characteristics are relatively clear: once startup, scrolling, and animations are tuned, the result is usually stable. It feels more like an “all-in-one machine”.

• React Native still renders UI using platform-native components. There remains an additional JS → Native call layer. Although this layer has become much thinner under the new architecture, it still exists in principle.

As a result, in extreme performance tests, Flutter can usually deliver better first-screen time and smoother long-list scrolling. In complex UI and animation-heavy scenarios, if peak performance is an absolute requirement, Flutter is generally the safer bet.

However, for most business apps, bottlenecks often come from data organisation, rendering strategy, and animation design, rather than the engine itself. React Native’s new architecture plus the new animation backend keeps as much native-executable work as possible on native threads. For mainstream scenarios such as e-commerce, content, and community apps, it is already enough to support a good user experience. If your team is more familiar with React, the performance gap itself is unlikely to be a deal-breaker.

Compared with Ionic / WebView: experience versus reuse

• Frameworks like Ionic essentially run a web technology stack inside a WebView. They are best suited for scenarios where you already have substantial web assets and need to quickly add a “usable” app shell for the business.

• React Native is closer to “using JS/React to drive native controls”. The interaction experience and system consistency are much better, including scrolling feedback, gestures, and input method behaviour.

If the project only needs simple information display and form submission, with limited dynamic interaction requirements, Ionic-style solutions can have a clear cost advantage.

But once you move into “heavy interaction + high experience expectations” — such as content communities, e-commerce, or productivity tools — React Native/Flutter-style “framework + native” approaches are more suitable, and the boundaries of the WebView route will quickly become visible.

Compared with fully native development: ceiling versus productivity

Fully native development, using Swift/Kotlin, needs little explanation: it has the highest ceiling in terms of performance and system integration. For scenarios that are extremely sensitive to latency, such as games, audio/video processing, automotive systems, and human-machine interfaces, it remains the only truly reliable choice.

This generation of React Native architecture is more about narrowing the gap with native in ordinary business scenarios. The goal is for most pages and interactions to reach a level where “users cannot feel the difference”.

From a team and cost perspective:

• A single React Native codebase can cover both iOS and Android, with much better cross-platform consistency.

• Companies with existing React/Web teams have lower training costs and do not need to maintain two separate native teams.

• Parts that truly require extreme performance can be moved down into native modules through TurboModules/Fabric and then connected back to RN.

This kind of hybrid model is already the practical reality in many medium and large companies: performance-sensitive core modules are written natively, while surrounding business logic is moved to React Native to improve iteration speed and unify the business development model.

Ecosystem: not just a question of “how many libraries”

When making a technology choice, ecosystem quality often has a greater impact on long-term maintainability and developer happiness than single-point performance.

React Native: backed by the React ecosystem, still in the new architecture transition

React Native is backed by the React ecosystem, which means:

• A large number of cross-platform state management, data flow, and engineering practices can be reused directly.

• Key areas such as navigation, gestures, animation, media, and maps all have mature mainstream solutions, and many of them are already adapting to the new architecture.

The realistic concern is that migration to the new architecture is not completed overnight. You may still encounter old libraries that are no longer updated, or libraries that only partially support the new architecture. For new projects, it is better to choose libraries that explicitly support TurboModules and Fabric from the beginning. For existing projects, you should first assess the maintenance status of core dependencies before deciding the upgrade pace.

Flutter: highly integrated, with a clear direction

Flutter’s ecosystem is more concentrated in its own “unified world”: the plugin system and official components are relatively complete, style and behaviour consistency are strong, and desktop/Web support has also moved forward quite aggressively.

Its issues are more about package size and engine overhead when extending to other platforms, as well as whether the team is willing to accept Dart and Flutter’s own development paradigm.

If you want to move one UI as much as possible to desktop/Web in the future, and you can accept the trade-offs in package size and technology stack switching, Flutter is the more stable route.

WebView / Ionic: maximum reuse versus limited ceiling

Ionic-style solutions are best suited to teams that already have a mature web frontend system and do not have high expectations for mobile experience. Fast delivery, a unified stack, and low maintenance cost are their main strengths.

The problem is also obvious: rendering and interaction are fully constrained by the browser. When you hit a performance bottleneck, there is not much the framework can do. You can only compromise at the product and interaction design level.

Native: the fallback option for compliance and high-risk scenarios

In industries that require strong compliance and high security, such as finance, healthcare, automotive, and government projects, native development is often still the easier path to get through. Platform documentation is complete, toolchains are mature, and regulators and auditors are more familiar with the native model.

In these scenarios, even when React Native is used at the business layer, key flows are often required to remain in the native layer, or additional security reviews may be introduced.

Final thoughts - practical advice for architecture and technology selection

At the 0.85 stage, if you are making a mobile technology choice, you can filter it through the following questions:

1. Team status: does the team already have strong React experience and many web assets, or can it start from scratch and accept Dart?

2. Business characteristics: is it mainly information and forms, or does it include many complex interfaces that require smooth interaction?

3. Performance ceiling: are there scenarios that must be “infinitely close to native” or even go beyond it?

4. Multi-platform expectations: are you only targeting iOS/Android, or do you want to unify desktop/Web in the long run?

Based on these dimensions, the rough conclusions are:

• React team + mainstream business app + iOS/Android first: React Native with the new architecture, especially versions after 0.85, is a well-balanced choice.

• Highly consistent cross-platform UI, with a clear long-term need for desktop/Web: Flutter is more suitable.

• Simple business requirements, extensive web assets, and moderate experience expectations: Ionic/WebView offers strong cost-effectiveness.

• Security, compliance, or extreme performance: native development remains the main path, while cross-platform solutions can only serve as supplements or peripheral layers.