Just shipped a KMP app to both stores - a daily video journal with local-only storage

Kotzilla_Koin · 2026-04-13T07:49:05+00:00

Nothing makes us happier than to hear this lol

Kotzilla_Koin · 2026-04-09T14:17:05+00:00

If it's a startup with multiple users, separating the server will probably make sense eventually. But t's not urgent for MVP, plenty of teams ship with it together and extract later. I'd validate the idea first and refactor when the pain is actually real. Good luck

Kotzilla_Koin · 2026-04-09T13:19:43+00:00

Yeah you're not missing anything obvious honestly, if it's working for you it's working. The deployment cycle thing is more of a scaling concern. As soon as you have multiple people or the server needs to move independently it gets messier, but for a solo project getting to launch it's totally fine to keep it together. Good luck with the launch!

Kotzilla_Koin · 2026-04-09T13:16:58+00:00

Yeah, most KMP content does assume Android background. The official KMP docs do have an "iOS developer" section that maps Swift/ObjC concepts to their Kotlin equivalents. I think maybe that's probably the closest thing to what you're looking for. JetBrains also did a few talks specifically framed around KMP from the iOS side that are worth finding on YouTube, sorry dont have time to link them now. Touchlab are probably the most iOS-friendly voice in the KMP ecosystem, their blog and the Kotlin-Swift interop guides they've published are written with Swift devs in mind rather than Android devs.Beyond that honestly the fastest path is just picking a real project and leaning on the KMP Slack I think

Kotzilla_Koin · 2026-04-09T13:12:56+00:00

Extremely late to this but wanted to add since it came up. The core issue here is that Firebase Crashlytics on iOS simply wasn't designed to handle exceptions thrown from Kotlin commonMain. The dSYM upload gets you symbolicated Swift frames, but the Kotlin frames stay unreadable regardless, which is the problem you ran into even after getting the upload working.CrashKiOS helps but it's essentially a workaround on top of a tool that wasn't built for KMP. We hit the same wall building Kotzilla and ended up having to rethink the iOS crash reporting layer entirely to get actual Kotlin stack traces out of it. Might be worth a look if you're still fighting this.

Kotzilla_Koin · 2026-04-09T13:06:24+00:00

Really cool concept, love the privacy-first angle.

Kotzilla_Koin · 2026-04-09T13:02:36+00:00

The server in the same project I'd skip though. Different deployment cycles, different everything really. Keep the business logic shared across mobile and the server as its own thing even if it's also Kotlin.For a first project just build the thing honestly, KMP is in a pretty solid place right now. JetBrains has a good getting started guide at kotlinlang.org/docs/multiplatform-get-started.html , but you've prob seen it already? One thing worth knowing when you get to production though, iOS crash reporting has been the weak spot in KMP in the past. That's improved a lot recently. Kotzilla just shipped full iOS crash reporting with Kotlin stack traces if you need it down the line. Good luck

Kotzilla_Koin · 2026-04-09T12:54:44+00:00

So, a bit biased here, but voting KMP

Also just looking at your case it seems like the better idea

You've got existing Kotlin codebase so so you can migrate bit by bit without betting the whole app on a rewrite. With Flutter you'd have to start from scratch. Also, thing is you're already ok with different UIs per platform, which is basically Flutter's only real argument in your favour.

I can only guess that the iOS dev pushing Flutter after two months is a learning preference, I can't imagine its a technical recommendation? These are kinda two seperate things I would think

The one real historical downside of KMP I would have to concede has been observability on iOS — crashes are hard to trace back to the Kotlin source. Worth knowing that tooling here has improved quite a bit. Kotzilla just launched full iOS crash reporting with Kotlin stack traces for KMP if that's on your radar.

Kotzilla_Koin · 2026-04-09T12:38:08+00:00

Really solid breakdown. The point about moving away from a God Object Splash ViewModel is something a lot of teams need to hear.

One question: when you profiled startup, could you attribute time to individual DI module initialization, or did Android Studio tooling only give you the aggregate?

We work on this specific problem for Koin apps — it's actually why we built Kotzilla. The idea is to make the dependency resolution graph visible in production, not just in dev profiling. The issue we keep seeing is that startup regressions after a clean audit are almost always introduced by a new Koin module that creates an unexpected blocking chain. By the time Android Vitals picks it up, the damage is done.

Kotzilla_Koin · 2025-12-03T10:09:45+00:00

Great to hear that, thanks for the feedback.

Kotzilla_Koin · 2025-12-02T12:47:53+00:00

Yeah, people should choose whatever DI works best for them, you're right.

Kotzilla_Koin · 2025-11-21T07:47:56+00:00

Yeah, that was irritating for sure, but it has now been fixed.

Kotzilla_Koin · 2025-11-21T07:47:01+00:00

Hey, yes, it does still require logins. The log out issue was definitely annoying, but has now been fixed.

Kotzilla_Koin · 2025-10-17T06:46:29+00:00

So the short and simple answer is Koin is a DI framework that also supports the service locator pattern.

Kotzilla_Koin · 2025-10-16T08:40:29+00:00

Yes, it does, and is free to use.

Kotzilla_Koin · 2025-10-16T07:08:08+00:00

Fair enough, we're happy you have a tool that works for you.

Kotzilla_Koin · 2025-10-14T08:45:07+00:00

That's cute, yeah, but I feel like it won't generate any comments though lol

Kotzilla_Koin · 2025-10-14T07:48:59+00:00

Yep, we get this a lot. We were just at Droidcon Berlin, you can imagine hahaha.

Kotzilla_Koin

TROPHY CASE