Flutter and cross-platform app development

A shared codebase is usually the right economic answer for a product shipping to both stores. It is not a universal one, and the places it stops paying off are predictable enough to check before you commit.

Cross-platform saves you the product code, which is most of the build. It does not save you the platform work: two store submissions, two sets of purchase plumbing, two permission models, two review processes. Budget for those separately and the economics hold up.

Where a shared codebase genuinely pays

The saving is real and it compounds after launch. One codebase means a bug is fixed once, a feature is written once, and the two platforms cannot drift apart into subtly different products, which is a failure mode that quietly costs far more than the original build.

• Products shipping to both stores where most of the value is in the interface and the data, not in platform capabilities.
• Small teams, where maintaining two native codebases means everything is half-staffed.
• Products still changing quickly, where writing every change twice slows learning as much as it costs money.
• Anything with a strong visual identity, since a shared rendering approach makes a custom design consistent across platforms rather than approximated on each.

Where it stops paying

The honest list is shorter than critics claim and longer than advocates admit.

• One platform only. A shared codebase then buys nothing and costs an extra layer to reason about.
• Deep platform integration. Widgets, complex background processing, unusual hardware access and system extensions all mean writing platform code anyway, and past a certain point you are maintaining three things rather than one.
• Demanding real-time work. Heavy media processing, low-latency audio and anything where you are fighting for frames.
• Teams that already have strong native engineers. Rewriting into an unfamiliar stack throws away expertise you are already paying for.

The part that is not shared, and gets underestimated

This is where cross-platform projects run late, and it is almost always the same list.

1. Store submission. Two consoles, two review processes, two sets of listings, screenshots and policy declarations.
2. In-app purchases and subscriptions. The two platforms model them differently, and restoring, upgrading and cancelling need testing on both.
3. Push notifications. Different delivery guarantees, different permission behaviour, and manufacturer battery management on Android that will stop background work.
4. Permissions. Different prompts, different timing, different consequences for asking at the wrong moment.
5. Platform conventions. Navigation, back behaviour, sharing and typography differ, and copying one platform's conventions onto the other is exactly what makes an app feel wrong.

A cross-platform app that feels cheap almost never feels that way because of the framework. It feels that way because one design was shipped to both platforms without anyone asking what each platform's users expect.

How we decide

During discovery, not before it. The questions that settle it are which platforms you actually need at launch, how much of the product depends on platform-specific capability, what has to happen while the app is closed, and whether you have or plan to have native engineers of your own.

For most consumer products shipping to both stores the answer is a shared codebase with native code where it earns its place. For a single-platform launch, or a product built around deep platform behaviour, we will say so.

What you get either way

Conventional architecture that another team could pick up, documentation that reflects what was actually built, an installable build every week, and ownership of the code, the design files and both store listings from the first day. If the stack is ever described to you as proprietary or in-house, that is the mechanism by which lock-in happens, and it is worth walking away from.