Two Fundamentally Different Approaches to the Same Problem
Building a mobile app that runs on both iOS and Android has two broad architectural approaches. Native development means writing separate codebases for each platform, using each platform's own language and UI toolkit: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. Cross-platform development means writing one codebase that compiles or runs on both platforms, most commonly today with React Native or Flutter. Neither approach is universally "correct" — the right choice depends on the specific app's performance requirements, team composition, and how quickly it needs to reach both platforms.
Native iOS: Swift and SwiftUI
Swift is Apple's modern programming language for iOS, macOS, watchOS, and tvOS development, replacing the older Objective-C as the default choice for new Apple-platform projects since its introduction in 2014. Swift is statically typed, memory-safe by design (using automatic reference counting rather than a tracing garbage collector, meaning memory is freed deterministically as reference counts drop to zero rather than during unpredictable collection pauses), and includes modern language features like optionals (making the possibility of a "no value" state explicit in the type system rather than relying on error-prone null references) and powerful pattern matching.
SwiftUI is Apple's modern, declarative UI framework, introduced in 2019 as the eventual successor to the older, imperative UIKit framework. In SwiftUI, a developer describes what the UI should look like for a given state, rather than writing step-by-step imperative code to construct and update UI elements, and the framework automatically re-renders the relevant parts of the UI when that underlying state changes — a declarative model that will feel immediately familiar to any engineer who has used React, Flutter, or Jetpack Compose, since all four converged on broadly the same declarative-UI paradigm around the same period. Native iOS development requires a Mac running Xcode, Apple's official IDE, for building, testing (including Apple's iOS Simulator), and submitting an app to the App Store — this is a hard requirement with no workaround, regardless of which language or framework was used to write the app's actual code.
Native Android: Kotlin and Jetpack Compose
Kotlin is Google's now-preferred language for Android development, having effectively succeeded Java as the default choice for new Android projects since Google announced "Kotlin-first" Android development in 2019, though Java remains fully supported and a large amount of existing Android code and documentation is still in Java. Kotlin is interoperable with Java (both compile to the same JVM bytecode and can call each other's code directly), while adding more modern language conveniences: null-safety enforced by the type system, more concise syntax, and coroutines, Kotlin's lightweight approach to asynchronous programming, broadly analogous in spirit to Go's goroutines discussed in the companion systems-languages article on this site.
Jetpack Compose is Android's modern, declarative UI toolkit, directly analogous to SwiftUI: describe the desired UI for a given state, and the framework handles efficiently updating the actual rendered UI when that state changes, replacing the older, more verbose XML-layout-plus-imperative-code approach of classic Android's View system. Unlike iOS development, Android development has no special hardware requirement: Android Studio, the official IDE, and the full Android build and emulator toolchain run natively on Windows, macOS, and Linux.
Cross-Platform: React Native and Flutter
React Native, built by Meta, lets developers write a mobile app's logic and UI in JavaScript or TypeScript using React's component model, while rendering through each platform's actual native UI components under the hood — a React Native button genuinely is a real native iOS or Android button, not a custom-drawn approximation. This gives React Native apps the platform's native look, feel, and accessibility behavior largely for free, and it's a natural fit for teams that already have strong React/web development experience, since the component model and much of the surrounding ecosystem (state management patterns, much of the general React knowledge) transfers directly.
Flutter, built by Google, takes a different architectural approach: it draws every pixel of its UI itself using its own graphics rendering engine, completely bypassing each platform's native UI components. This produces pixel-identical rendering across iOS and Android (an advantage for apps with strong custom branding that don't want platform-specific visual differences) and generally very smooth, consistent animation performance, since Flutter isn't dependent on bridging to native components for every UI update. The tradeoff is that Flutter apps don't automatically inherit each platform's native look-and-feel conventions the way React Native apps do — replicating iOS-specific or Android-specific interaction patterns has to be done deliberately. Flutter uses Dart, a language most engineers haven't used elsewhere, which is a genuinely new syntax and ecosystem to learn compared to React Native's use of familiar JavaScript/TypeScript.
Side-by-Side Comparison
| Approach | Language | UI Rendering | Code Sharing | Best For |
|---|---|---|---|---|
| Native iOS | Swift | SwiftUI (native) | None (iOS-only) | Platform-specific performance, latest OS APIs day one, dedicated iOS team |
| Native Android | Kotlin | Jetpack Compose (native) | None (Android-only) | Platform-specific performance, latest OS APIs day one, dedicated Android team |
| React Native | JavaScript / TypeScript | Real native components via bridge/JSI | ~90%+ between platforms | Teams with existing React experience, apps wanting native look-and-feel |
| Flutter | Dart | Self-drawn (Skia/Impeller engine) | ~90%+ between platforms | Custom-branded UI needing pixel-identical cross-platform rendering |
Performance and API-Access Tradeoffs
Native apps have direct, zero-overhead access to every platform API the moment Apple or Google ships it, and can push hardware performance to its absolute limit without any cross-platform abstraction layer in the way — this matters most for high-end games, complex real-time camera or graphics processing, and apps competing on frame-perfect animation smoothness. Cross-platform frameworks typically lag behind by weeks to months before a brand-new native OS API gets an official cross-platform binding, and while both React Native and Flutter have closed most of the historical performance gap for typical business-logic-and-UI apps, genuinely performance-critical or graphically demanding apps still more commonly reach for native development, or a hybrid approach where a specific performance-critical screen or feature is built natively and the rest of the app remains cross-platform.
Choosing an Approach
For a solo engineer, a small team, or an early-stage product validating an idea across both platforms quickly, a cross-platform framework is usually the more efficient starting point — one codebase reaching both major app stores substantially reduces both initial development time and ongoing maintenance burden compared to keeping two fully separate native codebases in sync. Between React Native and Flutter specifically, the better choice generally follows existing team skills: React Native for teams with strong existing React/JavaScript experience, Flutter for teams willing to invest in learning Dart in exchange for pixel-consistent cross-platform rendering. Native development remains the stronger choice for apps that must push platform-specific performance to its limit, need same-day access to brand-new OS capabilities, or are being built by a larger organization that already maintains dedicated, specialized native iOS and Android teams — a common setup at bigger companies even when a cross-platform approach would technically be viable, simply because the organization already has the specialized talent and prefers the platform-idiomatic result native development guarantees.