Journey Away from React Native
Mobile Development No Longer Needs React Native ???
Google(Android) & Apple(iOS) build the best tools to build mobile apps!
Why walk away from all the amazing native IDE & Tools …
In the early days of mobile app development, React Native (RN) offered a compelling promise: build apps for iOS and Android from a single codebase. It gained popularity by saving teams from duplicating efforts across platforms. However, today’s landscape has shifted. Modern native development tools and advances in AI-assisted coding have eroded React Native’s advantages. Even Meta (Facebook), the creator of React Native, chose not to use it for their new flagship app Threads, favoring fully native solutions instead. In this article, we explore why many developers and companies might move away from React Native in favor of native development, and what it means for mobile engineers and product managers.
React Native Limitations
The Hardware/Sensor/BLE Bottleneck: Complexities of BLE communication. Native frameworks provide direct, robust, and constantly updated APIs for this. Cross-platform frameworks add a layer of abstraction that can lead to performance issues, bugs, and delays in adopting new hardware/sensor/BLE features from iOS and Android.
The “Native Ceiling”: The common pain points:
- The “bridge” between JavaScript and native code becomes a performance drag.
- Difficulty in adopting new OS features.
- The debugging process becomes significantly more complex.
- Maintaining a forked version of React Native to handle custom native modules.
(+) Moving to native results in three (3) versions: RN, RN (bug fixes) & native
From the community …
Android AI Glasses
If you have been burned by the “React Native on Wear OS” experience, Android XR is going to be significantly harder.
Our assessment is spot on (see below 👇🏽) : React Native never got official first-party support for Wear OS. It has always relied on community hacks, third-party forks, and “WebViews on a watch” — none of which were ever great.
And Here is why “AI Glasses” (Glimmer) will be an even bigger nightmare for React Native than Wear OS was:
- The Rendering Problem (It’s not just a screen anymore)
— On a watch (Wear OS), the screen is small, but it is still just a standard opaque square/circle of pixels. Technically, React Native can draw a view there, even if it performs poorly.
— On AI Glasses (Glimmer), the display is optical see-through (transparent).
The OS Layer: Android XR uses a specialized rendering pipeline to handle “additive light” (black pixels become transparent).
The Problem: React Native’s renderer assumes it is drawing on a solid phone screen. If you try to render a standard RN <View> on glasses, you will likely get a solid black box floating in the user's vision (blocking their eye) rather than the transparent overlay you intended. React Native has no concept of "Glimmer" transparency or Focus Depth.
So … The “Physics” Advantage of Native — The reason React Native fails hard on AI Glasses isn’t just “JS Bridge overhead” (though that kills battery); it’s rendering physics.
React Native / Flutter: They paint pixels on a canvas. If you paint “Black” (#000000) in RN, it tries to render a black pixel.
Native Glimmer: It understands Additive Light. On optical see-through displays, “Black” is transparency. Glimmer’s rendering pipeline (SurfaceFlinger level) ensures that pixels are not just “drawn,” but illuminated correctly against the real world.
The Result: A React Native app often looks like a grey/black floating square blocking your vision. A Native Glimmer app looks like a hologram floating in the real world.
2. Input is Totally Different
— Wear OS: You still had a touchscreen. React Native’s onPress mostly worked.
— AI Glasses: There is often no touchscreen. Input is via “Frame Taps” (temple sensor), Head Gestures (nodding), or Hand Tracking.
The Gap: React Native’s gesture handler has no bindings for “Temple Tap” or “Head Nod.” You would have to write custom Native Modules for every single interaction, essentially writing the app in Kotlin anyway just to pass events to JavaScript.
3. The “Battery & Thermal” Wall
— Wear OS: Smartwatches have roughly ~300–400mAh batteries.
— AI Glasses: These have even smaller batteries (often split between arms) and much stricter thermal limits because they sit directly against your temples.
The Cost: React Native requires the JavaScript Bridge (or Hermes engine) to be constantly running. On a phone, this is fine. On glasses, spinning up the JS engine consumes precious milliwatts that will overheat the device or kill the battery in minutes.
Evolution of Native Development
SwiftUI and Jetpack Compose
Not long ago, developing UI separately for iOS and Android meant dealing with verbose, platform-specific toolkits (Storyboard/XIB or programmatic UIKit on iOS, XML layouts on Android). React Native gained traction by abstracting these differences. But in recent years, Apple and Google have revolutionized their SDKs with modern, declarative UI frameworks:
Apple’s SwiftUI (since 2019): A declarative framework that significantly reduces UI code and integrates across Apple platforms (iOS, macOS, watchOS, tvOS). Developers report building UIs much faster with SwiftUI — one analysis notes UIs can be built ~3× faster than with old methods. SwiftUI’s adoption has surged, used in around 70% of new iOS apps by 2025. Apple is clearly “pushing SwiftUI hard,” making it the focus of new API features like home screen widgets and Live Activities. This means many cutting-edge iOS capabilities are best accessed via SwiftUI, leaving React Native a step behind.
Android’s Jetpack Compose (since 2021): Google introduced Compose as the modern toolkit for Android UI. It’s fully declarative and Kotlin-based, eliminating XML layouts. The Android team has stated “Jetpack Compose … is the present and future of Android UI”, underlining Google’s commitment to Compose. Developers find it drastically simplifies UI development and iteration. In fact, when Meta built the Threads app for Android, they did it almost entirely in Jetpack Compose for rapid development. Despite the team’s lack of prior Compose experience, they shipped Threads to 100M users in just 5 months, crediting Compose’s flexibility and speed.
These advancements mean that native development isn’t the tedious slog it once was. A developer on Reddit aptly noted that SwiftUI and Compose “offer very good [developer experience], relatively simple to learn (they’re not very different from RN), [provide] native look and feel and run circles around RN in terms of performance”, without needing hacks or workarounds. In essence, the gap in developer productivity that React Native once filled has narrowed considerably. Modern native frameworks are declarative (inspired by React’s paradigm), so mobile engineers get a similar ease-of-use without leaving the native ecosystem.
Generative AI and Better Developer Tools
Another game-changer for mobile teams is the rise of Generative AI coding assistants (like GitHub Copilot and ChatGPT). Maintaining two codebases (one in Swift/SwiftUI and one in Kotlin/Compose) was traditionally seen as an overhead. But today, AI assistants can help convert or duplicate logic across languages and catch platform-specific issues early. For example, a developer can implement a feature in Swift and use AI to get a baseline Kotlin translation, reducing the barrier of writing everything twice.
Beyond AI, improved IDE support and build systems have eased pain points of native development. SwiftUI’s live previews and Compose’s interactive tooling give instant feedback, accelerating UI building and debugging. Continuous integration setups handle two apps fairly seamlessly now. In short, productivity tools have evolved to mitigate the historical cost of dual native codebases. This diminishes the appeal of a cross-platform framework, especially when weighed against the performance and UX benefits of going native.
Product managers should also consider that over-the-air (OTA) updates, a touted benefit of RN (updating JS bundle without App Store releases), are less critical with today’s fast app release cycles and robust CI/CD pipelines. Many apps can ship updates through app stores weekly or even daily. Apple’s and Google’s policies around dynamic code are also strict, limiting how much logic can be updated without review. So the advantage of OTA updates via React Native is not as large as it once seemed (mostly useful for minor tweaks).
Meta’s Own Move Away from React Native
The Case of Threads
It’s telling that Meta itself is not dogmatic about using React Native. React Native was created inside Facebook (Meta) in 2015 and used in the main Facebook app and others. Yet Meta has “jumped in and out of their own cross-platform solution due to many issues”, casting doubt on RN’s long-term viability. A high-profile example is Facebook’s new Threads app (launched 2023), which did not use React Native. Instead, the Threads team built the iOS app with Swift/UIKit and the Android app entirely with MAD Jetpack Compose. Their decision was based on achieving the best performance and development speed using each platform’s latest technology. As one Threads engineer put it, going all-native with modern toolkits “enabled us to move faster than refactoring a large application” and set the app up better for future updates.
- Performance and UI Fidelity: React Native relies on a JavaScript bridge (at least before the new Fabric architecture fully rolled out), which can introduce latency. In contrast, Jetpack Compose and SwiftUI UIs run directly in native code, yielding smoother animations and interactions.
- Access to Latest APIs and Features: When Apple introduces something like interactive widgets or App Clips, native developers can adopt them on day one. React Native must wait for the community or Meta to provide a binding — which could take months.
- Developer Experience and Maintenance: With React Native, every new Xcode or Android Gradle version can potentially break the build. And when things do break, Meta can’t ask Apple or Google to hold off changes — the onus is on the RN community to adapt. This dynamic means risk for product timelines.
Platform Advancements
Don’t Miss Out on Native Benefits
Using React Native means adding an abstraction layer over iOS and Android. This inevitably lags behind when Apple or Google introduce new capabilities. In modern mobile development, Google and Apple are pushing the envelope with platform-specific advances, and React Native apps risk missing those benefits or getting them late:
- Performance and UI Fidelity: Apps built with SwiftUI/Compose can use native UI components and optimize performance more easily. As one engineer observed, RN can’t match apps that use “components closer to the metal” — native UIs often just run better by default. React Native relies on a JavaScript bridge (at least until the new Fabric architecture fully rolls out), which can introduce latency and performance hiccups for complex animations or heavy computation. In contrast, Jetpack Compose and SwiftUI UIs run directly in native code, yielding smoother animations and interactions, especially under load. For a user base that expects instant, fluid responses, this is critical.
- Access to Latest APIs and Features: When Apple introduces something like interactive widgets, App Clips, or the latest ARKit features, native developers can adopt them on day one. React Native must wait for the community or Meta to provide a binding/module — which could take months or might never match full functionality. Apple’s new frameworks (e.g. Vision Pro’s visionOS) are SwiftUI-first, and “Apple’s only focus for new APIs” is often the native Swift/SwiftUI approach. Similarly, Android developers get immediate access to new AndroidX libraries, new UI patterns, or improvements in Kotlin (e.g. coroutines, flows) that may not yet be idiomatic in React Native. By choosing RN, teams risk lagging behind the platform curve. This can hurt a product’s competitiveness if it can’t quickly support the latest OS features or design conventions.
- Developer Experience and Maintenance: Modern native frameworks have first-party tooling support (integrated into Xcode and Android Studio). This means better error diagnostics, profilers, and seamless updates. With React Native, every new Xcode or Android Gradle version can potentially break the build until dependencies are updated. Developers often had to “fight with the platform [and] resort to hacks just to build the app (see RN failing to build every time a new Xcode version gets released)”. In other words, each iOS or Android update might introduce friction in React Native projects, whereas native projects, if updated to the new SDKs, generally “just work” or come with official migration tools. Google and Apple invest heavily in backward compatibility and smooth transitions for native APIs; React Native adds another moving part that must catch up. And when things do break, Meta (as the maintainer of RN) can’t exactly ask Apple or Google to hold off changes — the onus is on the RN community to adapt. This dynamic means risk for product timelines, as seen when a critical RN library lags behind an iOS update. Your product’s stability is therefore contingent on the priorities and reaction speed of a third party, who is reacting to the whims of a platform owner they do not control. This is a fragile foundation on which to build a serious business.
We have worked with Google (Android Studio) and Apple (XCode) for 20 years refining the performance / debug tools and RN just walks away from all that !!! Ridiculous !!!
In summary, the platform owners are effectively outpacing cross-platform solutions. What RN provided as a stop-gap (a unified UI layer) is now offered in improved form by the platforms themselves. A Reddit commenter put it succinctly: “RN made sense when writing the simplest of screens took a few hundred lines of setup on each platform, but that was years ago. Now the only benefit… is easier entry for web devs and OTA updates; everything else is simply superior if you write natively.”
Real-World Examples
Companies Returning to Native
The trend away from React Native isn’t just theoretical — many organizations have tried RN and ultimately reverted to native development for scalability and quality reasons. Some notable examples include:
- Airbnb: After initially adopting React Native, Airbnb famously decided to sunset its use of RN and rebuild their apps natively. They cited technical and organizational challenges in a series of blog posts, concluding that the costs outweighed the benefits. By 2018, Airbnb moved away from React Native back to full native development. The engineering team reported issues with integration into their large codebase, performance problems, and the overhead of keeping up with two evolving platforms plus RN itself.
- Intuit: The maker of financial apps like Mint and QuickBooks also experimented with RN and then left React Native for native code. Intuit engineers encountered difficulty achieving the level of polish and reliability they wanted via RN. Moving to Swift and Kotlin allowed them to better meet user expectations for performance and consistency.
- Meta Threads: The Threads app (Meta’s Twitter-like platform) was built with native SDKs (Compose and Swift) from the start, deliberately avoiding React Native. This decision was likely influenced by lessons learned from previous RN projects and the desire to leverage the best native tools available in 2023. Threads achieved a remarkably fast development cycle and smooth launch, reinforcing Meta’s confidence in going native.
These examples illustrate a pattern: cross-platform frameworks can carry hidden costs as projects and user bases scale. Initial speed in prototyping can give way to technical debt, performance bottlenecks, and slower adoption of new features. Companies that outgrew React Native did so to provide a better user experience and to iterate more freely with platform advancements. As one developer observed, maintaining a single JavaScript codebase sounds convenient, but in large apps the reality often became an “OK-ish JS codebase… and [poor] native modules” requiring expertise in both realms anyway. In contrast, dual native teams (separate iOS and Android developers) can fully optimize for each platform’s strengths and have more straightforward maintenance in the long run.
Performance
For developers prioritizing granular performance control and optimization, Android Studio with native Modern Android Development (MAD) offers a superior environment for performance tuning compared to React Native. This is primarily due to its direct access to the underlying platform, more sophisticated profiling tools, and the elimination of abstraction layers that can introduce performance bottlenecks.
Direct Access and Native Execution
Native Android applications, built with Kotlin or Java and the latest MAD principles (including Jetpack Compose for UI), are compiled to run directly on the Android operating system. This provides several key performance advantages:
Unhindered Hardware Access: Native apps can fully leverage the device’s CPU, GPU, and other hardware components without any intermediary layers, resulting in faster execution and more efficient resource management. This is particularly crucial for performance-intensive tasks such as complex animations, high-resolution graphics rendering, and heavy computations.
Optimal Performance by Default: Because the code is executed natively, it is inherently more performant. There is no need for a JavaScript bridge or a virtual machine to interpret code at runtime, which can introduce overhead and potential for dropped frames in React Native.
Immediate Access to New OS Features: When Google releases new performance-enhancing features or APIs in Android, native developers can integrate them into their apps immediately. React Native developers, on the other hand, often have to wait for the framework to provide a corresponding wrapper or module.
Advanced Performance Tuning Tools
Android Studio provides a comprehensive suite of advanced profiling and debugging tools specifically designed for native Android development. These tools offer deep insights into an app’s performance, enabling developers to identify and address issues with a high degree of precision. Key tools include:
CPU Profiler: Helps inspect your app’s CPU usage and thread activity in real-time. Developers can identify long-running tasks on the main thread that can cause the UI to freeze and optimize them accordingly.
Memory Profiler: Provides a detailed analysis of memory usage, helping to detect memory leaks, churn, and inefficient object allocation. This is critical for building stable and responsive applications.
Network Profiler: Allows for the inspection of all network traffic to and from your app, helping to optimize data transfer and reduce battery consumption.
Energy Profiler: Helps identify and address areas of high energy consumption, leading to better battery life for the end-user.
React Native’s Performance Considerations
While React Native has made significant strides in performance, especially with its new architecture that includes the Fabric renderer and TurboModules, it still presents some inherent challenges for performance tuning:
The JavaScript Bridge: In the older architecture, communication between the JavaScript code and the native side happens through a bridge, which can be a bottleneck, especially for frequent and data-intensive interactions. While the new architecture mitigates this, the abstraction still exists.
UI Rendering: React Native uses its own UI components that are then mapped to native widgets. While this provides a near-native look and feel, it can sometimes lead to performance issues with complex user interfaces and animations.
Limited Multithreading: JavaScript is single-threaded, which can be a limitation for CPU-intensive operations. While background tasks can be offloaded to native modules, this adds complexity to the development process.
Debugging and Profiling: While tools like Flipper and the React DevTools are available, debugging and profiling a React Native app can be more complex. Developers often need to be proficient in both JavaScript and native debugging tools to get a complete picture of the app’s performance.
Conclusion
The Case for Going Native in 2025 and Beyond
For today’s mobile developers and product managers, the landscape has shifted dramatically since React Native’s introduction. The need for a JavaScript-based cross-platform layer is simply less convincing when:
- Google and Apple provide high-level frameworks (Compose, SwiftUI) that deliver near-parity in development speed and first-class access to every native feature.
- Performance and polish are paramount — and are easier to achieve with native UI components and languages.
- Tooling and AI assistance have lowered the barrier to managing two codebases, making native development more efficient than ever.
- Real-world experience (from Meta, Airbnb, Intuit, OURA, and others) shows that beyond a certain app complexity/scale, the drawbacks of React Native often outweigh the benefits.
This is not to say React Native has no place. For some teams — especially those building simple apps or with strong web backgrounds — RN can still accelerate initial development and reduce upfront cost. It also has a vibrant community and an evolving ecosystem (e.g. Expo). However, it’s telling that even proponents admit RN’s “only benefit” today might be a slightly easier onboarding for web developers or the ability to push minor updates without app store releases. Meanwhile, the average mobile user’s expectations for app quality have risen, and native platform support is non-negotiable for meeting those expectations.
Ultimately, choosing a tech stack is about trade-offs. But the trade-offs have changed: where once React Native’s promise of “one codebase, two apps” was revolutionary, now native platforms have largely caught up to offer developer productivity with superior end-user experience. Unless your team’s situation squarely fits React Native’s narrow sweet spot (simple app, web-heavy team, need for rapid cross-platform rollout), you may find that going native is not only viable — it’s preferable for long-term success. As Google’s Android developers put it, Compose is the future of Android UI, and as Apple’s momentum shows, SwiftUI is on a similar trajectory for iOS. Embracing these modern native tools means aligning with the direction of the platform owners, and that alignment pays off in smoother development and happier users.
In summary: We don’t “need” React Native like we did in years past. Mobile development has evolved. By leveraging the latest native frameworks and tooling (and even a bit of AI help), teams can build fast, build beautiful, and build natively — without the compromises that cross-platform solutions entail. And for applications where peak performance is a critical requirement, such as real time, gaming, augmented reality, or complex data visualization, the direct control and powerful, specialized tooling offered by Android Studio (native MAD development) & iOS XCode (Instruments) make it the more advantageous choice for performance tuning.
The result is apps that are more performant, more up-to-date with platform innovations, and ultimately more capable of delighting users.
That is the outcome every product manager and mobile developer wants.
AshBike Project
Cross-platform solutions often promise efficiency but deliver compromise — compromising on performance, on access to the latest hardware features, and ultimately, on the user experience. Your users deserve better.
We believe so strongly in the native approach that we built a complete case study for you: a high-performance bike application that demonstrates the power of the modern Android development (MAD) toolkit. Before you commit to a path that will limit your potential, please consider what is possible when you build without compromise.
Code in: applications/ashbike
App Supports — Dark & Light mode — English, French, German & Spanish
This is What Your App Could Be: The AshBike Project
We built this to show what users expect and what native development delivers:
- Seamless Hardware Integration & Connectivity: The app features a fully operational Bluetooth Low Energy (BLE) service to connect with any external sensor, NFC for tap-to-pair functionality, and an integrated QR Code scanner. This deep hardware access is a core strength of native development.
- A Full Wear OS Companion App: This isn’t just a mirrored notification. It’s a high-performance smartwatch application built with Wear Compose and Horologist, featuring custom Tiles and Complications. This creates a true ecosystem experience that keeps users engaged.
- Intelligent, On-Device Features: Leveraging the device’s full power, we integrated CameraX with ML Kit for on-the-fly text recognition — a feature that runs smoothly and instantly, without relying on a server.
- Guaranteed Performance & Reliability: The live-tracking dashboard runs flawlessly in a Foreground Service, ensuring that critical, real-time data is never lost, even when the app is in the background. This is the level of reliability that builds user trust.
The Architectural Foundation of Excellence
These features are not accidents; they are the result of a deliberate and robust architectural strategy. This is the blueprint for a scalable, maintainable, and high-performance application:
- Core Architecture: A clean MVVM (Model-View-ViewModel) pattern separates concerns, making the app easy to test and scale.
- State Management: We use ViewModel and StateFlow to create a predictable, one-way data flow, which eliminates a whole class of bugs and makes the UI incredibly stable.
- User Interface: The entire UI is built with Jetpack Compose, a modern, declarative toolkit that allows for beautiful, responsive interfaces with less code and better performance.
- Dependency Injection: Hilt manages dependencies throughout the app, which is critical for building a modular and maintainable codebase that can grow without collapsing under its own weight.
- Data & Networking: With Room for local database management and both Retrofit and Apollo Client for networking, the data layer is flexible, efficient, and completely decoupled from the UI.
- Performance Optimization: We’ve even included Baseline Profiles, an advanced optimization that pre-compiles the app for significantly faster startup times and smoother animations.
This is the blueprint for a modern, world-class application. It’s robust, future-proof, and designed to deliver the best possible experience to your users.
React Native has its place, but for an application where performance, reliability, and access to the full potential of the device are paramount, the choice is clear.
Don’t build an app that simply works. Build an app that users love.
iOS Source
Apple Liquid Glass
Apple Just Released “Liquid Glass” design language.
We are able to build on it the day it is released.
While the RN community wonders if they should move to Liquid Glass we already have our app running on it …
Android App fits in Material Design & Apple OS fits in the Liquid Glass
Kotlin Multiplatform
If you really want one platform … you should be thinking about KMP
But we will save that for another time …
Our OURA Story
Oura’s transition from React Native to a native-first strategy is an case study, mirroring a broader industry trend. It underscores the unique challenges hardware-centric applications face and highlights the maturation of modern native development (SwiftUI/Compose) as the premier solution for building high-performance, long-lasting mobile products.
In the fast-paced world of tech startups, the choice of a technology stack is a high-stakes balancing act. The pressure to launch quickly, validate a product, and secure funding often pushes teams toward solutions that prioritize speed over long-term scalability. This is the classic startup gambit: trade tomorrow’s architectural purity for today’s market presence.
Oura, the pioneering smart ring company, provides a masterful case study in this very dilemma. Their journey from a React Native application to a native-first architecture isn’t a simple story of a mistake corrected, but rather a compelling look at a strategic trade-off, its initial benefits, and its ultimate, substantial cost.
The Initial Gambit: Launching at Web Speed
When Oura first launched, choosing React Native was a logical and defensible business decision. It’s highly probable their early engineering team had a strong background in web technologies like JavaScript and React. For them, React Native offered a compelling advantage:
- Speed to MVP: It allowed a small team to build and launch an app for both iOS and Android from a single codebase, drastically cutting down initial development time.
- Unified Team: It leveraged the existing skills of web developers, avoiding the immediate need to hire two separate, specialized, and expensive native mobile teams.
This strategy achieved its primary goal: it got the Oura ring and its app into the hands of users quickly, allowing the company to prove its concept and build a business. However, even at the outset, it was clear that this approach had a shelf life for a company so deeply integrated with hardware.
As we articulated in a communication to the team on December 18, 2020, the unique demands of their product would inevitably challenge the limits of a cross-platform solution.
We believed it was a misstep as the long term costs outweighed the quick / easy launch … So we sent:
They continued to post jobs in RN development … So we sent:
They presented a blog post saying they allow the developer to choose the tech stack / tools they want to use (RN, Flutter, native) … So we sent:
They started looking for native Android & iOS devs … So we set:
And today …
Oura (Smart Ring App): Oura Health, which produces the Oura Ring wearable, now emphasizes a fully native approach for its mobile app. The Oura team “works mostly with native code (Kotlin and Swift)” and “strongly favor writing all UI code natively,” only sharing code across iOS/Android where it makes sense (using techniques like Kotlin Multiplatform or code generation). This focus likely comes from Oura’s need to interface deeply with device hardware (Bluetooth, sensors) and deliver real-time, reliable health insights — areas where native code excels. Oura’s approach shows that even startups in the wearable space, who might traditionally have opted for a cross-platform shortcut, are finding better long-term stability in native development.
So we hope to work with them ….
We did the same with helping companies move from
- Java/XML to MAD Compose
- Objective-C(rap)/Storyboards to Swift/SwiftUI/SwiftData
