Choosing a mobile technology is not a matter of belief; it is a decision made by looking at what the product needs. Here are the questions we ask.
Key takeaways
- For most products Flutter gets you onto two platforms sooner with a single codebase.
- Native is the better choice for products with heavy hardware use and platform-specific experiences.
- The decision should follow where the product will be in two years, not the technology's popularity.
- The two approaches can also be used together.
In this article6 sections
"Should we build the app natively or with Flutter?" comes up in the first meeting of almost every mobile project. You can find persuasive articles online for both sides. We answer this question by looking at the product, not at our own preference. We ship products with both approaches, and each is right in some situations.
Terms first
Native means writing two separate apps, in Swift for iOS and Kotlin for Android. Flutter produces apps for both platforms from a single codebase. The first gives direct access to everything the platform offers; the second cuts development time and maintenance load.
The four questions we ask
- How hard does the product push the device hardware? For needs such as real-time video processing, complex Bluetooth communication, continuous background location or augmented reality, native is safer ground.
- Do you need to launch on both platforms at once? If getting to market quickly with the same experience on both platforms is the priority, Flutter gives a clear time advantage.
- How much is the interface your own? If you want a brand-specific, platform-independent visual language, Flutter draws it once. If the app must follow each platform's standard behaviour exactly, native pulls ahead.
- Who will develop the app two years from now? If you plan to build your own team, that team's skills directly affect the decision.
When Flutter is right
The great majority of booking, ordering, content, community and business process apps fall into this group. With a single codebase a feature goes live on both platforms the same day, and a bug is fixed once. In products like these the performance difference is not something users notice.
When native is right
We choose native when the product's core value comes from the device itself: camera and sensor-heavy apps, deep integration with wearables, products that must use new operating system features from day one. Here the cost of two codebases is reasonable next to the control you gain.
Both together
The decision is often not either-or. You can add native modules to a Flutter app only where they are needed. Most of the app stays in one codebase, and the small part that works close to the hardware is written per platform.
Conclusion
The right technology is the one that fits your product's needs and your roadmap. We make this decision during discovery, by talking about where the product will be in two years. The cost of the wrong choice shows up not in the first release but in the third.
