Every new mobile project starts with the same debate. Some people on the call have read that cross-platform frameworks are now as good as native. Others have heard horror stories. Both camps are right about something, which is why we stopped arguing about technology and started asking about the product.
1. How much of the app is platform-specific?
If the app leans heavily on widgets, background tasks, Bluetooth, health data, camera processing or deep system integrations, native code will be needed anyway. At that point a cross-platform layer adds a second set of problems on top of the first.
2. Who will maintain it in two years?
A product owned by a small team benefits a lot from one shared codebase. A company planning separate iOS and Android teams may prefer native code that matches how those teams will work.
3. How fast do both platforms need to ship?
If both stores must launch on the same day with the same features, a shared codebase usually wins on cost. If one platform clearly matters more, starting native there and adding the second later is often cheaper overall.
- Mostly forms, lists and content: cross-platform is usually a safe choice.
- Heavy animation and custom gestures: both work, native is easier to polish.
- Deep hardware or OS features: native, or shared logic with native UI.
- A web version planned too: consider how much code can be shared with it.
What we deliver at the end of discovery
A two-page architecture note with our recommendation, the alternatives we rejected and why, and the risks we see. Clients sometimes choose differently from our recommendation. That is fine, as long as the choice is made with the trade-offs on the table.