Note · 16 October 2026
Native or cross-platform: how we actually decide
There's no default answer. There is a short list of questions that gives one in about an hour.
Every founder asks it in the first call, usually with an answer already in mind. Someone told them Flutter is faster. Someone else told them real apps are Swift. Both were right about their own product and wrong about yours.
We don't have a house preference. We have a list of questions.
1. Does the experience depend on the platform?
Camera pipelines, background audio, widgets, watch apps, deep integration with the share sheet, HealthKit or Android intents. If the product's value lives in those details, native wins and it's not close. A cross-platform layer can reach most of them, but every bridge is a place where polish leaks out.
2. Is the interface mostly screens, lists and forms?
Dashboards, marketplaces, booking flows, social feeds. These are ninety percent layout and data, and the frameworks are excellent at that. Here cross-platform is usually the right call: one codebase, one team, both stores on the same day.
3. How many engineers will maintain it in a year?
Two native codebases means two sets of bugs, two review cycles, two people who understand each. If you'll have one engineer after we hand over, that engineer should be able to hold the whole app in their head. That argues for one codebase.
4. Where are your users?
If eighty percent are on iOS, you're not building an Android app. You're building an iOS app that also runs on Android, and that changes how much the second platform's rough edges matter. If it's an even split, those edges matter twice as much.
5. What happens when the framework ages?
Native APIs are the floor; they don't go away. Frameworks have good years and quiet years. We'd rather bet on a framework with a boring, well-funded roadmap than a clever one with a Discord.
What we end up recommending
- Consumer utilities and media-heavy apps: native, usually SwiftUI first.
- SaaS companions, marketplaces, internal tools: cross-platform, with the framework chosen by who'll maintain it.
- Anything with a serious web product alongside: we look hard at sharing logic across web and mobile before picking anything.
The honest version: we've built both and we'll keep building both. The decision takes about an hour in the Discovery Sprint and we write the reasoning into the brief, so when someone asks in a year why it's built this way, the answer isn't "the agency said so". It's a paragraph you can disagree with.
Fingersnap Labs
Written by the studio, from what we do every week. If something here doesn't match your experience, write to us. We'd rather update the note than defend it.
Your next product could be one snap away.
Tell us what you're building. We'll reply with how we'd approach it.