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

When React Native 0.85 was released, the official team didn't use any "revolutionary" taglines, because this update was essentially a systematic polish of infrastructure like animations, debugging, and testing, built on the premise that the new architecture has already been established.

If you're currently in a technology selection phase, or considering an upgrade from an older version, the signal from this version is:the new architecture can now be considered the default, and future efforts will focus on experience and ecosystem quality.

Below, we cover three dimensions: the core changes in 0.85, the key points of the current React Native architecture, and a comparison with Flutter, Ionic, and native solutions in terms of performance and ecosystem.

What does 0.85 bring?

A unified animation backend: bringing critical paths back under "official control"

The most noteworthy aspect of 0.85 is the introduction of a shared animation backend. For a long time, React Native's built-in Animated and the community's Reanimated were essentially two separate worlds: one for simple scenarios, and the other taking over much of the logic for performance and expressiveness.

In 0.85, the underlying logic for animation execution has been pushed down to the RN Core. The official team and Software Mansion have converged the animation scheduling and execution path into a single universal backend. From an architectural standpoint, this has several practical implications:

• Animation scheduling no longer completely relies on "third-party magic"; core logic enters the main repository, enabling consistency testing and performance optimization alongside RN versions.

• The coverage of native drivers has expanded; layout-related properties can now be driven by the native driver, a scenario that previously often fell into the "can be written but risky to rely on heavily" category.

• For business teams, the pressure of choosing an animation layer decreases: they can more confidently use a combination of official and top-tier animation libraries without worrying about one of them falling behind the new architecture in the future.

If your app doesn't have a lot of animations, this might not immediately change your experience; but for apps with complex interactions and heavy animations, it's a positive for "long-term health."

Debugging workflow improvements: multi-client, TLS, test preset separation

Several other changes are less flashy but impact daily development experience:

• Support for multiple debugging clients based on the Chrome DevTools Protocol coexisting. In simple terms, you can connect React Native DevTools, IDE plugins, and even automated debugging/AI tools simultaneously without competing for a single "exclusive debug connection."

• The Metro dev server supports TLS configuration. For many enterprise projects that require full HTTPS/WSS, previously local debugging meant either modifying configuration or using self-signed proxies; now it can be addressed at the framework level.

• Jest preset has been split into a standalone package. This might seem like just a directory structure change, but it's valuable for monorepos and cross-platform projects: test configuration is no longer tightly coupled with the main RN package, upgrade cadences can be more flexible, and it's easier to unify into an internal company scaffold.

The common thread of these changes: they don't suddenly unlock any dazzling capabilities, but they reduce time wasted on the toolchain.

Core understanding of the current React Native architecture

If you ignore the version number, it's hard to discuss React Native nowadays without mentioning the "new architecture." Let's briefly recap its key points, which will aid in framework-level comparisons.

From Bridge to JSI: a generational change in communication

The older React Native relied on a "bridge": communication between JS and native happened through a serialized message queue, inherently asynchronous, and required JSON-level packaging and unpacking for cross-language data.

The new architecture replaces this layer directly with JSI: JS can obtain references to C++ objects, and the two sides can interact in a manner closer to "direct invocation."

The direct results:

• You're no longer forced to design all calls as async tasks; you can choose sync/async per scenario.
• Significantly reduced serialization/deserialization overhead, which makes a noticeable difference in CPU-intensive or high-frequency calling scenarios.
• Work can be more naturally distributed across multiple threads, rather than squeezing everything into a poorly described "bridge queue."

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

TurboModules and Fabric: module and rendering refactoring

On the other side of the new architecture are TurboModules (the new native module system) and Fabric (the new renderer).

• TurboModules emphasize lazy loading and type-safe cross-language calls. With Codegen, they generate C++ binding code from TypeScript/Flow types, reducing glue code maintenance costs.
• Fabric replaces the old UI management layer, making the rendering pipeline more consistent (including Yoga layout, diff, commit) and better adapting to multiple platforms.

The direct impact on business teams:

• The cost and mental burden of writing your own native modules is reduced, especially in large projects with multiple platforms and coexisting versions.
• In scenarios with lists or large view updates, Fabric can deliver more stable and predictable performance, reducing some "sporadic" jank and strange rendering bugs.

React Native 0.85 doesn't make drastic architectural changes; instead, it assumes you're already on this new architecture and starts transitioning to a "normal maintenance period." This is the key signal for technology selection:the framework's structure is essentially settled, and subsequent efforts will shift to experience and ecosystem quality rather than another comprehensive overhaul.

Performance: Where does React Native 0.85 stand?

Technology selection inevitably involves performance, so let's compare React Native with other approaches.

Differences from Flutter: rendering control and controllability

• Flutter has its own rendering engine (Skia, etc.), controlling everything from layout to drawing. Its performance characteristics are clear: once startup, scrolling, and animations are dialed in, results are stable—like an all-in-one machine.
• React Native still renders UI using platform-native components, with an additional JS-to-Native call layer. Although this layer has been thinned out under the new architecture, it still exists in principle.

Therefore, in extreme performance tests, Flutter often delivers better first-screen times and smoother long-list scrolling. For complex UI and animation scenarios with extreme peak performance requirements, Flutter is more reliable.

However, for most business apps, bottlenecks often lie in data organization, rendering strategies, and animation design, not the engine itself. React Native's new architecture + new animation backend maximize the amount that can run natively on native threads, which is sufficient for mainstream scenarios like e-commerce, content, and community apps. If your team is more familiar with React, the performance gap alone is unlikely to be a deal-breaker.

Compared to the Ionic / WebView approach: trade-offs between experience and reuse

• Frameworks like Ionic essentially run a web tech stack inside a WebView. The best use case is when you have a large web asset base and need to quickly wrap a "usable" app shell for your business.
• React Native is positioned more as "driving native controls with JS/React," offering much better interaction experience and system consistency—e.g., scroll feedback, gestures, input method behavior.

If your project only needs simple information display and form submission with low dynamic interaction requirements, cost advantages of Ionic and similar approaches are obvious. But once you enter "heavy interaction + experience-focused" business (e.g., content communities, e-commerce, utility apps), a "framework + native" approach like React Native/Flutter is more suitable; the boundaries of a WebView approach quickly become apparent.

Compared to pure native development: ceiling vs. productivity

Pure native (Swift/Kotlin) needs no explanation; it offers the highest performance and system integration ceiling, and remains the only reliable choice for latency-sensitive scenarios (gaming, audio/video processing, automotive, human-computer interfaces, etc.). React Native's new architecture narrows the gap with native for "normal business scenarios," aiming for most pages and interactions to reach a level where users "can't tell the difference."

From a team and cost perspective:

• One set of React Native code covers iOS/Android with much better cross-platform consistency.
• Companies with existing React/Web teams have lower training costs and don't need to maintain two native teams.
• Parts that truly need peak performance can be pushed down via TurboModules/Fabric, written natively as modules and then connected to RN.

This hybrid model is the practical reality for many mid-to-large companies' mobile tech stacks: core performance-sensitive modules are written natively, while peripheral business is react-native-ified to boost iteration efficiency and unify the business development model.

Ecosystem: It's not just about "how many libraries there are"

When making technology choices, the quality of the framework's ecosystem often affects "long-term satisfaction" more than isolated performance metrics.

React Native: React ecosystem backing + new architecture migration phase

React Native is backed by the React ecosystem, meaning:

• A large number of cross-platform state management, data flow, and engineering practices can be directly reused.
• Mature mainstream solutions exist for navigation, gestures, animation, media, maps, etc., and most are already adapting to the new architecture.

However, a practical consideration is that the new architecture migration didn't happen overnight; you may still encounter libraries that haven't been updated or are only partially adapted. For new projects, it's advisable to start selecting libraries that "explicitly support TurboModules and Fabric"; for old projects, assess the maintenance status of core dependencies before deciding on an upgrade cadence.

Flutter: high integration, clear path

Flutter's ecosystem is more concentrated in its own "unified world": plugin system and official components are fairly complete, with high consistency in style and behavior. Desktop/Web support has also been pursued aggressively.

Its challenges are more about the bundle size and engine overhead when going to "other platforms," as well as whether the team is willing to accept Dart and Flutter's unique development paradigm.

If you want to potentially move as much of a single UI as possible to desktop/web, and can accept the bundle size and tech stack switching cost, Flutter is a more stable path.

WebView / Ionic: extreme reuse vs. limited ceiling

Ionic and similar solutions are best suited for teams that already have a mature web frontend system and don't have high mobile experience requirements—fast delivery, unified stack, low maintenance costs are their main battlefield.

The problem is also straightforward: rendering and interaction are entirely constrained by the browser; when performance bottlenecks arise, it's hard to optimize much at the framework level, forcing compromises in product and interaction design.

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

In industries that require strong compliance and high security (finance, healthcare, automotive, government projects), native is often the easier path to take: official platform documentation is complete, toolchains are mature, and regulators and auditors are more familiar.

In such scenarios, even if the business layer uses a cross-platform solution like React Native, it's common to require that critical flows stay in the native layer or undergo additional security reviews.

Final - Practical advice for architecture/selection

Standing at the 0.85 release, if you're making mobile technology decisions, you can filter based on the following questions:

1. Team situation: Do you have extensive React experience and web assets, or can you start from scratch and accept Dart?

2. Business characteristics: Is it mainly information and forms, or are there complex interfaces requiring smooth interactions?

3. Performance ceiling requirement: Are there scenarios that must be "almost native" or even surpass native performance?

4. Expectations for multi-end unification: Are you only targeting iOS/Android, or do you want to unify to desktop/web in the long run?

Combining these dimensions, the rough landing points are:

• React team + mainstream business app + primarily iOS/Android: The new architecture of React Native with versions after 0.85 is a balanced choice.

• Need highly consistent cross-platform UI, and long-term plans to go to desktop/web: Flutter is more appropriate.

• Simple business, abundant web assets, average experience requirements: Ionic/WebView solutions offer high cost-effectiveness.

• Security/compliance/extreme performance: Native is the main path, cross-platform solutions can only be supplementary or peripheral.