Flutter lets one team build an Android and an iPhone app, but not always without native code.
Building two phone apps twice is expensive. Flutter lets one team write the screens once and publish them to Android and iOS. For most business apps, such as bookings, orders and field forms, that saving is real and the result looks right.
The saving shrinks when an app leans hard on the phone itself. Bluetooth devices, background tracking and new system features still need native code. Flutter reaches them, but through a bridge that someone has to maintain for years.
Flutter is a toolkit from Google for building phone apps, and now web and desktop apps too, from one code base written in a language called Dart. It draws every button and animation itself instead of using the phone’s built-in parts. That is why an app looks identical on both platforms.
Where it earns its place.
What it is genuinely good at
- One code base for Android and iOS, with one team to hire and brief
- Custom interface design, because Flutter draws every pixel itself
- Smooth animation and transitions that feel the same on both phones
- Business apps made of lists, forms, maps and camera uploads
- Fast changes during development, since screens refresh as you edit
Where native code is still needed
Flutter does not use the phone’s own interface parts, so anything deeply tied to the phone’s system sits outside what it does well by itself.
- Bluetooth printers, scanners and other hardware, which often need native drivers
- Tracking that keeps running when the app is closed
- Brand new system features, which arrive in native tools first
- Apps that must look and behave exactly like the phone’s own settings screens
Flutter can call native code when it must. The honest cost is that you then maintain a Dart side and a native side for that feature.
Where we use it
- Customer apps for booking, ordering and following a delivery
- Staff apps for field visits, checklists and photo capture
- Apps with a strong custom look that a standard interface could not give
- Projects where a client wants one team to cover both stores
- Companion apps that sit beside a web system we also build
The upkeep behind a published app
A phone app is never finished. Both stores and both operating systems keep changing, and an untouched app gradually stops working.
- Flutter and package updates a few times a year, with a test pass after each
- Store rules and new device sizes, which force changes you did not plan
- Dart, a language that few of your other developers will already know
- Native plugins that stop being looked after by their authors
How a Flutter app fits with the rest
The app is only the screen on the phone. The data and the rules live on a server, which the app reaches over an API.
- A back end in Node.js, Laravel or similar, shared with your web app
- Firebase for push messages, sign-in or crash reports where they fit
- A web admin panel, often React, for staff to manage what the app shows
- Offline storage on the phone for places with a poor connection
When this is the right choice.
- You need Android and iOS apps and one budget to cover both
- The interface has a distinctive custom design that must match on every phone
- The app is mostly screens, forms, lists and maps rather than hardware
- A small team has to build and then maintain the app for years
- You do not already have a large web team that knows React
When it is not.
- An app built mainly around Bluetooth or background hardware, which is better written natively
- A team of React developers who could use React Native or Expo and share more skills
- A simple content app that a mobile-friendly website already serves well
- An app that must follow every new iOS or Android feature the week it appears
- An internal tool for a handful of staff, where a web app is much less to publish
Questions we are asked about it.
Is a Flutter app a real app, or just a website?
It is a real app, compiled for each phone and published through the usual stores. It is not a website in disguise. It draws its own screens, which is why it can feel smooth.
Flutter or React Native?
Flutter suits a strong custom design and a team starting fresh. React Native or Expo suits a team that already writes React and wants to reuse that knowledge. Both are sound, and the deciding factor is usually who will maintain the app.
Will it feel like a native app?
Mostly yes, because the animation and scrolling are smooth. Small differences can show, such as how a menu or a date picker behaves. For most business apps nobody using it notices.
Can Flutter work offline?
Yes. The app can keep data on the phone and send it to the server when a connection returns. That needs careful design, particularly for what happens when two people change the same record.
Do we need two teams for Android and iOS?
No, that is the point of Flutter. One team writes most of the app once. You may still need a little native work for certain features, and iOS publishing needs an Apple developer account.
What happens if Flutter is later abandoned?
Nobody can promise how any tool will age, so we do not. Your app code and the server behind it belong to you, and the back end is not tied to Flutter. Only the screens would need rebuilding.
Services that use it.
What it sits with.
Not sure Flutter is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements