Choosing a stack by building in it
Building the same MVP in SwiftUI, Flutter and Kotlin Multiplatform before committing to one.
- Period
- 2026
- Scope
- 3 products · 7 builds
- Stack
- SwiftUI, Flutter, Kotlin Multiplatform
- Status
- Lumi live, FORQ in progress
Problem
"Which framework should I use?" is easy to argue about and hard to answer in the abstract. The honest answer depends on the app: how native it needs to feel, whether Android matters yet, and which platform features it leans on.
I wrote about this in Building an app before deciding its tech stack. This is what that looks like in practice.
Approach
When the stack isn't obvious, I build a small spike of the core screen in each candidate, usually in a day each. Each spike starts from the matching starter kit, so the spike is only the new part.
FORQ, a recipe manager. I built spikes in Kotlin Multiplatform, SwiftUI and Flutter. The deciding feature was import: paste a link from a recipe blog or a social post and get a clean, structured recipe. That pipeline is mostly networking and parsing, and it runs cheapest-first:
- Look for schema.org Recipe data in the page. It's free, it runs on the device, and it covers most recipe blogs.
- For social posts, fetch the caption, where creators actually put the recipe, and let the AI structure it.
- For other pages, send the page text to the AI.
- Fall back to an editable draft with the title and image, so the user never hits a dead end.
The Flutter version carried this best across both platforms, so it's the one being built out.
ReadMate, a book tracker. An older Flutter app, spiked in Kotlin Multiplatform to see what a native-UI rewrite would feel like.
Lumi, a reading companion. Lumi shipped first in SwiftUI. Once it was live, I rebuilt it in Flutter to reach Android, keeping the same bundle ID, design system, subscription setup and data keys, so existing users carried over. It also kept a native iOS home-screen widget written in Swift.
Outcome
- Lumi is live on the App Store, with the Flutter rebuild ready for Android
- FORQ picked Flutter on evidence, not on habit
- the Kotlin Multiplatform spikes were cheap, useful and deliberately thrown away
A spike you throw away isn't wasted. It's the cheapest way to turn an opinion into a decision.