One codebaseor two natives?Choose wisely.
Flutter, React Native, or Swift + Kotlin for your first app.
The short version
For most first versions, you want one codebase (cross-platform) or one platform - not two full native apps. Dual native iOS and Android before product-market fit is one of the fastest ways to burn budget without learning more about your customers.
Not sure what belongs in v1? Start with pre-build validation, then MVP scope and design and prototyping before you lock a stack in a statement of work. Choosing an agency? Read our red-flag checklist first.
Why this decision matters before line one of code
I have reviewed hundreds of agency proposals and stack debates over 15 years. The pattern is consistent: founders who win their first release are ruthless about scope and realistic about platform. Founders who struggle often signed for two native apps, a heavy backend, and a feature list that belonged in year two - before anyone paid.
Platform choice is not a badge of quality. It is a budget and learning decision. The right answer is the one that gets you evidence that people will pay - with enough left in the bank to iterate when the first version is wrong (and it often is).
Definitions: native, cross-platform, and web
Agencies throw these terms around in proposals. Here is what they actually mean for your wallet and timeline.
Native (iOS and Android separate)
iOS built in Swift (or SwiftUI). Android built in Kotlin. Two codebases, two release pipelines, two sets of bugs. Maximum control over each platform; maximum cost for the same feature set on both.
Cross-platform (one codebase, two stores)
One shared codebase - commonly Flutter or React Native - compiled or bundled to iOS and Android. One team maintains core features once. Trade-off: some platform-specific polish takes extra effort; very exotic OS features may need native modules.
Web app / PWA (browser-first)
Runs in the browser; can be “installed” on home screens with progressive web app techniques. Often 20-30% cheaper than store apps for content-heavy or B2B tools. Weak fit when you need App Store discovery, push notifications at scale, or deep device APIs out of the box.
When cross-platform wins (especially for v1)
Cross-platform is not a compromise for lazy teams. For many MVPs it is the rational default.
- You need iOS and Android but the core flows are the same (signup, paywall, list/detail, bookings, messaging-lite).
- Small team or fixed budget - you cannot fund two senior native developers for six months before launch.
- B2B tools, marketplaces, SaaS-style apps where UX parity matters more than platform gimmicks.
- You are validating - speed to learning beats perfect per-platform animation.
We often recommend Flutter for greenfield MVPs when both stores are in scope: strong UI consistency, one language (Dart), and predictable performance for typical product apps.
“If a developer or agency tells you to build separate native iOS and Android apps as your first version, ask why - it is often not the most efficient or best use of your money, especially for new products that don't yet have market validation.”
Zinnia O'Brien, on tech stack conversations with founders.
When native wins
Native is the right tool when the product - not the agency pitch deck - demands it.
- Deep platform APIs - health data, advanced AR, complex background processing, or OS features that cross-platform bridges do not support cleanly yet.
- Performance-critical experiences - games, real-time creative tools, or apps where frame rate and latency are the product.
- Mature product, clear platform strategy - you already have revenue and a roadmap that differs materially on iOS vs Android.
- Single-platform launch - native Swift for iOS-only in AU/NZ is valid when Android can wait until you have proof; that is still native, but not dual native.
What it costs: cross-platform vs dual native
Platform choice is one of the six levers that move your total build number. On comparable feature scope, our project data lines up with what we publish in the app development cost guide for Australia:
| Approach | Typical cost impact | Best for |
|---|---|---|
| Cross-platform (Flutter / RN) | ~30-40% savings vs dual native | Most first-time MVPs on both stores |
| iOS or Android only | Baseline | Validating on one market first |
| Both native | 70-90% more than one platform | Mature apps with platform-specific roadmaps |
The bigger savings on most founder projects still come from validating before you build and scoping v1 to what users will pay for - not from framework religion. A lean cross-platform MVP beats a bloated dual-native build every time.
Scope your v1 before you pick a stack
Stack debates are easier once you know what actually ships. Start with pre-build validation, then our app design and MVP scoping phase locks features, flows, and technical assumptions so quotes compare apples to apples.
Red flag: dual native mandated for v1 with no user base
If your proposal assumes separate Swift and Kotlin teams, full parity on both stores, and a six-figure budget - but you have not validated demand or payment intent - pause.
Ask what you learn by spending twice as much on code that you could learn with one cross-platform build or one platform first. Often the honest answer is “the agency's standard template,” not your business need.
The expensive mistake is usually not the hourly rate - it is scope inflation. Dual native for an unproven idea is a classic example: you fund two full codebases before you know if anyone will pay. See our agency red-flag guide before you sign.
5-question decision worksheet (use before your RFP)
Answer these in writing - yourself or with a trusted advisor - before you compare agency quotes. If the proposal contradicts your answers, that is the conversation worth having.
Do you have paying users or strong payment intent on both iOS and Android today?
If no, you probably do not need dual native yet.
Does your v1 depend on platform-only APIs (HealthKit, ARKit, advanced background modes, etc.)?
Heavy platform hooks favour native or a very targeted single-platform launch.
Is your core app experience the same on both platforms, or materially different per OS?
Similar UX across platforms favours cross-platform; divergent UX may justify separate builds later.
What is your realistic v1 budget and timeline?
Map options against our cost guide - dual native rarely fits a lean validation budget.
Who owns the codebase and repo if you change agencies?
Stack choice matters less than clear IP, handover, and documentation in the contract.
Our default for first-time founders (and experienced app entrepreneurs too)
Validate the problem and offer first via pre-build validation. Scope v1 to one core job and one primary metric. Then choose cross-platform or a single native platform unless you have a documented technical reason not to. Revisit native splits when revenue and roadmap justify them.
That sequence is how we run app design and MVP builds for founders in Australia, New Zealand, and globally - design and specs locked before development, so stack choice serves the product instead of the other way around.
FAQ
Should my first app be cross-platform or native?
Is Flutter or React Native as good as native apps?
How much does cross-platform save vs building iOS and Android natively?
When should I build native iOS and Android separately?
Can I start cross-platform and move to native later?
Picking a stack for your first app?
Book a free strategy session. We will pressure-test your v1 scope, platform choice, and budget against what we have seen work in practice - no obligation to build with us.
Compare costs: App development cost in Australia (2026)