Native vs. cross-platform: when React Native is the wrong call
Every founder building a mobile app faces the same question: should we build native apps for iOS and Android, or use a cross-platform framework like React Native or Flutter?
The conventional wisdom is that cross-platform saves money. You write the code once, it runs everywhere. This is true in the way that "you can sleep on a couch" is true. You can. It isn't the same experience.
The actual trade-off
Cross-platform frameworks abstract away the platform. That's their selling point and their cost. When the abstraction holds, you get two apps for the price of one. When it doesn't, you spend more time fighting the framework than you would have spent building natively.
The abstraction breaks in predictable places:
- Navigation patterns. iOS uses a navigation stack with swipe-to-go-back. Android uses a back button with different behavior. Cross-platform frameworks simulate both, and neither feels right to a daily user of that platform.
- System integrations. Widgets, Shortcuts, SharePlay, Live Activities, AirDrop, iCloud sync. Each of these is a native API with no cross-platform equivalent. If your app needs them, you're writing native code anyway, but now you're also maintaining a bridge layer.
- Performance-sensitive surfaces. Audio playback, video rendering, camera capture, real-time animation. Cross-platform layers add latency that native apps don't have.
- Design language. iOS 26 introduced Liquid Glass. Material 3 has its own motion and shape system. A cross-platform app that tries to match both will match neither. A cross-platform app that ignores both will feel foreign on every device.
When cross-platform works
Cross-platform is a reasonable choice when the app is essentially a web experience with a native wrapper. Content feeds, dashboards, forms, CRUD interfaces. If every screen is a list of cards that opens a detail view, React Native will serve you well.
It also works when you genuinely need Android parity from day one and your budget can't support two native builds. In that case, the trade-off is deliberate and the downsides are accepted.
When native wins
Native wins when the app is the product, not just a delivery mechanism for content. If people open your app every day, if they care about how it feels in their hand, if you're competing with apps that are already native, then native isn't a luxury. It's table stakes.
Building natively used to mean doubling the cost. You needed an iOS team and an Android team, each maintaining a separate codebase. That math has changed. With modern tooling, one person can build a native SwiftUI app in the time it used to take a team of four. The cost of native has come down dramatically; the downsides of cross-platform have not.
What we recommend
We specialize in Apple platforms: iOS, iPadOS, macOS. We build with SwiftUI, the framework Apple designed for its own apps. Our clients get apps that feel like they belong on the platform, because they use the same controls, animations, and patterns that every other native app uses.
If your users are primarily on Apple devices, there's no reason to compromise. A native app, built fast, will cost you less than you expect and feel better than any cross-platform alternative.
If you need Android coverage, we'll tell you. We aren't going to sell you a native iOS app when a cross-platform approach genuinely makes more sense for your situation. But in most cases, building an excellent iOS app first and adding Android later is cheaper and produces a better result than trying to ship both at once with a shared codebase.