One codebase, two app stores, without the second invoice
Flutter or React Native apps that ship to iOS and Android from one codebase, with native code only where the feature needs it. Faster to build, cheaper to keep up to date. MVP from €14,900.
Shared-code splitter: tick what your app needs
example model, not a quoteWhere the code lives example model
- Shared Dart, both stores80%
- iOS only, Swift11%
- Android only, Kotlin9%
Build cost example model
About 44% less to build, and every later change is made once. Example timeline: 7 weeks of build, then store review.
One codebase fits this app well.
About 80% of the code is shared. The rest is small platform glue: permissions, push setup and store configuration.
An example model to show the shape of the trade-off: effort per feature is a typical figure, and the "from" prices are used as floors. Your quote is written for your app after a short call. Watch the two phones: with Flutter both phones show exactly the same pixels, because Flutter draws the interface itself.
Flutter or React Native, side by side
Both are mature, both ship to both stores, and both let me drop into Swift or Kotlin when a feature needs it. Answer four questions and the table marks which column fits your situation.
Your developers already write
The interface should look
Code to share with a website
Custom animation or a heavily branded interface
| compare | Flutterby Google, open source | React Nativeby Meta, open source |
|---|---|---|
| Language | Dart, quick to pick up for anyone who knows Kotlin, Java or TypeScript. | TypeScript or JavaScript with React. |
| How it draws the screen | Its own rendering engine paints every pixel, so the app looks the same on every phone and OS version. | Real native iOS and Android controls, so the app follows each platform's look and behaviour. |
| Best when | The interface is brand-led, animated or must match pixel for pixel across platforms. | The app should feel like each platform, or a React team will maintain it. |
| Team fit | Good for teams new to mobile; one language for the whole app. | React developers feel at home from day one. |
| Web reuse | Little in practice: Flutter for the web suits app-like tools more than content sites. | API clients, validation and business logic can be shared with a React or Next.js site. |
| Native features | Platform channels to Swift and Kotlin, plus a large package library. | Native modules in Swift and Kotlin, plus the Expo tooling for builds. |
| Updates after launch | A store release for each change; third-party code push tools exist. | JavaScript-only changes can ship over the air within store rules; native changes need a store release. |
| Honest verdict | My usual pick for a new app with no existing code. | The better pick when you already run React on the web. |
Framework details change with each release; this reflects the stable versions in autumn 2026. Check the projects' own documentation for current features.
Send your feature list. You get the shared-code split, a framework recommendation and a fixed price in writing.
Get a cross-platform quoteNative code, only where it earns its place
A cross-platform app is still a real iOS app and a real Android app. These are the places I write Swift and Kotlin next to the shared code, and why.
Push and background work
Push certificates, notification channels and background modes are set per platform. Small, but each store checks them.
Bluetooth and sensors
Plugins cover common devices. Anything continuous or vendor-specific gets its own module and testing on the real hardware.
Widgets and watch
Home-screen widgets and Apple Watch apps run outside the shared engine, so they are written natively and read the app's data.
Payments and accounts
Physical goods use your normal payment provider; digital goods sold in the app need in-app purchase. Check the current store rules.
From prototype to both stores
Each phase has its own fixed price, so you can stop after any of them and keep what was made.
- 1
Prototype
A clickable version on your own phone in about two weeks, tested with real customers.
- 2
Framework call
Flutter or React Native, recommended in writing with the reasons, including any native modules.
- 3
Shared build
Two-week sprints. Test builds on TestFlight and Google Play internal testing after each one.
- 4
Native modules
Swift and Kotlin only for the features flagged in the quote, tested on real devices.
- 5
Both stores
Listings, privacy details and review. New personal Google Play accounts need a closed test first; check current policy.
Cross-platform packages
Proposed prices in euros, excluding VAT 25.5%. All prices.
Clickable prototype
Test the idea before paying for the build.
- Key flows as clickable screens
- Runs on your own phone
- Five short user tests
- Written build recommendation
Cross-platform MVP
One codebase, live on both stores.
- Flutter or React Native, your choice with my advice
- Login, core screens and your store or site API
- Push notifications and crash reporting
- Submitted to the App Store and Google Play
Publishing and care
Keep it building and on the stores.
- OS and framework upgrades
- Target API and SDK deadlines
- Store listings and releases
- See app care
Store fees are paid by you, from your own accounts: the Apple Developer Program is $99 a year and Google Play has a one-off $25 registration. Check current fees on the stores' own pages.
You own the code repository, both developer accounts and the signing keys from the first day. If the prototype shows that an app is not the right answer, you keep the prototype and the written recommendation, and the build is never started.
When I would not recommend cross-platform
One codebase is the right default for most business apps, not for all of them.
- 01Most of the app lives outside the shared code: an Apple Watch app, rich widgets or continuous Bluetooth. The splitter above shows this as a short shared bar.
- 02You already run separate, healthy iOS and Android codebases with their own developers. A third codebase adds work instead of removing it.
- 03Customers only need to look things up and buy. A fast website or installable web app may do; compare the options on the mobile apps page.
Questions about cross-platform apps
Flutter or React Native?
Both are mature and both ship to the App Store and Google Play. Flutter, written in Dart, draws its own interface, so screens look identical on both platforms. React Native, written in TypeScript, uses each platform's native controls and suits teams that already write React for the web. I recommend one in writing after the prototype.
Will a cross-platform app feel slow?
Not for typical business apps such as catalogues, accounts, bookings and checkouts, when built with care. Sluggishness usually comes from oversized images, too many network calls or long unoptimised lists rather than from the framework. I test every build on an older mid-range Android phone as well as a recent iPhone, before you see it.
When is native the better choice?
When the app lives close to the hardware or the operating system: continuous Bluetooth, heavy background location, complex widgets, an Apple Watch app, advanced camera processing or games. Also when you already have separate iOS and Android teams. The splitter on this page flags those features, and the quote says so plainly.
Get a cross-platform quote
A few lines about the app and who uses it are enough. You get a written reply with a fixed price for the first phase within one working day.
I am a web and store specialist who builds apps that connect to your store, site and server. Larger native work, such as a watch app, may be delivered with a vetted partner developer, under one contract and one point of contact. owner to confirm
Or email [email protected]
Pikselipolku is an independent studio and is not affiliated with Apple, Google or any other company named here.