Native vs cross-platform app development: React Native/Expo vs Swift/Kotlin vs Flutter

If you're planning an app, someone will ask early on: native or cross-platform? The question sounds technical, but the answer mostly comes down to budget, timeline and what your app does all day. Here is how I'd decide in 2026, with the trade-offs laid out plainly.

Native vs cross-platform: what the terms mean

Native development means building each platform with its own tools: Swift (usually with SwiftUI) for iOS, and Kotlin (usually with Jetpack Compose) for Android. You end up with two codebases, often maintained by two people or two teams.

Cross-platform development means writing one codebase that ships to both stores. The two serious options today are:

• React Native, usually with Expo: you write TypeScript and React, and the app renders real native UI components (a real iOS button, a real Android list).
• Flutter: you write Dart, and Flutter draws every pixel itself with its own rendering engine instead of using the platform's components.

A newer middle path is Kotlin Multiplatform, which shares business logic (and optionally UI through Compose Multiplatform) while keeping native code where you want it. It's solid, but its ecosystem and hiring pool are still smaller than the other three, so I won't cover it in depth here.

Side-by-side comparison

The cost row is the one most founders care about. With one codebase you design, build, test and fix features once instead of twice. In our experience, a cross-platform build often costs noticeably less than two native apps of the same scope, though the exact gap depends on how much platform-specific work the app needs. For real numbers, see how much it costs to build an app.

React Native and Expo in 2026

React Native is maintained by Meta and used in large production apps across the industry. Expo is the framework and cloud tooling built on top of it, and the React Native team itself now recommends starting new apps with a framework like Expo. A few things changed the picture over the last couple of years:

The New Architecture

React Native's New Architecture (the Fabric renderer, TurboModules and JSI) replaced the old asynchronous "bridge" between JavaScript and native code. JavaScript can now call native code directly and synchronously when it needs to, rendering is more predictable, and React's concurrent features work. It became the default for new projects in late 2024, and recent React Native and Expo releases have dropped the legacy architecture. Most of the performance complaints you'll find in older blog posts were about the bridge.

EAS Build, Submit and Update

• EAS Build compiles your iOS and Android binaries in the cloud, so the team doesn't need a carefully maintained Mac build machine for every developer.
• EAS Submit uploads those builds to App Store Connect and Google Play.
• EAS Update delivers over-the-air (OTA) updates: changes to your JavaScript and assets reach users' phones on the next launch, without waiting for store review.

Add Expo Router (file-based navigation that also runs on the web), config plugins that let you change native project settings without hand-editing Xcode projects, and a large library of maintained modules for camera, notifications, location, payments and more. For most apps, you rarely need to write native code at all.

Flutter: Dart and its own rendering engine

Flutter, from Google, takes a different approach. Instead of asking iOS and Android to draw components, it ships its own rendering engine (Impeller) and paints the whole UI itself. That has real advantages:

• Pixel-identical UI on every device, which is great for heavily branded, custom-designed interfaces.
• Smooth animations and a mature widget library.
• Fast hot reload and a well-integrated toolchain.

The trade-offs: you're writing Dart, a language few developers use outside Flutter, so the hiring pool is smaller. Because Flutter draws its own widgets, matching the exact feel of each new iOS or Android design update depends on the Flutter team catching up. And Flutter on the web renders to a canvas, which works for app-like dashboards but is a poor fit for content you want indexed by search engines.

Flutter is a good choice, and I'd never tell a team with strong Flutter experience to switch. The main reason I don't default to it is code sharing with the web, which I cover below.

Native: Swift/SwiftUI and Kotlin/Jetpack Compose

Native development today is far more pleasant than it was a decade ago. SwiftUI and Jetpack Compose are both declarative UI frameworks, similar in spirit to React. You get day-one access to every new OS feature Apple and Google announce, the best debugging and profiling tools, and no abstraction layer to fight.

The cost is duplication. Every screen, every bug fix and every feature is built twice, in two languages, and the two apps tend to drift apart over time unless someone works to keep them in sync. For a funded product with separate iOS and Android teams, that's manageable. For a startup or small business with one budget, it usually isn't. If one platform is clearly enough for launch, a single native app can make sense: see iOS app development and Android app development.

When native development wins

Go native, or at least plan significant native code, when your app is mainly about something the platform does:

• Heavy graphics and real-time media: 3D, AR, games, pro-level video or audio editing, camera pipelines that process every frame.
• Deep OS integration: CarPlay or Android Auto, background audio or location logic beyond the usual modules, Bluetooth hardware with strict timing, accessibility services, custom keyboards.
• Widget- and watch-heavy products: if the home screen widget, Live Activity or Apple Watch app is the product, you'll be writing Swift and Kotlin for those surfaces anyway.
• Brand-new OS features on day one, when shipping before anyone else is the business advantage.

A useful nuance: React Native apps can include native code. Widgets, watch extensions and custom native modules can sit alongside a React Native app, and Expo config plugins can add those targets to the project. So the real question is often "how much native code do we need?" rather than "native or not?"

When cross-platform wins (most business apps)

Most apps are forms, lists, feeds, chat, maps, payments, notifications, user accounts and a backend. That covers marketplaces, booking apps, internal tools, field-service apps, community apps, SaaS companions, and most AI-powered apps. For these, cross-platform is the better business decision:

• You launch on both stores at once instead of picking a platform and leaving half your market waiting.
• Your budget goes further, either to a lower total cost or to more features for the same money.
• Fixes ship once. A bug found on Android is fixed for iOS too.
• One team owns the whole product, which matters a lot when you're early and changing direction weekly.

This matters even more for an MVP, where speed of learning is the whole point. Our guide on how long it takes to build an app shows how timelines shrink when you're not building twice.

Sharing code with a web app

Many products need a web app too: an admin dashboard, a customer portal, or a browser version of the app itself. This is where React Native has a structural edge. Your web app will very likely be built with React, so a React Native team can share:

• TypeScript types, validation and business logic.
• API clients, data fetching and state management.
• Backend code. With a realtime backend like Convex, the same queries and mutations power both the phone and the browser.
• In some cases the UI itself, through React Native for Web and Expo Router.

It's also one language and one mental model across the whole stack, so the same developers can move between mobile, web and backend. Our own product Star works this way: a tablet app used to run setlists and presentations, plus a web app at app.starapp.io, both built from the same TypeScript foundation. If a browser product is part of your plan, see web app development.

Our default at Loha.dev, and why

To be upfront: at Loha.dev we build mobile apps with React Native and Expo, and that's what we'll recommend for most projects. You should know that bias. Here's the reasoning behind it:

1. One TypeScript codebase for iOS, Android and often web keeps cost and timeline reasonable for founders and small businesses.
2. Over-the-air updates let us fix most issues the same day instead of waiting on store review.
3. The hiring pool is the largest of any option, so you're never locked in to us. Another React Native developer can pick up the code.
4. Native escape hatches exist. When a feature needs Swift or Kotlin, we write that piece natively instead of switching the whole app.

When we'd tell you otherwise: if your app is a 3D or AR experience, a game, a pro media tool or mainly a watch app, a native-first build (or a game engine) is the honest answer, and we'll say so even if it means you work with someone else. You can see how we approach mobile app development, or skip ahead and get a free app plan for your specific idea.

A quick way to decide

Whatever you choose, the framework matters less than a clear scope, a good backend and a team that ships. Choosing well up front saves you a rewrite later.