Journal — 02 Mobile

All notes

React Native or native? An honest decision tree

We build most apps cross-platform. Here are the specific cases where we tell clients to go native instead.

We build the majority of our mobile work in React Native, and we'll happily argue for it. But "cross-platform is fine now" has become the kind of received wisdom that stops people checking whether it's true for their app. Sometimes it isn't, and finding out in month four is expensive.

Go native when…

The app is the graphics

Video editors, camera apps with custom capture pipelines, AR, games — anything doing per-frame work on image buffers. You can bridge to native modules for this, but once the interesting half of your app lives behind a bridge you've taken on cross-platform's costs without its benefits.

You need new OS features on day one

If shipping against the newest iOS APIs the week they land is part of your value proposition — widgets, Live Activities, new sensor access — you'll spend your life waiting on library support.

The platforms genuinely differ

Sometimes the iOS and Android versions should behave differently enough that sharing UI code saves nothing. If your shared-code estimate is under about 60%, the abstraction costs more than it returns.

You already have the team

If you employ two strong iOS engineers, do not make them learn React Native for the sake of architectural tidiness. The best stack is frequently the one your people are fastest in.

Go cross-platform when…

  • The app is mostly screens, lists, forms and network calls. Which describes most business software, marketplaces, booking tools and content apps.
  • You need both platforms at once on one budget. The most common reason, and a good one.
  • Your team is already strong in TypeScript. The shared language matters more than people expect — types can be shared between the API and the app.
  • You want over-the-air updates. Pushing a fix in an hour instead of waiting on review is a genuine operational advantage.

The trap in the middle

The worst outcome isn't picking wrong — it's picking cross-platform and then fighting it. Teams try to make React Native produce pixel-identical output on both platforms, reimplement platform navigation by hand, and rebuild native components to match a design that assumed the web. You end up maintaining the bugs of three platforms.

If you go cross-platform, use the platform. Let iOS look like iOS. Use the system navigation patterns, the system date picker, the system share sheet. The apps that feel cheapest are the ones fighting hardest to hide what they're built with.

What we actually recommend

For about eight out of ten projects that come to us: React Native, with native modules where a specific feature demands it. For the other two, we say so in discovery, before anyone has signed anything — usually because of the graphics test above.


Next: Shipping an LLM feature you can actually maintain
Next step

Tell us what you're working on. You'll get a straight answer on scope, timeline and cost within one business day — including if we're not the right studio for it.

hello@veyonlabs.com