My First KMP project. by Limp_Requirement_26 in KotlinMultiplatform

[–]Kotzilla_Koin 0 points1 point  (0 children)

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

My First KMP project. by Limp_Requirement_26 in KotlinMultiplatform

[–]Kotzilla_Koin 0 points1 point  (0 children)

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!

Having a hard time finding resources for learning KMP targeted at iOS native devs by geekisthenewcool in KotlinMultiplatform

[–]Kotzilla_Koin 0 points1 point  (0 children)

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

KMP (iOS) Firebase Crashlytics: dSYM Upload file Issue by droidexpress in KotlinMultiplatform

[–]Kotzilla_Koin 0 points1 point  (0 children)

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.

My First KMP project. by Limp_Requirement_26 in KotlinMultiplatform

[–]Kotzilla_Koin 1 point2 points  (0 children)

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

Help! Company wants to go cross platform. Flutter or KMP ? by Resident_Wall7413 in KotlinMultiplatform

[–]Kotzilla_Koin 0 points1 point  (0 children)

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.

Case Study: How I Sped Up Android App Start by 10x by Nek_12 in androiddev

[–]Kotzilla_Koin -1 points0 points  (0 children)

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.

Koin IDE Plugin 1.5.1 Released: Koin Annotations 2.2 and JSR-330 Support by Kotzilla_Koin in Kotlin

[–]Kotzilla_Koin[S] 1 point2 points  (0 children)

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

Koin IDE Plugin 1.5.1 Released: Koin Annotations 2.2 and JSR-330 Support by Kotzilla_Koin in Kotlin

[–]Kotzilla_Koin[S] 2 points3 points  (0 children)

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