React Native

What keeps moving when JavaScript is busy — sixteen things a screen does

A React Native screen is two programs talking to each other. Your React code runs on one JavaScript thread. The views the user touches belong to the platform’s UIUIUser Interface — what the user seesEverything the user sees and operates: screens, buttons, fields, states. UI is how the interaction looks; whether the interaction makes sense in the first place is a UX question, and the two get confused constantly.All terms thread, also called the main thread. Most of the time the difference is invisible. It becomes visible the moment the JavaScript thread is busy — a large response being parsed, a long list re-rendering, a heavy calculation — because anything that needs JavaScript waits, and anything that does not keeps moving. So the useful question about any part of a screen is not “is React Native fast?”. It is “which thread runs this, and what does the user see if that thread is busy for half a second?”. Here are sixteen things a screen does. Later sections cite the rows by number.

Two threads and a crossing: the New Architecture

A <View> in React Native is not a div and not a drawing. It becomes a real UIView on iOS and a real android.view.View on Android, created and drawn by the platform. That is why scrolling has the right physics, why the keyboard behaves correctly, and why screen readers work without extra effort — none of that is reimplemented; the operating system is doing its own job. It is also why an operating-system redesign reaches a React Native app, component by component, as soon as the app is rebuilt — the Flutter page draws that difference for iOS 26.

A change reaches the screen in three steps. First, render: React runs your components on the JavaScript thread and builds a tree of elements, and the renderer turns it into a shadow tree — a copy of the screen’s structure kept in C++. Second, layout: Yoga, a flexbox engine written in C++, computes the size and position of every node. In the common case both happen on the JavaScript thread; an urgent update, such as the response to a touch, can be rendered synchronously on the UI thread instead. Third, mount: the UI thread compares the new tree with the one on screen and applies only the difference — create this view, update that one, remove the third. The UI thread never runs your React code. It only applies the result.

The original design connected the two sides with a “bridge”: every message was serialised to JSONJSONJavaScript Object Notation — text format for dataA text format for passing data around: key–value pairs, lists, numbers and strings. It came out of JavaScript, but every language reads it now, and that is why most APIs answer in it rather than in anything more capable.All terms, queued, and delivered in batches, asynchronously. It worked, and it produced the framework’s signature failure — a busy JavaScript thread sent its instructions late and frames were dropped. The New Architecture replaces it with three parts. JSI, the JavaScript Interface, lets JavaScript hold a direct reference to a C++ object and call it synchronously, with no JSON in between. Fabric is the renderer described above, built on JSI. TurboModules are native modules loaded when first used rather than all at start-up, with their types generated by Codegen from a typed specification, so a mismatch between the JavaScript and the native signature fails at build time.

The JavaScript engine is Hermes, built by Meta for React Native. It compiles JavaScript to bytecodebytecodeinstructions for a virtual machineCompact instructions for a virtual machine rather than for a real processor — what the JVM, CPython, PHP’s OPcache, React Native’s Hermes and the Ethereum Virtual Machine run. A compiler produces it from source code ahead of time, so the runtime skips parsing; the virtual machine then interprets it or compiles the busy parts further into machine code.Full article →All terms when the app is built, so the phone does not parse source code at start-up — that is row 16’s first control. Hermes V1, a rebuilt compiler and virtual machine, became the default in 0.84; on the Expensify app the React Native team measured total time to interactive 7.6% faster on Android and 2.5% faster on iOS. JavaScriptCore, the engine Safari uses, left the core in 0.79 and lives on as a community package.

Lists, re-renders and images: where “React Native is slow” comes from

Almost every “React Native is slow” report resolves to rows 10, 13 or 15 — a list, an unnecessary re-render, or too much work on the JavaScript thread — or to row 4, an image nobody resized. Lists come first because they are on nearly every screen. A long list built with .map() inside a ScrollView mounts every row, visible or not. A FlatList is virtualised instead: it mounts a window of rows around the screen and unmounts the rest. By default it renders 10 rows first, then adds 10 per batch every 50 ms, and keeps a window 21 screens tall — ten above, ten below, and the visible one. When the user flings faster than JavaScript can render new rows, the list shows empty space where rows should be. The documentation calls these blank areas.

FlashList, Shopify’s list, takes a different approach: it recycles. Instead of mounting and unmounting rows, it keeps roughly one screen of cells plus a small buffer and, as a cell scrolls off the top, re-binds it to the item entering at the bottom. Version 2, released in 2025, runs only on the New Architecture and no longer needs size estimates. It is downloaded about two million times a week. Since 10 September 2026 it also carries a lesson of its own: Shopify is leaving React Native and says it is “in discussions with several companies about taking on long-term stewardship” — so a library you depend on now has a sponsor you need to watch. Whatever the list, the row is still the unit of cost. A list cannot make a slow row fast; memoise the row component, keep it cheap, and give it a stable key.

Row 13 follows the same rules as React on the web — the React page covers them: keep state as low in the tree as it can live, memoise what receives unchanged props, let the React Compiler do the memoising where it is enabled. One rule is specific to mobile. A navigation stack keeps the screens behind the current one mounted, so they keep their scroll position and state — and they also keep re-rendering whenever a shared store changes. React Navigation’s freezeOnBlur stops re-renders of screens the user cannot see; Coinbase built the same thing by hand in 2020, and the cases section says what it cost them not to have it.

Row 4 is memory, not speed. An image is decoded before it is drawn, and a decoded image costs width × height × 4 bytes, whatever its file size. A 12-megapixel photo — 4,000 by 3,000 pixels — is 48 MB in memory even if the JPEG was 2 MB; a feed of ten of them is close to half a gigabyte, and on a mid-range Android phone the system kills the app long before that. Ask the server or the CDN for the size you actually display, and use an image component with a disk and memory cache, such as expo-image.

Expo, native code and over-the-air updates

Expo used to be a sandbox you eventually had to leave. It is not any more, and React Native’s own documentation now tells you to start a new app with a framework and names Expo. It gives you a build service, over-the-air updates, a large set of maintained native modules, a file-based router, and — the part that decides how a project ages — config plugins. A config plugin describes a change to the native projects as code: add this permission, register that SDKSDKSoftware Development Kit — ready-made tools for a platformA packaged set of libraries, tools and examples for working with someone else’s platform. The difference from an API is that an API only states the rules, while an SDK hands you code that already knows how to speak them.All terms. The ios and android directories are then generated rather than edited by hand, so an upgrade regenerates them and reapplies your changes. A project whose native directories were edited by hand turns every upgrade into a merge against its own edits; those are the projects still three versions behind two years later.

Expo ships an SDK release for each React Native version it adopts, after it has tested the libraries together. SDK 57, released on 30 June 2026, runs React Native 0.86. SDK 58 has been in beta since 15 September 2026 on the 0.88 release candidaterelease candidatea build meant to become the releaseA build the team believes is ready to ship, published so users can try it before the final release. Bugs found now are fixed and no new features are added, but details can still change — so it is for testing, not for production.All terms and becomes stable shortly after 0.88 does. For a team that is the practical meaning of “upgrade one version at a time”: one SDK at a time, with npx expo install --fix aligning every Expo library to it.

Over-the-air updates and their exact limit

Because the app’s logic is JavaScript, you can send a new bundle to installed apps without going through store review — an over-the-air (OTA) update. A fix reaches users in minutes instead of days. Both stores allow it, within written limits. Apple’s Developer Program License Agreement, section 3.3.1(B), says interpreted code may be downloaded only if it does not change the app’s primary purpose, does not bypass signing, the sandbox or other security features, and does not create a store for other apps. Google Play forbids downloading executable code such as .dex, JAR or .so files from anywhere but Play, and exempts code that runs in a virtual machine or an interpreter, such as JavaScript — which must still obey every other Play policy.

The technical limit is stricter than the legal one. An update replaces JavaScript and assets — images, fonts, text — and nothing else. Anything that changes native code needs a new binary and a new review: adding a library with a native module, changing a permission, upgrading React Native, changing the icon. The dangerous case is the one in between: an update written against a newer build reaching phones that still run an older one. The JavaScript calls a native module that is not there, and the app crashes at launch. Expo prevents this with a runtime version — a label for the native layer that every build and every update carries, so an update is offered only to builds with the same label. The fingerprint policy computes the label from everything that can affect native code, which is safer than bumping it by hand and remembering to.

Releases, upgrades and the stores’ 2026 deadlines

React Native ships a minor version — 0.86, 0.87 — about every two months, and the release crew maintains the latest three. The newest is “Active” and gets frequent patches; the oldest of the three is in “End of Cycle” and gets fixes only for important regressions; everything older is “Unsupported”. In practice a version is supported for about six months. Since 0.83, in December 2025, roughly every second release is planned to break nothing users can see — 0.83 and 0.86 were — to make the cadence easier to keep.

Upgrading one minor version at a time is dull and takes an afternoon. Upgrading four at once takes a fortnight, because the framework, the navigation library, every native module and both platform SDKs move together, and a crash after the upgrade could come from any of them. The React Native Upgrade Helper shows the exact diff of the template between any two versions, which is most of the native-side work in a bare project. The release table above is also a budget: six months of support means a team that upgrades twice a year is never on an unsupported version, and a team that upgrades once a year always is.

Which React Native are you looking at

The stores’ deadlines — inherited from both platforms

A cross-platform app is not exempt from either platform’s calendar; it has both. Each store raises its minimum build requirements on a fixed date, and the change reaches React Native through the native projects and through every native dependency. These are the ones in force or arriving around this page’s date.

How much you actually share — and the native work that stays

The promise people hear is one codebase for two platforms. The honest version is that business logic, networking, state and most screens are shared, and the rest is not. Navigation patterns differ, the back gesture exists on one platform and not the other, permission dialogs behave differently, and each store has its own rules about what you must show. React Native gives you Platform.select and .ios.tsx / .android.tsx files precisely because the last part is expected to diverge.

When a capability has no JavaScript APIAPIApplication Programming Interface — contract between programsThe rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.Full article →All terms, you write a native module — a small piece of Swift or Kotlin exposed to JavaScript. This is normal, not a failure of the approach, but it is the moment a team needs somebody who reads the platform’s documentation. Shopify, after five years of moving every app to React Native, wrote in 2025 that “100% React Native should be an anti-goal”: home-screen widgets, watch apps, on-device models and Siri shortcuts were better built natively. A React Native team with no one who understands the native side eventually stalls on a problem no amount of JavaScript can reach.

Five cases, and what each one was missing

Each case is documented by the people it happened to — engineering blogs, a security advisory, a vendor’s shutdown notice. Between them they cover the decision to adopt, the cost of re-renders, a hosted dependency disappearing, the development tools as an attack surface, and the decision to leave.

The first case is the one every React Native discussion still cites, usually wrongly. In June 2018 Gabriel Peal published Airbnb’s account of two years with React Native. The headline was performance; the substance was structure. Airbnb had added React Native to two large native apps that kept moving fast: 80,000 lines of product code across 220 screens, plus 40,000 lines of JavaScript infrastructure, inside apps with about ten times the code and four times the screens on each platform. To make product work possible, the infrastructure team wrapped networking, experiments, internationalisation and shared-element transitions for React Native — and kept those wrappers in step with native code that never stopped changing. In their words, they “wound up supporting code on three platforms instead of two”. They also carried about fifty commits patched on top of React Native, which made every upgrade painful, and the start-up time of the JavaScript runtime hurt launch screens and deep links. New React Native work stopped, and the most-used screens were scheduled to return to native by the end of 2018. Most engineers who used it still rated it well. The lesson is about scope, not speed.

The third case is a service that simply ended. CodePush, Microsoft’s over-the-air update service, was the default way to ship JavaScript fixes to React Native apps for years. It lived inside App Center, and Microsoft retired App Center on 31 March 2025 — CodePush with it. The standalone server Microsoft offered for self-hosting was archived two months later. Teams that had treated OTA as part of their incident response lost it on a fixed date, and an app whose installed binaries pointed at the old service could no longer receive fixes at all; only a store release could move them. The fix was always available — Expo’s updates, or a compatible service — but it needed a native change, and so a review. An exit plan for a hosted dependency is cheap to write while the service still works.

The fourth case attacked developers, not users. On 3 November 2025 JFrog disclosed CVECVECommon Vulnerabilities and Exposures — a public ID for a known vulnerabilityA public identifier for a known security flaw, such as CVE-2021-44228 for Log4Shell, so that vendors, scanners and advisories all mean the same bug. The number says a flaw exists; how dangerous it is for you depends on whether you run the affected version and expose the affected part.All terms-2025-11953, rated 9.8 out of 10, in @react-native-community/cli-server-api — the package behind the Metro development server that npx react-native start runs. The server listened on all network interfaces rather than only the developer’s own machine, and one of its endpoints passed part of a request to a function that opens files and URLs through the operating system. Anyone who could reach the port could run commands on the developer’s computer; on Windows, with arguments of their choosing. Version 20.0.0 fixed it. VulnCheck saw it exploited from 21 December 2025 to deliver malware, and CISA added it to its catalogue of exploited vulnerabilities on 5 February 2026. A development server is a server: bind it to localhost, keep it off untrusted networks, and update the tooling as promptly as the app’s own dependencies.

Where it degrades

React Native is generous where a web team is strong and silent where it is weak. Components, state and data fetching transfer straight from React, so a screen is easy to build. What does not transfer is the second thread, the native projects and the store calendar — and almost every failure is one of these:

• Animations and scroll effects driven from JavaScript, which stutter the moment the thread has real work (rows 8–9).
• Long lists built with .map(), or virtualised lists with expensive, unmemoised rows (row 10).
• A global store that re-renders every mounted screen on each change (row 13).
• Full-resolution photos decoded into memory for thumbnails (row 4).
• Hand-edited ios and android directories, which turn every upgrade into a merge conflict.
• A version more than three minors behind, and native libraries that never migrated to the New Architecture.
• Over-the-air updates without runtime versions, staged rolloutstaged rolloutan update released to a growing share of usersReleasing an update to a small share of users first — 1%, then 5%, 20%, everyone — and checking crash and error rates before each step, so a bad release reaches a few people instead of all of them. It limits how many a bad release reaches, not whether it reaches them: on the app stores a halted rollout does not take the update back from those who already have it.All terms or a rollback.
• A team with no native skill, which stalls the first time a feature needs a module, a widget or a store deadline.
• Testing only on a recent iPhone, where the JavaScript thread is fast enough to hide every mistake above.
• A development server reachable from the network.

The honest limit is the second thread and the second platform. A product whose core is continuous custom graphics — a game, a drawing tool, a camera pipeline — fights the architecture, because its hot path wants to live entirely on one side of the crossing. A product built around a capability that has no JavaScript surface and changes with every OS release lives in native code anyway. And the economics are not fixed: React Native pays off when sharing one implementation saves more than the framework layer costs, and Shopify’s 2026 decision shows that the balance can move. For forms, lists, feeds, commerce and workflow apps built by a team that already writes React — most of what gets built — it is still a very good trade.

The practical check takes ten minutes. Read the React Native version in package.json and find its row in the release table. List the native dependencies and check each one’s New Architecture support and last release. Open the slowest screen in a release build on a mid-range Android phone with the performance monitor on. Search the code for useNativeDriver: false, onScroll handlers that call setState, and .map( inside a ScrollView. Check that over-the-air updates carry a runtime version. And confirm the Android target API and the Xcode version against the deadline table.

When to use it

Related pages

• DevelopmentFlutterFlutter is Google’s UI framework that draws every pixel of an app with its own engine, from one Dart codebase for iOS, Android, web and desktop. That choice is why a Flutter app looks identical everywhere and does not change when the operating system does — even when the operating system changes on purpose, as iOS 26 did. The page opens with sixteen things an app needs and whether Flutter draws them or has to ask the platform, then covers the three trees and the frame budget, what a rebuild costs, Dart and isolates, the platform boundary and OS redesigns, releases up to Flutter 3.47, five documented cases, and where it degrades.
• DevelopmentReactReact is a JavaScript library for building user interfaces out of components, each describing what the screen should show for the current state. React then works out how to change the page to match, and nearly every difficulty with it comes from breaking that model: impure work during render, state kept where it cannot be the source of truth, or an effect doing a job that belonged somewhere else. The page opens with every built-in hook on one screen and the four reasons a component renders, then covers render and commit, re-renders, state as a snapshot, effects, Server Components, and five documented cases.
• DevelopmentPWAA progressive web app, or PWA, is a website that uses a service worker and a web app manifest so it can be installed, work offline and behave like an app. There is no PWA SDK: what an installed web app can do depends on the browser and the platform, and the gap between Chrome on Android and Safari on an iPhone is what most product decisions turn on. The page opens with sixteen capabilities and where each one works in October 2026, then covers the service worker and the update that never arrives, caching strategies and storage that can be evicted, installation on four platforms, what Apple permits and how that changed, the store question, five documented cases, and where it degrades.