The Cross-Platform Question Isn’t Going Away
Building for both iOS and Android has always meant a trade-off: write once and share code, or write twice and get full platform control. Years into the cross-platform experiment, the answer is more nuanced than “always pick X.” Here’s an honest look at where each option stands.
Flutter
Flutter compiles to native ARM code and renders its own UI using the Skia (and increasingly Impeller) graphics engine rather than relying on native platform widgets. This gives it extremely consistent visuals across platforms and generally strong performance, especially for animation-heavy interfaces.
Strengths: Consistent UI across platforms, strong performance, a single codebase that also targets web and desktop reasonably well, growing package ecosystem.
Trade-offs: Apps don’t automatically pick up native platform look-and-feel changes, the Dart language has a smaller talent pool than JavaScript, and app sizes tend to run larger than native equivalents.
React Native
React Native lets teams write UI in JavaScript/TypeScript while rendering through native components. The introduction of the new architecture (Fabric and TurboModules) significantly closed the performance gap that used to be a major criticism of the framework.
Strengths: Huge talent pool since it uses JavaScript/TypeScript and React, strong ecosystem, code and knowledge sharing with web teams, native look-and-feel by default since it uses actual platform components.
Trade-offs: Bridging to native modules can still introduce complexity for highly custom features, and performance for very demanding use cases (heavy animation, real-time graphics) can require dropping into native code.
Native Development (Swift/Kotlin)
Writing separate codebases in Swift for iOS and Kotlin for Android remains the choice for teams that need the absolute best performance, deepest platform integration, or are building apps where a slightly-off UI interaction is unacceptable — think camera-heavy apps, AR experiences, or anything pushing hardware limits.
Strengths: Best possible performance, first access to new platform APIs, no abstraction layer to fight against, easiest path to platform-specific polish.
Trade-offs: Two codebases to maintain, two sets of platform expertise needed on the team, generally slower time-to-market for feature parity across platforms.
How Teams Are Actually Choosing
- Startups and MVPs tend to favor React Native or Flutter for speed of iteration and smaller team requirements.
- Content and e-commerce apps with standard UI patterns rarely need native development — the cross-platform frameworks handle these well.
- Apps with heavy camera, AR, or hardware integration often end up native, or hybrid — cross-platform for most screens with native modules for the demanding parts.
- Teams with existing web/React expertise often lean React Native to share knowledge and sometimes code with their web codebase.
- Teams prioritizing pixel-perfect design consistency across platforms often prefer Flutter.
What’s Changing the Calculus
The gap between cross-platform and native performance keeps narrowing. React Native’s new architecture and Flutter’s Impeller renderer have both addressed long-standing pain points. Meanwhile, native development tools like SwiftUI and Jetpack Compose have made native development itself faster and more declarative, closing some of the productivity gap that used to favor cross-platform frameworks.
The Honest Recommendation
There’s no universally correct answer. If your team already knows React, React Native is usually the pragmatic choice. If UI consistency and animation quality matter most and your team is willing to learn Dart, Flutter is compelling. If you’re building something performance-critical or deeply tied to platform-specific capabilities, native still wins. Most successful products today aren’t dogmatic about this — they choose based on the specific app, team skills, and timeline rather than ideology.