Why We Rebuilt Wookie: From KMP to Flutter

Note: Some names and company-specific details have been generalized to protect confidentiality.

Wait, why did we even start this in the first place?

Kotlin Multiplatform (KMP) works great… right until the math stops working.

It was mid-2024. I was looking at our roadmap and realized we had a problem. The original KMP team was about to be pulled for a high-priority client project

This left me with a tough problem, KMP required developers who had KMP experience to maintain the shared code. There would be no one left behind?

So we started the rebuild in advance. It wasn’t a panic move yet. I had one senior and one junior (who had just trained in Flutter) start the migration as a background task. “Just in case,” I told myself.

Then the Tuesday morning from hell happened… 💀

We were right to start early. Because late in 2024, Xcode, requiring a yearly update, broke the codebase

We were preparing a routine release for Wookie. Suddenly, our build pipeline was NOT WORKING. The KMP bindings for iOS were broken.

• To fix it, we needed to update the Kotlin version.
• But updating Kotlin required updating KMP.
• But updating KMP required migrations which would then result to refactoring our shared business logic layers.

I stared at the error logs halfway through migration and realized: We were stuck halfway between a broken KMP app and an unfinished Flutter app.

The pivot (asking for the cavalry)

This was the catalyst

I didn’t use the breakage to start the rebuild—we’d already done that. I used it to get resources.

I sent an urgent message straight to the HR and CTO. “KMP is dead, the migration requires resources we don’t have. The Flutter rebuild is 40% done. If you want this app to survive, I need dedicated developers to finish the Flutter port ASAP.”

Because the breakage was so visible (and painful), I got the go signal. We got a new team, and what started as a “nice to have” background task became the main priority

Okay, let’s look at the math

In 2023, choosing KMP made sense. We had native mobile developers who needed to upskill in Kotlin and SwiftUI and wanted to share logic but keep their native UI tools (SwiftUI and Compose). Fair enough.

But by 2024, the constraints had completely shifted:

• Resource Crunch: We didn’t have a dedicated team anymore. We had a rotating cast of juniors and maintainers.
• Maintenance Cost: Every feature had to be implemented twice in the UI layer. One screen for iOS. One screen for Android. Bugs happened separately or twice.
• Onboarding Speed: Teaching a junior Swift and Kotlin and the KMP bridge took is impossible without prior native experience. Teaching them Flutter? several weeks.

I literally did the math,

The decision was painful but clear: Throw away the code.

The unplanned lucky break

We didn’t just stop development. We actually caught a huge break.

Not only did we get a client, we also got to rebuild the product in a more future proof manner

Why? Because it forced our hand. Without the developers who could debug obscure Gradle/Xcode interop issues, KMP was unsustainable. It proved my earlier fear If the tool requires specialized expertise to maintain, it’s the wrong tool for a rotating team.

How we migrated 10,000 lines of code without dying

We didn’t do a “Big Bang” rewrite. We went smart

We kept the backend exactly the same. Because we used Supabase, the database, auth, and real-time logic were already decoupled from the client.

Phase 1: The Zombie App. We kept the KMP app running in maintenance mode. No new features.

Phase 2: The Shadow Build. We onboarded 4 new trainees from our internship program (started in 2024). Their first task? “Test the codebase and check for issues against the current Production app”

One of the original leads (Geremy Ubaldo) and a team member (Margaux Padiwan) volunteered to guide the new team while still on their client project. Their knowledge sharing and PR reviews made the transition significantly faster.

Phase 3: The Swap. Because the backend logic was identical, we could switch all the users by just releasing a new build with the same package identities

So, did Flutter win?

Yes. But not because it’s “better technology.”

KMP is nice if you have a large, stable team of native engineers who need deep OS integration and a fully native UI/UX. But for a tool maintained by a rotating team? Flutter is king.

Today, Wookie runs from a single repository. They can pull a random junior off the bench, give them a Dart crash course, and have them shipping features and fixes in days, not weeks.

The honest truth

Tech stack decisions aren’t about “Right vs. Wrong.” They’re about “Matches your constraints” vs. “Doesn’t.”

In 2023, KMP matched our team. In 2024, it didn’t.

The best engineers aren’t loyal to tools. They’re loyal to reality.

---

Related:

• Wookie: The Complete Story
• Teaching Frontend Devs to Build Backends