Home Services Use cases Blog Company Contact Get in touch

One codebase for iOS and Android: when Flutter makes sense.

Flutter lets you build one app that runs on both major mobile platforms. Here is an honest look at when that is the right choice — and what to plan for beyond the screens.

A laptop showing code next to a smartphone

If you need a mobile app for your customers, field technicians or internal team, one of the first decisions is how to build it. Two separate native apps — one for iOS, one for Android — or one shared codebase with a cross-platform framework like Flutter? Both are valid. The right answer depends on what the app needs to do and how you plan to maintain it.

What Flutter is, in one paragraph

Flutter is an open-source framework from Google for building apps from a single codebase written in the Dart language. It draws its own interface, so the app looks and behaves consistently on iOS and Android, and it compiles to native code for good performance. Platform-specific features are reached through plugins or, when needed, small pieces of native code.

Where Flutter shines

  • One team, one codebase — features, fixes and design changes are made once and shipped to both platforms.
  • Consistent look and behaviour — the app feels the same to every user, which simplifies support and training.
  • Fast iteration — hot reload makes it quick to adjust screens and try ideas during development.
  • Lower long-term maintenance — one codebase to update, test and keep secure instead of two.
  • Good fit for business apps — forms, lists, dashboards, maps, scanning and data entry are all well supported.

Where to be careful

  • Very new platform features — when Apple or Google release something new, native apps get it first; Flutter plugins may follow later.
  • Heavy platform-specific work — apps built around deep system integration (for example specialised background processing or unusual hardware) may need significant native code anyway.
  • App size — Flutter apps are typically somewhat larger than minimal native apps, which rarely matters but is worth knowing.
  • Plugin quality varies — well-maintained plugins exist for most needs, but each dependency should be checked before relying on it.

For most business and customer-facing apps, the advantages outweigh these points. For highly specialised apps, a native approach — or Flutter with dedicated native modules — may be better.

The app is only half of it: backend and sensors

Most useful apps talk to something: your ERP, a customer database, a booking system or devices in the field. Plan these connections early:

  • Backend and APIs — a secure API (REST or GraphQL) that the app uses, with authentication and clear permissions.
  • Integration with existing systems — the backend connects to your ERP or CRM so the app shows real, current data.
  • Sensors and devices — camera, barcode scanning, GPS, Bluetooth devices or other sensors are reachable through plugins or native code.

Offline mode

Warehouses, basements, construction sites and rural roads all have weak signal. If people use the app on the move, decide up front what must work offline. A typical approach: store needed data locally, queue changes made offline, and sync them when the connection returns — with clear rules for what happens if the same record was changed in two places.

Push notifications

Notifications are useful for new tasks, status changes or reminders, but they need a plan: which events trigger them, who receives them, and how users control them. Technically, they go through Apple's and Google's notification services, so the backend must be set up to send them reliably.

Publishing to the App Store and Google Play

Getting an app into the stores involves more than uploading a file:

  • developer accounts for Apple and Google in your company's name,
  • store listings with descriptions, screenshots and a privacy policy,
  • answering data-usage questions in each store honestly and accurately,
  • passing the review process, which can raise questions and take some time,
  • internal or private distribution if the app is only for employees.

After launch, both platforms regularly update their requirements, so plan for ongoing updates as part of maintenance and support.

In short

  1. Flutter fits most business and customer apps: one codebase, both platforms
  2. Consider native for apps built around very specialised platform features
  3. Plan the backend and system integrations from the start
  4. Decide early what must work offline
  5. Budget time for store publishing and ongoing updates

How int32 can help

We build mobile apps in Flutter, including the backend, integration with your systems and sensors, push notifications, offline mode and publishing to the App Store and Google Play. Read more about our mobile applications and business software, or get in touch and describe the app you have in mind.

Tell us about the app you have in mind.

We'll get back to you with suggested next steps — no obligation.