Answer 12 questions about your product, team and constraints. You get a recommendation with the reasons shown, how cost and the first release compare with native, and what to watch out for.
Pick my stack
The picker shows which stack fits your answers best and what tipped the balance. Cost and time are relative to native and based on our published articles; they are planning guides, not a quote. We build in all five stacks, so the result follows your answers, not our preference.
Each answer adds points to some stacks and removes points from others, from −2 to +2. The points are multiplied by the weight of the question (1 to 3) and added up. The total is scaled to a 0–100 fit score. “Not sure” answers add nothing and lower the confidence; they are left out of the scale, so they do not drag scores toward the middle.
Some answers set hard limits. If the app needs Bluetooth in the background, health data, widgets, NFC, CarPlay or a custom camera, a PWA is capped at 20: a web app cannot reach these capabilities the way a native app does. Softer limits take a few points off and are shown as things to watch.
Confidence is high when the leader is 12 or more points ahead and you were sure about almost everything. When the top two are within 6 points, the picker says so: you have two close options, and the choice comes down to your team and roadmap.
| Question | Weight |
|---|---|
| Which platforms do you need at launch? | 3 |
| What kind of product is it? | 2 |
| What should the interface feel like? | 2 |
| Which device capabilities does the app need? | 3 |
| How should the app work without a connection? | 1 |
| Security and compliance requirements | 1 |
| Which skills does your team already have? | 3 |
| What do you already have? | 2 |
| How will people get the app? | 2 |
| When do you need the first release? | 2 |
| What matters more for the budget? | 2 |
| How long should the app live without a rebuild? | 1 |
| Stack | When | Effect |
|---|---|---|
| PWA | The app needs Bluetooth in the background, AR or a custom camera, health data, widgets or watch apps, NFC or CarPlay | capped at 20 · Not suited: a PWA cannot reach this device capability the way a native app does. |
| PWA | The app must be in App Store and Google Play | −10 points · A store listing needs a wrapper (Capacitor or Trusted Web Activity). |
| PWA | Offline-first with sync | −8 points · Offline storage for web apps on iOS is limited and can be cleared by the system. |
| Native iOS + Android | First release within 3 months and lowest cost | −10 points · Two codebases rarely fit a 3-month, lowest-cost brief. |
| Kotlin Multiplatform | No Kotlin skills in the team and no vendor | −8 points · Needs Kotlin skills in the team. |
| Kotlin Multiplatform | First release within 3 months | −6 points · Younger ecosystem: plan extra time. |
| Flutter | Web is needed and the product is content or media | −8 points · Flutter on the web is weaker for search-driven content. |
| React Native | Graphics-heavy or game-like product | −8 points · For rendering-heavy UI, Flutter or native fit better. |
Flutter / Dart: one codebase for iOS and Android, plus web and desktop
Google’s UI toolkit in Dart. It draws every pixel itself, so a custom brand design and animation look the same on iOS and Android. One team, one codebase, and web and desktop builds from the same code. The trade-offs: a smaller hiring pool than JavaScript, and new platform features arrive through plugins, sometimes later.
React Native (incl. Expo): JavaScript / TypeScript, native UI components
Meta’s framework in JavaScript or TypeScript, with Expo as the default toolchain and the new architecture on by default. It renders real platform components, so standard screens look at home on each OS. It shines when your team already writes React or when the app shares logic with a web product. Heavy custom graphics are its weaker side.
Swift / SwiftUI for iOS and Kotlin / Compose for Android: two codebases
Two apps, each in the platform’s own language and UI toolkit. You get every new OS feature on day one, the best access to hardware such as Bluetooth, health data, widgets and the camera, and the most familiar feel. The price is two codebases: roughly 1.4–1.8 times the build cost of a cross-platform app and two teams to keep in step.
Kotlin Multiplatform: shared business logic, native or Compose Multiplatform UI
Shares business logic, networking and data in Kotlin while each platform keeps a native UI, or uses Compose Multiplatform for shared screens. It suits teams that already have native apps or Android engineers and want less duplication without a full rewrite. The ecosystem is younger, so plan extra time for tooling and iOS integration.
Progressive Web App, optionally packaged with Capacitor or TWA for the stores
A web app that installs to the home screen and works offline within browser limits. It is the cheapest and fastest route when a link or QR code is enough and the app is mostly content and forms. On iOS, push, background work, storage and device access are more limited than in a native app, and store listings need a wrapper.
| Source | What we take from it |
|---|---|
| Native vs cross-platform app development in 2026 | Cross-platform costs 55–70% of native; the first release is 30–40% faster; native takes 8–14 weeks |
| Web app vs native vs PWA in 2026 | A PWA takes 5–8 weeks and $40–100k versus $80–250k for native; PWA limits on iOS |
| Mobile app maintenance cost in 2026 | Maintenance is 15–25% of the build cost a year and 30–50% in year one; cross-platform is 20–35% cheaper to maintain |
| React Native vs Flutter in 2026 | Where each framework fits, and where Kotlin Multiplatform comes in |
Kotlin Multiplatform and PWA values are our estimates between the published figures and are pending review by our mobile lead.
It depends on your team and interface. React Native fits teams that already write React or share code with a web app; Flutter fits custom brand design and animation. The picker weighs both against your answers, and our React Native vs Flutter comparison goes deeper.
When the app depends on platform capabilities such as Bluetooth in the background, health data, widgets, CarPlay or a custom camera, when it must feel exactly like the OS, or when strict security and a long lifespan matter more than build cost. It is also the natural choice for a single platform.
Kotlin Multiplatform shares business logic between iOS and Android while each keeps a native interface. It suits teams with existing native apps or Android engineers who want less duplicated code without rewriting everything. The ecosystem is younger, so plan extra time.
Often yes for content, forms and internal tools that people open from a link. On iOS, web apps have tighter limits on push, background work, storage and device access, and in the EU iOS support for home-screen web apps has changed with the Digital Markets Act. Check the current behaviour before you commit.
Flutter and React Native usually cost 55–70% of two native apps, so you save 30–45%. The more platform-specific code the app needs, the smaller the saving. The picker adjusts the figure to your answers and shows the range.
From our projects: native takes 8–14 weeks, Flutter and React Native are 30–40% faster at about 5–9 weeks, and a PWA takes 5–8 weeks. Kotlin Multiplatform sits in between. Scope moves these numbers more than the stack does.
Each answer adds or removes points for each stack, weighted by how much the question matters. Hard limits cap a stack that cannot meet a requirement. The section “How the picker decides” above lists every question, weight and limit.
Yes. We build in Flutter, React Native, native Swift and Kotlin, Kotlin Multiplatform and as web apps. That is why the picker shows its reasoning instead of pushing one option.
One codebase for iOS, Android and the web.
Mobile apps for teams that already work in React.
Native Swift and SwiftUI apps.
Native Kotlin and Jetpack Compose apps.
From the first prototype to store release and support.