When a company decides to build an app for its employees or its customers, an early question comes up: do we build two separate apps, one for Android devices and another for iOS devices, or one app that runs on both?
The question isn’t only a technical one. It determines how many teams you need, how many times the same feature gets written, and how much each change costs after launch. Flutter is one of the options that answers it with a single app, and here we explain when it fits and when it doesn’t.
What one codebase for two platforms means
Flutter is a framework for building apps from a single codebase that runs on Android and iOS, and it also supports the web and desktop operating systems. The team writes the screens and the business rules once, and from them an app is built for each platform and published in that platform’s store.
For the decision-maker, the direct impact comes down to three things:
- Most of each feature is written and tested once, instead of being written twice in two different languages.
- One team knows the whole app, instead of two teams whose decisions may differ in the details.
- Identical behavior on both platforms: the same rules, the same field validation, and the same messages to the user.
This shows up in maintenance after launch more than in the build itself. Every bug fix, and every change to a business rule, is made once and reaches users on both platforms together, instead of one platform lagging behind the other.
On cost, a single app doesn’t mean the cost is automatically cut in half, but it does mean that most of the effort isn’t repeated. The design, the business rules, the connection to the server, and the core tests are built once, and the extra effort stays limited to what is specific to each platform.
But “one codebase” doesn’t quite mean “one job.” Each platform still has its own release settings, store requirements, and permissions, and the app needs testing on devices from both platforms, not just one of them.
When Flutter is a good fit
Flutter suits most business apps, because what these apps need sits at the core of what it offers:
- Forms and lists: entering orders, logging visits, viewing invoices and balances, and searching for items.
- A consistent interface: the screens look and work the same way on both platforms, so they’re easier to explain to employees, and employees are easier to support.
- Offline data: Flutter’s official documentation covers the pattern of an app that works offline, built on a local database that syncs with the server later.
- Arabic and text direction: through its official localization library, Flutter supports many languages and sets the interface direction, right to left or left to right, according to the selected language.
- Connecting to the company’s systems through an API, such as an ERP system or the existing sales system.
In the article “Systems that keep working when the internet drops: why it matters in our markets,” we covered the decisions on sync and conflict resolution. Choosing Flutter doesn’t change these decisions; what changes is that they’re written once for both platforms.
An Arabic interface needs deliberate care
The framework’s support for text direction is a starting point, not the finish line. A good Arabic interface needs deliberate decisions: which icons flip with the direction and which stay as they are, how Latin-script names and codes appear inside Arabic text, and how numbers, dates, and currencies are displayed.
That’s why we test the screens in Arabic from the first prototype, not after the app is finished in English and then translated. Arabic text may run longer or shorter than its English equivalent, and it may break a design built on the assumption of a single direction.
Suppose a distribution company wants an app for its sales reps: it shows the list of customers and items, records orders even offline, and sends them to the company’s system when the connection returns. Some of the reps carry Android devices and others carry iOS devices. This is a case that suits Flutter: clear business screens, an Arabic interface, local data, and one team managing the whole app.
When a native app may be the better fit
A native app is built separately for each platform, with that platform’s own tools and language. It may be the better fit in specific cases:
- When the app depends at its core on deep operating system features, such as tight integration with specialized hardware, or tasks that run in the background in a way each platform dictates differently.
- When the interface must follow each platform’s style down to the fine details, and differ significantly between Android and iOS.
- When new operating system features are needed as soon as they’re released, before a ready-made way to use them is available in Flutter.
- When your team already has experience in native development for each platform, along with existing apps that would be hard to rebuild.
The cost here is clear: building two apps means two teams, or one team working in two languages; every feature is written and tested twice; and every change needs coordination to reach both platforms at the same time. So this option is worth its cost when what it offers is essential to the app, not when it’s a general preference.
Even in these cases, the choice isn’t all or nothing. Flutter lets you write platform-specific code for a particular feature, in Kotlin or Java on Android and in Swift or Objective-C on iOS, and the app communicates with that code through channels called platform channels. Most of the app stays shared, and only the specific part is written separately for each platform.
What matters is knowing these specific parts before you start, not halfway through the project. Each of them means code that is written, tested, and maintained twice, and it has to be factored into the cost from the beginning.
Questions to ask before you choose
- Who will use the app, and on which devices? Does the company own the devices, or does each person use their own?
- What has to work offline, and what data is stored on the device?
- Does the app need device-specific features, such as the camera for scanning barcodes, location, or printing to a connected printer? Is there ready-made support for them in Flutter, or do they need platform-specific code?
- Is the interface in Arabic only or in several languages, and right to left only or in both directions?
- How will the app connect to your existing systems, and do they already have an API?
- Who will maintain the app after launch, and what experience does your team already have?
Written answers to these questions turn the discussion from technical preferences into clear requirements, which you can use to compare the options and their costs.
If doubt remains after answering them, a small prototype of one or two screens that includes the app’s hardest feature settles the question at a limited cost, before you commit to the whole project.
Also keep in mind that the app is part of a larger system. Core business rules, such as prices, permissions, and approvals, belong on the server, not in the app. This makes the framework decision less risky than it seems, because the core of the system isn’t tied to it.
A quick decision guide
- A business app with forms, lists, and reports, for users on Android and iOS, with an Arabic interface: Flutter is often a good choice.
- An app that works offline in the field and syncs with a central system: Flutter fits, provided the sync rules are settled before development.
- An app that needs one or two device-specific features: Flutter, with platform-specific code for those features only.
- An app whose core depends on a deep feature of one platform: start by evaluating a native app for that platform.
- An app whose interface must match each platform’s style precisely: compare the two options with a small prototype before deciding.
Choosing Flutter isn’t an isolated technical decision; it’s a decision that sets the cost of building and maintenance, and the size of the team, for the app’s entire life. When your case is a business app for both platforms with an Arabic interface, one codebase means features written once and changes that reach everyone together. You can discuss your situation with the ITS team, so that together we can determine whether Flutter is right for your app and which parts of it need platform-specific code.
Related serviceMobile apps