There are three main ways to build a mobile app today: separate native apps for iOS and Android, React Native, or Flutter. We have shipped work with both cross-platform options. Zeevan and KankreG, two D2C stores, are built with Expo, the React Native framework, and VeggieKing's customer and delivery-partner apps are built with Flutter. This is how we decide which one a project should use.
The three options in brief
- Native. Two codebases: Swift for iOS and Kotlin for Android. Each app uses its platform's own tools and interface components directly.
- React Native. One codebase in JavaScript or TypeScript, written with React. Expo adds tooling, routing and build services on top, and React Native for Web lets much of the same code run in a browser.
- Flutter. One codebase in Dart. Flutter has its own implementation of each interface control instead of using the system's, and its code compiles to native code.
When React Native with Expo fits
React Native suits teams that already work in React and TypeScript, and products that need a website and apps from shared code. Zeevan and KankreG are web storefronts built with Expo and Expo Router, so the same React Native code that serves the browser today can be extended into store apps later, without starting again.
- You need a website and mobile apps, and want to share screens and logic between them
- Your team, or the team that will maintain the product, knows React
- Most screens are standard: lists, forms, product pages and accounts
When Flutter fits
Flutter suits apps with a strongly branded interface that should look the same on every phone. Because Flutter draws its own controls, a design looks and behaves consistently across Android versions and manufacturers. VeggieKing's apps have custom festive themes, a floating cart bar, maps and live order tracking, and both the customer and delivery-partner apps are written in the same language and framework.
- The app is mobile first, and a website is a separate product or not needed
- The design is custom rather than close to standard iOS and Android screens
- You want one team to build and maintain more than one app
When native is worth the extra cost
Two native codebases cost more to build and maintain, so they need a reason. Good reasons include:
- Deep use of platform features: home-screen widgets, complex background work, advanced camera or audio, or augmented reality
- Needing new operating-system features on the day they ship
- An in-house team that already works natively on each platform
Questions we ask before choosing
- Which platform matters first: Android, iOS, the web, or all three?
- Do you need a website from the same code?
- Which phone features does the first release use: camera, location, background tasks, Bluetooth?
- Does the app need to work offline?
- Who will maintain it after launch, and what do they already know?
For most business apps, such as catalogues, carts, bookings and tracking, all three approaches are fast enough. Slow apps are usually slow because of large images, too many network calls or long lists that render every row at once, and no framework fixes those on its own.
What to do next
Read our mobile app development process, or see the stacks in practice in the VeggieKing and Zeevan case studies. If you are deciding for your own product, tell us what it has to do and we will recommend a starting point.