React Native Limitations in 2026: What's Real, What's Fixed
React
April 29, 2022•Updated October 9, 2026•7 min read
I hope you enjoy reading this post. If you want us to do your frontend development or design, click here.
Author: Alex Vasylenko | Founder of The Frontend Company
Reviewed by Pavlo Tyshchenko, COO, The Frontend Company
Most articles about React Native limitations describe a framework that no longer exists. They list the asynchronous bridge, layout jumps and a dozen 2022-era complaints as if nothing had changed — while React Native has shipped the New Architecture by default (0.76, October 2024), frozen the old one (0.80), dropped it entirely (0.82, October 2025) and is now on 0.87 (August 2026).
So this guide does the one thing generic lists don't: it splits React Native's limitations into the ones that are still real in 2026 and the ones the New Architecture fixed or softened, and then says when the real ones actually matter for your app.
A quick orientation for anyone new to the stack. React Native is Meta's open-source framework (first released in 2015) for building iOS and Android apps in JavaScript or TypeScript with React. Unlike WebView wrappers, it renders real platform UI components; what you share between platforms is the application logic and most of the UI code, not a web page in disguise. Expo is the officially recommended framework for new apps, and Meta, Microsoft, Shopify and Discord run it in production at scale. If you are wondering whether the framework itself is in trouble, the short answer is no — we covered the evidence in Is React Native dead?
What are the limitations of React Native?
In 2026, React Native's real limitations come down to one trade-off: you are building on an abstraction over two platforms. Everything below is a consequence of that deal, not a bug Meta forgot to fix.
- Platform-specific UI depth. ‘Learn once, write anywhere’ is accurate; ‘write once, run everywhere’ is not.
- Native modules are yours to maintain. Anything outside the framework and the community libraries means Swift and Kotlin code that somebody on your team owns.
- Heavy graphics, 3D and sustained compute. Application logic still runs on one JavaScript thread.
- App size. A few megabytes of runtime overhead compared with a native build.
- Upgrade cadence and ecosystem churn. A new minor version roughly every two months, and libraries that have to keep up.
1. The cross-platform promise has a platform-specific tail
React Native shares logic and most UI between iOS and Android, but each platform keeps its own conventions: navigation gestures, permission dialogs, keyboard behaviour, haptics, system fonts, the status and navigation bars. The last 10–20% of a polished app is platform-specific code — Platform.select branches, separate components, sometimes separate design decisions. Teams that budget for ‘one codebase’ and get ‘one codebase plus two sets of edge cases’ are the ones who end up writing angry limitation posts.
Accessibility is the sharpest example. React Native exposes accessibility props that map to VoiceOver on iOS and TalkBack on Android, but the two screen readers announce roles, states and focus order differently, so a screen that passes on one platform can fail on the other. That matters more than it used to: if you ship to EU consumers, the European Accessibility Act has applied to apps since June 2025, and conformity has to be demonstrated per platform, not per codebase.
2. Native modules are yours to own
Anything the framework and the community libraries don't cover — a payment SDK, a hardware integration, a vendor's native-only API — means writing a native module in Swift or Objective-C and Kotlin or Java. The New Architecture made this cleaner (Turbo Native Modules are type-safe and generated from a TypeScript spec), but it did not make it JavaScript. Somebody on the team needs native skills, and that code needs maintaining through every React Native upgrade and OS release.
The same applies to third-party libraries. The ecosystem is large, but a dependency that lags behind a React Native release can block your upgrade, and since 0.82 a library that never migrated to the New Architecture is a liability rather than an inconvenience. Vet maintenance activity before you adopt, not after. Whether you build that native capacity yourself or bring in a partner is a staffing decision; we compared the two models in in-house vs outsourcing.
3. Heavy graphics, 3D and sustained compute
Your application logic still runs on a single JavaScript thread. That is not the performance problem it used to be — the renderer is multi-threaded, high-priority UI events can render synchronously on the UI thread, and animation libraries run worklets off the JavaScript thread — but it is a ceiling. A game loop, real-time 3D, video processing or an app that crunches data continuously in the background will hit it. Those apps belong in native code, in Flutter with its own rendering engine, or in a native module that React Native merely drives. Our Flutter vs React Native comparison goes into where that line sits.
4. App size
A React Native app ships the Hermes JavaScript engine (Hermes V1 is the default since 0.84), your bundled JavaScript and the framework's native runtime on top of what an equivalent native app would include. The overhead is a few megabytes and most users never notice. It only becomes a limitation when install size is a hard constraint — markets where downloads happen over metered connections, or app-clip-style experiences with strict budgets.
5. Upgrade cadence and ecosystem churn
React Native ships a new minor version roughly every two months (0.83 in December 2025, 0.87 in August 2026). Most upgrades are routine, and several recent releases explicitly shipped with no breaking changes, but each one can touch native project files, build tooling and third-party libraries. Over a multi-year product lifetime that is real engineering time — and skipping upgrades for a year makes the eventual jump harder, as teams only now moving off the Legacy Architecture are finding out.
React Native is also unopinionated: navigation, state management, styling and project structure are choices, not defaults. A team used to a stricter framework like Angular often underestimates how much standardisation it has to do itself before a large codebase stays consistent.
Which React Native limitations did the New Architecture fix?
This is the half most ‘limitations’ posts get wrong. Since 0.76 (October 2024) the New Architecture is the default, and since 0.82 (October 2025) it is the only architecture — you can no longer opt back into the old one. The complaints below describe a framework you cannot install anymore.
The asynchronous bridge bottleneck
In the old architecture every interaction between JavaScript and native code was serialised to JSON and passed over an asynchronous bridge. That is where ‘React Native is slow’ came from: scroll events, layout measurements and native calls all queued on the same channel. The New Architecture removed the bridge. JavaScript now calls native code directly through the JavaScript Interface (JSI), native modules are Turbo Native Modules, and the Fabric renderer talks to the platform without a serialisation step. If a post lists the bridge as a current limitation, it is describing 2021.
Layout jumps and asynchronous effects
With the old renderer, state updates made inside an onLayout callback could apply after the previous frame had painted, so adaptive layouts — tooltips, measured lists, responsive containers — showed intermediate states. The New Architecture gives synchronous access to layout, so those updates land before anything is visible, and useLayoutEffect behaves as it does on the web.
Missing modern React features
Suspense, Transitions and automatic batching needed the new renderer to work properly in React Native. They are fully supported now, and the framework tracks current React releases closely (React 19.2 shipped in 0.83).
Fragile tooling: debugging, testing, hot reload
Older limitation lists complain about hot reload losing state and the lack of an official testing story. Hot reload was replaced by Fast Refresh years ago; React Native DevTools, built on Chrome DevTools, became the default debugger in 0.76; new projects start with TypeScript, ESLint and Jest configured, and 0.85 shipped an official Jest preset package. End-to-end testing is still a third-party choice (Detox, Maestro) — which is the same situation as native development.
Softened, not solved: single-threaded JavaScript
Your code still runs on one JavaScript thread, so this one stays on the ‘real’ list above. What changed is how much that matters: rendering and gesture handling no longer wait on that thread, and 0.85 added a new animation backend. The old claim that users ‘can't do two things at once’ in a React Native app was never accurate — the limitation is about heavy compute, not multitasking.
When do React Native limitations actually matter?
A limitation only counts if your product runs into it. For most product apps it won't.
They matter if you are building
- A game or anything with a custom real-time rendering loop.
- An app whose core feature is heavy on-device processing — video editing, AR, large offline datasets crunched continuously.
- A flagship app where every platform detail must match the newest OS features on launch day, with a team that already has strong Swift and Kotlin engineers.
- A product with a hard install-size budget.
For those, start from the alternatives rather than fighting the framework: Flutter for rendering control, Kotlin Multiplatform for shared logic with fully native UI, or going native. We ranked the options honestly in React Native alternatives.
They are mostly theoretical if you are building
- Feeds, marketplaces, booking and commerce flows, fintech dashboards, messaging, content apps — the bulk of what gets shipped.
- A product where the mobile app and a React web app share a team, a design system or a codebase.
- An MVP, or a product that needs to iterate weekly on both platforms with one team.
In that territory the trade-off works in your favour: one team, shared logic, native UI, and a hiring pool that dwarfs any alternative. What you still need is someone who can handle the native tail — the modules, the per-platform polish, the upgrades. That is the honest version of ‘React Native has limitations’: not a reason to avoid it, a line item to staff for.
Conclusion
React Native in 2026 has a short list of real limitations — platform-specific depth, native-module ownership, heavy graphics and compute, size, upgrade churn — and a longer list of historical ones the New Architecture closed. Judge it by the first list, and judge it against your actual product, not a worst case.
Planning a cross-platform app and want a team that has shipped through these trade-offs? The Frontend Company provides React and React Native development services — have a look at our case studies, read where to hire React Native developers if you are still weighing the options, or contact us for an intro call.
FAQ
Alex Vasylenko is the founder of The Frontend Company, DBC and several other successful startups. A dynamic tech entrepreneur, he began his career as a frontend developer at Deloitte and Scandinavia's largest banking company. In 2023, Alex was honored as one of 'Top 10 Emerging Entrepreneurs' by USA Today.
Follow the expert:
REVIEWED BY
COO, The Frontend Company
Pavlo runs operations and delivery at The Frontend Company and builds its internal AI systems - agent workflows, automation, and the engineering side of software compliance.
Follow the expert:
KEEP READING
Related articles
LEARN MORE
