How it works
Instead of writing a separate app in each platform's own language, the team writes one app in a shared framework. Flutter uses the Dart language and draws its own interface. React Native uses JavaScript or TypeScript and maps to the platform's native interface components. In both cases the result is packaged as a normal app for each store. The alternative is a native app on each platform.
Benefits and trade-offs
| Benefit | Trade-off |
|---|---|
| One team and one codebase to maintain | New platform features can reach the framework later than the platform itself |
| Features and fixes reach both platforms together | Heavy graphics, advanced hardware access or background work may need native code |
| Often a faster route to a first release | App size and start-up speed can differ from a native app |
| Consistent design across devices | Some platform conventions need extra care to feel natural |
These trade-offs depend on the product, so compare the options against your own needs. Our article on native or cross-platform lays out the decision, and the Flutter and React Native pages describe how we work with each.
An example
Imagine a delivery company that needs a booking app for customers and a simpler app for drivers, both on iPhone and Android. A cross-platform framework lets one small team share most of the logic and interface between the two platforms, and add native code only for features such as background location. This is a hypothetical example, not our work.
Common mistakes
- Choosing a framework because it is fashionable, not because it fits the product.
- Assuming one design works unchanged on both platforms. Navigation and gestures differ.
- Forgetting right-to-left layouts, which need testing on real devices in Arabic.
- Ignoring store rules and testing on older phones.