Flutter App Development for UK Businesses: Why We Use It
Flutter app development explained for UK business owners: one codebase for iOS and Android, what it means for cost, speed, store accounts and upkeep.
Flutter app development means building your iPhone and Android app from one shared codebase instead of two separate ones. For most UK businesses commissioning a first app, that cuts the amount of code to write, test and maintain, which is why Flutter is our default for mobile apps. It is not the right answer for every app, and this guide explains where it fits, where it does not, and what it changes for you as the person paying for it.
Key takeaways
- Flutter is Google's open-source toolkit for building apps for iOS, Android, web and desktop from a single codebase, written in the Dart language.
- One codebase means one set of features to build, one set of bugs to fix and one team to brief, rather than an iOS team and an Android team.
- You still need two store accounts: Apple charges $99 a year and Google Play charges a one-time US$25 registration fee.
- New personal Google Play accounts must run a closed test with at least 12 testers for 14 days before going live, so build that into the launch plan.
- Flutter hot reload shows code changes in a running debug build while keeping the app's state, which shortens the build-and-check loop.
What is Flutter, in plain English?
Flutter is a software development kit made by Google. Its own project page on GitHub describes it as Google's SDK for building user experiences for mobile, web and desktop from a single codebase, and it is fully open source under the BSD-3-Clause licence. That licence matters to a business owner for one reason: the licence allows commercial use without a licence fee, and the source code is public.
Developers write Flutter apps in a language called Dart. The screens are built from small building blocks that Flutter calls widgets: a button, a list, a form field, a whole page. The same widget code runs on both iPhone and Android.
The official Flutter repository lists iOS, Android, web, Windows, macOS and Linux as targets. For most of our clients, the first two are what count. Web and desktop are useful extras, for example a simple admin screen that runs in a browser from the same code.
Why one codebase for iOS and Android matters to your budget
The traditional way to get an app on both platforms is to build it twice, once for each platform. Two codebases means two sets of developers, two rounds of testing for every feature and two places where a bug can hide. Changes after launch have to be made in both codebases.
With one codebase iOS and Android share the same screens, the same business logic and the same connection to your back end. In practice there is still some platform-specific work: app icons, permissions text, store listings, push notification setup and the occasional native plugin. But the bulk of the work, the part that changes every time you add a feature, is done once.
We cover the wider trade-offs in our guide to native vs cross-platform apps. The short version is that for business apps, the kind that show bookings, take orders, capture forms or let customers log in to an account, most features are the same on both platforms, so sharing code is usually worth weighing first.
Where the saving shows up
| Stage | Two native apps | One Flutter app |
|---|---|---|
| Design | Often adapted per platform | One design system, with platform tweaks where wanted |
| Building features | Each feature built twice | Each feature built once |
| Testing | Two apps to test end to end | One app, checked on both platforms |
| Bug fixes | Fixed and released twice | Usually fixed once, released to both stores |
| Team | iOS and Android specialists | One Flutter team |
We have deliberately not put a percentage on the saving. It depends on how much of your app is shared screens and logic, and how much is platform-specific. Your quote should break this down rather than quote a headline figure. Our guide to app development costs in the UK explains the other things that drive the price.
How Flutter speeds up building and changing your app
The feature developers talk about most is hot reload. According to the Flutter documentation, hot reload injects updated code into the running app and rebuilds the screen while keeping the app's current state. If a developer is adjusting the third step of a checkout, they can change the layout and see the result on that same step without starting again from the login screen.
For you, that shows up as quicker review cycles. Small layout or wording changes can be shown on a test phone quickly during a review session. The documentation is clear that this only works in debug mode during development, and that changes to native code need a full restart, so it is a development convenience rather than a way to update live apps.
It is worth separating two kinds of speed. Development speed is how fast the team can build and change features, and Flutter helps there. Store speed is how fast an update reaches customers' phones, and that is set by Apple and Google's review processes, not by the framework.
What Flutter does not change: stores, accounts and testing rules
A single codebase still produces two apps, and each one has to get through its own store. This part has nothing to do with the framework, so plan it early.
Apple App Store
To publish on the App Store you need a membership of the Apple Developer Program, which Apple lists at $99 per year. Apple's membership comparison page explains that membership is what gives access to App Store Connect for submitting apps and TestFlight for beta testing. A free Apple account lets a developer test on their own devices but does not allow App Store distribution.
We recommend the account is in your company's name, not your developer's. If you ever change agency, the app stays with you.
Google Play
Google Play charges a one-time registration fee of US$25, according to its developer account help page. The bigger planning point is testing. Google's testing requirements page states that personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers who stay opted in for 14 continuous days before applying for production access.
That is two weeks at minimum, and testers who drop out before the 14 days do not count. If your launch date is fixed, for example for a trade show or a seasonal campaign, plan the closed test into the timeline from the start. Google's page sets this rule for personal accounts, so check which account type you are registering.
Launch checklist for a first app
- Register the Apple Developer Program and Google Play accounts in the business name.
- Give your developer access through each store's team or user settings, not your own login.
- Prepare store listing text, screenshots, a privacy policy URL and support contact details.
- Recruit testers early if your Play account is subject to the closed testing rule.
- Agree who submits each release and who answers store review questions.
When is Flutter the wrong choice?
Flutter is our default, but not out of habit. There are cases where we would point you elsewhere.
- You do not need an app at all. If customers only need to view information or fill in a form occasionally, a fast mobile website may do the job for far less. Our post on app or mobile website helps you decide.
- The app is mostly one platform's newest hardware feature. Hot reload covers Dart code only; changes to native Kotlin, Java, Swift or Objective-C code need a full restart. If most of the app is native work, the benefit of a shared codebase shrinks.
- Your in-house team already maintains a native app. Rewriting a working app just to change framework rarely pays off. Adding features to what you have can be cheaper.
If none of those apply, and the app is a typical business tool such as bookings, ordering, customer accounts, job sheets for staff or a members area, Flutter is usually the sensible default.
Long-term maintenance: what you are signing up for
An app is not finished at launch. Apple and Google release new operating system versions, store rules change, and the libraries an app depends on release new versions. Someone has to keep up with that.
With Flutter, the shared code is updated in one project, then tested and released on both platforms.
Ask any agency these questions before you sign:
- Will the source code be in a repository we own, with access for us?
- Which third-party plugins does the app depend on, and who maintains them?
- What is included in ongoing support, and how are operating system updates handled?
- How long does a typical update take from request to store release?
The ongoing cost is the developer time to keep your app current with each new release.
Is a Flutter app agency right for your project?
If you are looking for a Flutter developer in the UK, look for evidence of apps actually released to both stores, not just demos. Ask to see one on your own phone. Ask how they handle the back end, because most business apps are only as good as the system they talk to: the booking database, the CRM, the stock system. An app agency that can also build and host that side saves you managing two suppliers.
That is how we work. We build Flutter apps alongside the custom web apps and portals they connect to, so the app, the admin screens and the data sit with one team. If you are still deciding which platform to prioritise, our guide to iOS or Android first is a useful read, though with Flutter the answer is often both at once. For a broader view of the process, see mobile app development in the UK.
Frequently asked questions
Is Flutter free to use for a commercial app?
Yes. Flutter is open source under the BSD-3-Clause licence, so there is no licence fee for using it in a commercial app. Your costs are development time, the Apple Developer Program membership, the Google Play registration fee, hosting for any back end and ongoing maintenance, not the framework itself.
Will a Flutter app feel different from a native app to my customers?
Because the app comes from a single codebase, the same screens ship to iPhone and Android. What customers judge is whether it is quick, clear and reliable, and that comes down to design and testing on real devices before launch. Ask to try a test build on your own phone, and on a colleague's phone running the other platform, before the app goes to the stores.
Can a Flutter app work with our existing website or CRM?
Usually, yes. If your website, CRM or booking system already has an API, the app can use it. If it does not, one needs building, and that work should be scoped and priced separately in any quote. Ask which data the app will read and write, and who maintains the connection.
How long does Google Play testing add to the launch?
For personal developer accounts created after 13 November 2023, Google requires a closed test with at least 12 testers opted in for 14 continuous days before production access. That adds at least two weeks. Planning testers early helps keep your launch date realistic.
Can we move a Flutter app to another developer later?
Yes, provided you own the source code, the store accounts and any back-end hosting. Flutter is open source with public documentation, so another competent Flutter developer can pick up a well-structured project. Make sure the contract states code ownership and that store accounts are registered in your business name.
Next steps for your first app
If you are commissioning a first app, start by writing down the three things customers or staff must be able to do on it, and what system holds the data behind those tasks. That list decides whether Flutter, a mobile website or a native app is the right fit. Then talk to us: see our mobile app development service, start a project for a scoped quote, or contact us.
