Shipping Cross-Platform Without the Compromises
The cross-platform debate has quietened down, mostly because the answer got boring: for the large majority of business apps, one codebase is now the right call. The interesting question is no longer whether, but where the remaining gaps are and how you plan around them.
Where cross-platform is simply fine
Forms, lists, navigation, authentication, media playback, offline sync, push notifications. If your app is fundamentally a well-designed interface over an API — and most are — you will not find a user who can tell the difference, and you will ship in roughly half the time.
Where it still costs you
- Heavy real-time graphics or custom camera pipelines, where you will end up writing native modules anyway.
- Deep platform integrations that arrive on day one of a new OS release and take months to reach the bridge.
- Very large lists with complex cells, where native gives you performance headroom you have to work for otherwise.
- Apps where binary size is a hard constraint, since the runtime is not free.
Plan the escape hatch up front
The teams that get burned are the ones who assumed the whole app would be shared and had no plan for the parts that could not be. Structure the project so a native module is a normal thing to add rather than an emergency. If you know from the start that one screen will need platform-specific work, scope it that way and move on.
