Flutter app development: one codebase for iOS and Android

Most products we are asked to build need to live on iOS and Android. Not later. On the first release. Flutter app development is how we do that: one Dart codebase, two store listings, one team. The admin is React. Both sit on the same Supabase backend.

This is the studio default. It is not dogma. When the product belongs on Apple, we write it in Swift. The rest of this note is why Flutter is the default, what that actually means in 2026, and how Arabic and the stores are handled as work rather than as a checkbox.

What Flutter is, in 2026

Flutter is Google’s UI toolkit. You write widgets in Dart. A release build on a phone is compiled ahead of time to native ARM. The renderer on iOS is Impeller — it is the only renderer Apple builds get, with no Skia opt-out. On modern Android, Impeller is the default. The point of Impeller is predictable frame times: shaders are compiled at build time, not on the first animation. We do not claim it is faster than native. We do not invent a frame rate.

Material 3 is the default design system in the SDK. Cupertino exists for iOS chrome when a product needs it. In practice we ship a custom design system either way. The SDK copies of Material and Cupertino are being split out of Flutter itself. That matters for a product that will live for years: the design library becomes a dependency you pin, not a surprise inside the framework.

Why one codebase is the default

Two native teams are two design systems, two release trains, two places a bug can live. One Flutter codebase is one conversation. The saving is coordination, not a percentage we print in a brochure.

The mobile app is half the product. Operators do not live inside it. They live in a React admin on the same data. Flutter does not do everything. It does the phone. That split is the product, not a compromise.

When Flutter is the right call

Both stores matter from the first release. The UI is custom, not a clone of Settings. The product is bilingual, or Arabic-first. The work is booking, offers, groups, learning, a marketplace — the kinds of products we have already shipped. The scope is written. Weekly builds are something you can open.

That is most of the work that comes to this studio. It is why Flutter is the line on the homepage.

Arabic RTL is a layout problem

A Gulf product is not “add a translation file.” Locale sets direction. Direction sets padding, alignment, and which edge a chevron lives on. You use directional insets, not left and right. Arabic plurals are not singular and plural — they are zero, one, two, few, many, and other. Mixed runs of Arabic, English product names, and Western numerals have to be designed, then tested on a phone held in the right hand.

The font has to shape Arabic properly. Thmanyah does that work on this site. Inside an app the family is chosen for the product, but the rule is the same: a Latin-only font with an Arabic fallback is how a screen starts to look rented.

Xcode still needs the locales listed for the App Store language listing. Flutter’s localizations do not do that for you. Two checklists. One product. The depth of that work is a separate note.

Two stores, two checklists

The same codebase produces an IPA and an AAB. They do not share a review. Apple wants a complete binary, a demo account, screenshots that match, and a privacy nutrition label. Google Play wants a signed app bundle and, on a new personal developer account, a closed test before production. None of this is exotic. All of it is work that has to be on the schedule, not discovered in week twelve. The two checklists are their own note.

TestFlight is how an iOS build reaches you during the week. A Play internal or closed track is the Android equivalent. You review the real thing on both phones.

When we still write Swift

The product is Apple-only. Or it needs watchOS, visionOS, ARKit, HealthKit-class APIs, App Intents, lock-screen widgets — surfaces Flutter reaches through a plugin, late, or not at all. Then we write a native iOS app. That decision has its own note.

A Flutter app can embed a Swift module for one feature. That is a seam, not a strategy. If the product is the Apple surface, do not start in Flutter and hope.

What we have shipped

Six mobile products are on the site, described as they are, with nothing invented.

• Naqrah.app — clinic booking for Oman’s private healthcare market.
• T-CODE — nearby offers and a merchant dashboard, in Saudi Arabia.
• Jameyatek — a jam’iyya organizer that does not move money.
• Aalim — Quran reading, tafsir, and an on-device recitation check.
• Qassah — barbershop booking and a salon dashboard, in Saudi Arabia.
• AlMizan — legal consultations with licensed law offices, in Oman.

Read them as products: Naqrah.app, T-CODE, Jameyatek, Aalim, Qassah, AlMizan. The stack is how they were built. The work is what they do.

Default, not dogma

If both stores and one team: Flutter. If the product is Apple’s: Swift. Either way the operators get a web admin on the same backend, and if the customer is an organization rather than a single user, that product is multi-tenant from the first schema.

Write to us with the product. If Flutter is the wrong call, we will say so before you pay for it.