Rewriting My Flutter App to Native Android: A Side-by-Side Architecture Breakdown

I rewrote a Flutter app to native Android with Kotlin and Jetpack Compose — same features, same Supabase backend, completely different architecture. Here in the real code we address what got simpler, what got harder, and the build-time cost nobody warns you about. Flutter got my app to market fast on two platforms with one codebase. But after maintaining it for a while, I rewrote it — screen by screen, package by package — into native Android with Kotlin and Jetpack Compose. Not a plugin sunset, a full rewrite. This talk is a practical, code-level comparison of both codebases side by side: same app, same offline dataset, same Supabase backend, two completely different architectures. I'll walk through: - Dependencies as a map of the architecture - Dependency injection - State management - Concurrency - Navigation and theming - What native actually bought me - The trade-off nobody mentions This isn't a "Flutter bad, native good" talk. It's a grounded look at what changes — for better and worse — when you move the same product across two very different architectures, from someone who actually did the rewrite rather than theorized about it.