React Native vs Native (Swift/Kotlin) in 2026: The Honest Case for One Codebase

Every week we talk to a small business owner who was quoted $90,000 to $180,000 by a Toronto or Vancouver agency for an "iOS and Android app" - meaning two separate codebases written in Swift and Kotlin, by two separate engineering teams, on two separate timelines that will never actually align. That model made sense in 2015. In 2026 it is mostly a way to bill twice for an app your customers cannot tell apart.

WebLaunch ships every mobile app as a single React Native + Expo codebase that deploys to both the App Store and Google Play. One team. One repo. Both stores covered for roughly the price one of those agencies charges for a single platform. This post is the honest engineering case for why - and the narrow edge cases where dual-native still wins.

The Three Real Options in 2026

React Native (with Expo)

A JavaScript and TypeScript framework from Meta that compiles to real native UI components on both iOS and Android. Expo is the toolchain on top - managed builds, OTA updates, push notifications, deep linking, native module access, and a library ecosystem covering practically every SMB need.

"React Native in 2026" almost always means "React Native with Expo." The combination has matured into the default for serious cross-platform work. The companies shipping production apps on this stack today include Shopify, Discord, Coinbase, Microsoft Teams, and Meta's own Facebook and Instagram apps.

Native iOS (Swift / SwiftUI) and Native Android (Kotlin / Jetpack Compose)

Two separate codebases in the platform-native languages. Best possible performance ceiling, deepest platform integration, and roughly 1.7x the cost and timeline of a React Native build for the same scope.

Flutter

Google's cross-platform framework. Technically excellent, smaller Canadian hiring pool than React Native, and the ecosystem fit is weaker for several SMB-critical integrations (Stripe, certain CRMs, Apple-specific features). We will ship Flutter when a project has a strong reason for it. For most Canadian SMBs that reason does not exist.

Why React Native + Expo Wins for 95% of SMBs

This is not a hedged "it depends." For the vast majority of small business apps in Canada - restaurant ordering, contractor lead capture, fitness studio booking, real estate buyer apps, retail loyalty, professional service portals - React Native is the obviously correct call. The reasons stack.

Cost: Roughly Half

One codebase versus two. For an MVP that would cost $20,000 to $30,000 as a single-platform native build, a dual-native build runs $35,000 to $55,000. The same scope in React Native + Expo ships to both stores at $18,000 to $32,000.

For a mid-range production app, dual-native at $80,000 to $130,000 becomes RN at $40,000 to $65,000. That is not a marginal saving. That is "the difference between launching with a marketing budget and launching broke."

Speed: Both Stores, Same Day

The single biggest soft cost of dual-native is timing drift. The iOS team ships a feature, the Android team is two sprints behind. Marketing has to decide whether to launch on iOS only, wait, or split the campaign. Operations has to support two slightly different feature sets.

With one codebase, every feature ships to both stores on the same day. There is no "iOS has this, Android does not." There is no second platform rollout. There is no quarterly catch-up.

Maintenance: One Repo, One Bug Fix

Over a 3-year horizon, the maintenance differential is where dual-native really bleeds. iOS releases break things. Android releases break things. With one codebase, you fix it once. With two, you fix it twice - and if your iOS engineer left and your Android engineer is on vacation, you fix it once now and again in six weeks.

We have inherited dozens of dual-native codebases where the platforms have drifted so far apart they are effectively two different products with the same logo. That drift accelerates with time. RN does not eliminate it but compresses it dramatically.

Hiring and Continuity

If you ever need to move your codebase to another developer or studio, the React Native + TypeScript hiring pool in Canada is several times larger than the senior Swift and Kotlin pool combined. You are also hiring one engineer instead of two specialists.

OTA Updates

This one is underrated. With Expo's EAS Update, you can ship JavaScript bug fixes to users without going through App Store review. A customer reports a bug at 9 AM, the fix is in users' hands by 11 AM. Dual-native requires a 24-48 hour App Store review cycle for every fix.

What the Performance Gap Actually Looks Like

The "React Native is slower than native" line is the most repeated and least true claim in the dual-native pitch. In 2017 it was correct. In 2026 with Fabric and TurboModules stable, the New Architecture in production, and Hermes as the default JS engine, the real numbers we measure across our production apps:

The metrics where native still measurably wins:

• Heavy real-time computation (on-device ML inference, sustained physics simulation)
• Sustained 120fps rendering on ProMotion displays
• Apps rendering hundreds of simultaneous video tiles
• Tight memory ceilings on very old devices

If you are not building a game, an on-device ML product, or a video-heavy social app, none of these apply to you.

When Dual-Native Is Genuinely Right

We ship native Swift and Kotlin when the project warrants it. The honest list of situations where it does:

Heavy AR or 3D

Real estate walkthroughs with high-fidelity 3D, retail AR try-on at scale, AR navigation. ARKit and ARCore APIs are deeper and more performant when called directly. RN can ship some AR via Viro or expo-three but the ceiling is lower.

Bluetooth LE-Heavy Apps

Medical devices, fitness hardware integration, industrial IoT, advanced wearable companions. RN has react-native-ble-plx but for apps where BLE behaviour and platform-specific background modes are the product, native gives you fewer surprises.

Brand-Defining Custom Motion

Luxury fashion apps, premium fintech, anything where the entire identity rides on custom animations that feel impossible. React Native Reanimated 3 is excellent but the absolute ceiling on SwiftUI and Jetpack Compose motion is higher.

Hard Real-Time Performance

On-device ML, real-time audio processing, sustained 120fps rendering, intensive computer vision. Less than 1% of SMB apps touch this category.

Specific Regulatory Environments

Some banking and healthcare audit processes are smoother with platform-native code. Not because RN cannot meet the security bar - it can - but because auditors want familiar artifacts.

If your project does not stack into one of these, dual-native is paying for a difference that nobody will perceive.

The Honest Cost of Choosing Wrong

If you go dual-native when you did not need to, the loss is:

• $20,000 to $80,000 in extra build cost
• 4 to 8 weeks of extra timeline
• Ongoing maintenance roughly 1.7x the RN equivalent
• Feature drift between platforms

If you go React Native when you actually needed native (the rare case), the loss is:

• Either re-platform later (full rebuild) or live with the performance ceiling
• For most SMB apps, the rebuild cost ends up similar to or less than what dual-native would have cost upfront anyway

The asymmetry favors starting with RN by default and going native only when the project requirements specifically demand it.

Agency Tells to Watch For

If an agency is pushing you toward dual-native for a standard SMB use case, listen for these:

• "Native is more reliable for App Store approval." False. RN apps get approved at the same rate as native.
• "React Native is just a wrapper, it is not real native code." False. It compiles to actual native UI components.
• "Performance is significantly worse." Outdated by about 8 years.
• "You will outgrow Expo." Outdated by about 4 years. Expo's managed and bare workflows now handle effectively every production case.
• "React Native is fine for prototypes but you need native for production." Then explain Shopify, Discord, Coinbase, and Meta itself shipping on RN.

If the agency is pushing dual-native and cannot give you a specific technical reason your app needs it, they are pitching their staffing structure, not your project. Get a second quote.

For context on what reasonable SMB app pricing looks like, see our 2026 mobile app cost guide. If you're in the Okanagan and trying to figure out who to actually hire for the build, our guide to choosing a mobile app developer covers what to look for locally.

The WebLaunch Default

Our default recommendation for any new SMB app project: React Native with Expo, single codebase, both stores, same launch day. We ship this stack roughly 90% of the time and the result is consistently $15,000 to $40,000 builds where downtown agencies are quoting $80,000 to $180,000 for the same scope.

The 10% where we ship native: when the project genuinely requires deep AR, complex BLE, brand-defining motion, or hard real-time performance. We will tell you up front which category you are in and we will not push you toward the cheaper path if your project actually needs the expensive one.

Same engineers ship your website, your backend, and your app. No agency hand-offs. No "the iOS team is waiting on the Android team."

Frequently Asked Questions

Will Apple reject a React Native app?

No more often than they reject native apps. Apple cares about your app's quality, privacy disclosures, demo account, and store guidelines. Framework choice is invisible to review.

Can React Native handle Apple Pay, Google Pay, and Stripe?

Yes, with first-class libraries. We ship these in production regularly.

What about offline mode?

Standard. RN's network and storage libraries handle offline-first patterns well. Some of our contractor apps are running on RN with offline-first sync to a Supabase backend.

What if I want to migrate from RN to native later?

You can. It is a rebuild. So is going the other direction. Pick right the first time using the criteria above.

Are there any well-known apps actually using React Native?

Facebook, Instagram, Discord, Shopify (both consumer and merchant apps), Coinbase, Microsoft Teams, Skype, Pinterest, Wix. The "RN does not scale" narrative is not supported by what actually runs in production.

Ready to Ship Both Stores for the Price of One?

If you have been quoted dual-native at a Toronto agency price and want a real engineering recommendation grounded in your actual project, book a free discovery call. We will tell you honestly which framework fits - including pushing you toward native if your project warrants it.

See our recent app and software work →