Most founders we talk to still cite Airbnb's 2018 sunsetting of React Native as proof the framework is broken. It's the load-bearing piece of evidence in nearly every "we should go native" Slack thread we get pulled into. The problem is that the architecture Airbnb actually complained about: the JSON-serialized bridge, the async first render, the missing native-module ergonomics, isn't the architecture you'd ship on today.
If your v1 is a working Lovable web app and you're staring down a mobile build, the choice between React Native and native iOS in 2026 isn't about a fundamental performance gap. It's about your team, your platform count, and what your app actually does at the screen level. We've built mobile products on both stacks for almost a decade, including Semaphr, our feature-flag and remote-release tool that manages 500K+ app sessions across iOS and Android, and the decision tree we use with founders looks nothing like the one floating around on X.
Here's the version we actually use.
What changed since Airbnb left
Airbnb's 2018 post is still online and worth reading, but read it as a 2018 document. Gabriel Peal was specific: the team hit walls with "initialization and the async first render" and with "supporting code on three platforms instead of two." The bridge: the chunk of React Native that serialized every JS-to-native call into JSON and shipped it across an asynchronous boundary, was the technical root cause of most of the pain.
That bridge is no longer the runtime path a new 2026 project should be planning around. React Native 0.76 made the New Architecture the default, 0.82 made it the only runtime path, 0.84 made Hermes V1 the default JavaScript engine, and 0.85 is the current stable release as of May 2026. Fabric, TurboModules, Codegen, Hermes, and JSI move JS/native interop away from JSON serialization and toward direct native interfaces. Third-party migration guides report large old-architecture to new-architecture gains, but we would not use those numbers as neutral RN-vs-Swift benchmarks.
The honest read: React Native caught up on the things that used to be obviously broken. It is not equivalent to native on bleeding-edge features, and we'll be specific about which ones below. But anyone using 2018 Airbnb as a reason to skip RN in 2026 is arguing against a framework that doesn't ship anymore.
The counter-evidence has been piling up, but it needs to be read precisely. Shopify migrated all of its mobile apps to React Native and reports sub-500ms P75 screen loads with greater than 99.9% crash-free sessions. Its earlier 2020 post reported 95% shared code in Arrive and 99% in Compass; the 2025 retrospective focuses on feature parity, productivity, and native escape hatches rather than one company-wide sharing number. Coinbase's 2021 migration moved 200+ screens of a 56M-user app off native, retrained 30+ native engineers, and ended up with 113 contributors on the React Native repo, many of them web engineers who previously could not ship mobile code at all.
The pattern is clean: companies with strong web engineering cultures keep choosing React Native; companies with strong mobile-native cultures keep choosing native. Airbnb in 2018 was the latter. Most founders coming out of a Lovable v1 in 2026 are the former.
When native iOS still wins in 2026
There is a real list of features where native produces a meaningfully better product, and we won't pretend otherwise. If your v2 lives in any of these categories, write Swift or budget native platform code for the hot path.
ARKit, Metal, custom shaders. RN bindings exist, but maturity varies and Apple APIs land in Swift first. Complex HealthKit writes, ResearchKit, CareKit, and Apple Watch companions, community packages can read HealthKit, but writing is fragile and you need physical devices to even test. Bluetooth Low Energy with strict timing for medical devices or hardware peripherals; every team we know that hits BLE at scale ends up writing a native module anyway. Sub-16ms gesture-driven UI for drawing apps, music apps, advanced camera filters, possible in RN with Skia plus Reanimated 3, but the tax is high. CarPlay, Live Activities, Dynamic Island, and long-running background work may need custom native modules even when the rest of the app is React Native.
A practical heuristic we use with founders: if a feature is on the WWDC keynote, budget native work for it. Sometimes a binding appears quickly. Sometimes it does not get mature enough for your product before your launch date.
There's also the App Store review angle. Apple Guideline 4.2, "Minimum Functionality," asks for features, content, and UI beyond a repackaged website. If your v2 strategy depends on App Store discoverability and you're tempted by a Capacitor wrap, which loads your existing Lovable build inside a WKWebView, add mobile-specific functionality before submission: push, biometric login, camera capture, offline mode. A straight website-in-a-wrapper materially increases 4.2 rejection risk.
When React Native is the only realistic answer
There is one founder profile for which React Native isn't a debate: web-first team, both platforms needed, six to ten weeks to TestFlight. If that's you, native is not on the table, not because RN is technically superior, but because the math doesn't work.
The planning math usually favors RN for two-platform products: one shared app means less duplicated feature work, one QA path, and fewer specialist hires. Third-party agency comparisons often estimate 30-50% cost savings versus two separate native builds, Netguru reported one Swift build taking 33% longer than its RN equivalent, and in our own greenfield work we have measured 43% less calendar time on comparable two-platform apps. Treat those as planning ranges, not laws. Two native apps require two specialists (Swift plus Kotlin) plus design and QA on both platforms. One RN app with a small native escape hatch typically requires 1 to 1.5 engineers to ship the same feature set.
Imagine you're a founder with a Lovable web app at $30K MRR, your investors are pushing for a mobile launch before your seed extension, and you have one React engineer and a part-time designer. In our hiring work, senior iOS specialists in NYC or SF are usually slower to find than senior React engineers, and that can eat the entire quarter you're trying to ship inside of. Public survey data points the same way: JavaScript and React are much more common than iOS-specific tooling. The salary gap moves by source and city. The recruiting timeline is what we plan around.
This is why Coinbase's 2021 headline reason for switching was not raw performance. It was team economics. The "113 contributors" number is the point: the adjacent React pool is larger than the iOS-specialist pool, and for any company that already writes React on the web, the mobile contributor pool grows the moment you commit to RN.
Where founders trip: Lovable's code doesn't carry over either way
Here's the catch. Lovable outputs React DOM: div, span, input, button. None of those components exist in React Native. Lovable's own FAQ confirms it does not build React Native apps and does not export to Expo.
What does carry over: your Supabase backend, your auth, your API contracts, your database schema, your business logic, your design tokens, your copy, your validated user flows. What gets rewritten: every screen.
This is true whether you go React Native or native iOS. So "we'll just port the JSX" is not on the menu. The third-party tools claiming "Lovable for mobile", RapidNative, CatDoes, and Newly, are RN code generators. The output is React Native code that still needs an engineer. Useful as scaffolders, dangerous as production sources of truth, and the same caveat that applies to Lovable applies to them.
Plan for a screen-layer rewrite. Budget six to ten weeks for a small app, twelve to twenty for a real one. The good news is that everything below the screen survives, which is usually 60-70% of the engineering work.
The watch-out: don't let anyone sell you "just as fast"
We need to be direct about something the React Native community sometimes oversells. RN on the New Architecture is not equivalent to native iOS on every dimension. It caught up on the 2018 issues: bridge serialization, async first render, and native-module overhead. It is genuinely production-grade for the lane Shopify and Coinbase live in. It is not better than Swift on memory, on bleeding-edge Apple APIs, or on the things Apple ships at WWDC.
Shopify is also honest about the maintenance tax: native specialists still matter for build and release, version updates, platform APIs, performance tuning, and React Native dependency upgrades. In our planning, that means budget maintenance every release cycle. Do not sell RN as a no-native-maintenance stack. Someone still needs to own App Store release engineering, native dependency compatibility, device testing, and crash/performance telemetry.
Shopify's framing is the one we'd repeat to any founder: "100% React Native should be an anti-goal…think native and React Native." The mature stack for a serious mobile product is RN for CRUD, lists, dashboards, content feeds, and forms, plus a native module for any hot path that needs it. Pretending you can do everything in JavaScript is how you end up with a slow app and a regretful CTO.
The decision tree
Run your v2 through these seven questions in order. The first one that gives you a clean answer is your answer.
| # | Question | If yes | Then |
|---|---|---|---|
| 1 | Is mobile usage going to be under 30% and you don't need camera, push, or deep hardware? | Ship a PWA from your Lovable build first. iOS PWAs got push in 16.4, install rates are low, but you'll learn whether you need the store at all. | Skip the rewrite. |
| 2 | Are you iOS-only, US/EU consumer, pre-Series A? | Native iOS (SwiftUI on iOS 17+, UIKit only where you must). Halves your code and your hiring problem. | Skip Android until you have signal. |
| 3 | Do you need both platforms in 6-10 weeks to TestFlight? | React Native with Expo is the realistic option. Use 30-50% lower duplicate work as a planning range, not a promise. | Plan a Capacitor v1.5 if the App Store deadline is this month. |
| 4 | Does the app rely on ARKit, complex HealthKit writes, BLE timing, sub-16ms gestures, or CarPlay/Live Activities? | Write Swift for iOS-only. Or write RN with a native module for that one path. | Don't fight the platform. |
| 5 | Is your team web/React shop with no mobile engineers? | React Native + Expo. Coinbase's 113-contributor result is proof that the adjacent pool matters. | Don't hire two specialists you don't need. |
| 6 | Do you ship weekly with bug-fix urgency? | RN + EAS Update. Compatible JS, styling, and asset fixes can ship without a new binary; native code, permissions, SDK upgrades, and material behavior changes still need store discipline. | Native review cycles will slow urgent iteration. |
| 7 | Are you in a regulated industry with quarterly releases and risk-averse compliance? | Native. Store-reviewed release discipline matters more when you ship rarely. | Stability beats velocity here. |
If you walked through that and landed on React Native, you're in good company. Shopify and Coinbase made the same call for the same reasons. If you landed on native iOS, you also have good company, and the right answer is to hire one senior Swift engineer and skip Android until your retention numbers earn it.
What these numbers are based on
Version and architecture claims were checked in May 2026 against the React Native release overview, the New Architecture docs, and the 0.76, 0.82, 0.84, and 0.85 release posts. Shopify claims come from its 2020 commitment and 2025 retrospective; Coinbase claims come from its 2021 migration post. Lovable, Expo, Apple, Stack Overflow, and Netguru claims come from the Lovable React Native FAQ, Expo EAS Update docs, Apple App Review Guidelines, Stack Overflow 2025 survey, and Netguru RN-vs-Swift comparison. TTM, cost, salary, and hiring numbers move by market, so we use them as planning ranges and separate them from appssemble project experience.
What we'd do with your v2
For most Lovable founders we work with, the answer is React Native plus Expo, with the existing Supabase backend preserved and a screen-layer rewrite planned for six to ten weeks. We then map the one or two features that genuinely need native modules before the build starts. That's the engineering playbook we run for clients who need to ship to both stores without doubling their team. Native iOS is the right answer when the product is iOS-only, when a native-only feature is core, or when you've already decided to hire actual mobile engineers and budget for two parallel codebases.
The Airbnb quote founders should keep is the one about team composition: "we recognized how important mobile was becoming but didn't have enough mobile engineers." That's still true. The bridge they complained about isn't.
If your team is web-first and you need both platforms fast, book a call and we'll scope the mobile rewrite with you: screen plan, native-module map, release path, and the honest list of features that should stay native.