Almost every prospective client asks some version of the same question early on: "Should we just build this in Flutter or React Native so it works on Android too?" It's a reasonable thing to ask — one codebase for two platforms sounds like it should always win on cost. In practice, for the kind of apps we build, it usually doesn't.
The pitch cross-platform makes
The argument is straightforward: write your UI and business logic once, compile it to both iOS and Android, and ship both from a single team and a single codebase. For a certain shape of product — internal tools, content-driven apps that are mostly a UI on top of an API, MVPs that need to validate a market fast on a tight budget — that trade is genuinely worth making. We're not against cross-platform frameworks on principle. We just don't think they're the right tool for what we build, which is apps that live or die on how they feel.
Where it breaks down
The gap between "runs on iOS" and "feels like an iOS app" is where cross-platform frameworks struggle, and it shows up in a few specific places:
- New platform features arrive late, if at all. When Apple ships something new — Live Activities, interactive widgets, StoreKit changes, a new SwiftUI API — native apps can adopt it the same week. Cross-platform frameworks need their own bridge or plugin for it first, and for anything niche, that bridge sometimes never gets built.
- Performance on older or smaller devices. This matters most on watchOS, where we ship several apps. A cross-platform runtime layer adds overhead that's easy to ignore on a new iPhone and very hard to ignore on an Apple Watch.
- Platform conventions are approximated, not inherited. Native gestures, haptics, accessibility behavior, dark mode transitions, keyboard handling — SwiftUI and UIKit give you these for free, tuned by Apple. A cross-platform UI toolkit has to reimplement all of it, and small inconsistencies accumulate into an app that feels slightly foreign even when nothing is technically broken.
- Debugging gets a second layer. A crash or a layout bug can originate in your code, in the framework's bridge, or in how the bridge talks to the native platform underneath it. Native debugging tools point straight at your code.
When cross-platform genuinely makes sense
To be fair to the other side: if you need Android and iOS on day one, have a small team, and the app's success depends more on shipping fast than on how refined the interactions feel, a cross-platform framework can be the right call. Plenty of good products are built that way. It's a real trade-off, not a mistake to be corrected — it's just a different bet than the one we make.
What native buys you
Every app in our portfolio is built the way we'd want an app we use daily to be built: Swift and SwiftUI, targeting iOS (and watchOS, where relevant) directly, with no translation layer between the code and the platform. That means new OS features are available the day Apple ships them, performance stays smooth on older hardware without extra tuning, and the details that make an app feel "native" — the way a sheet resists being dragged closed, the exact spring curve on a transition — come from the platform itself instead of being approximated.
It also means a smaller, more focused codebase. There's no bridge layer to keep in sync with two operating systems' release cycles, no plugin ecosystem to vet for every native capability the app needs. For apps meant to run for years and get updated as iOS evolves, that maintainability difference compounds.
If you're deciding between native and cross-platform for a new app, the honest answer depends on what you're optimizing for. If it's speed to a multi-platform MVP, cross-platform is a fair bet. If it's an app that has to feel unmistakably like it belongs on the device it's running on — which is the case for most of what we build — native is the one we'd choose every time.