(for context, I helped with the streetcomplete port, and have build and maintained a KMP / CMP maplibre sdk for the past two years, but otherwise consider myself a polyglot proficient in most common tech stacks at least to a moderate degree)
> Maintaining a significant new moving part in the dev process. KMP updates, management, integration, futures awareness, this all takes non-zero time.
If you're already doing that for Android, any additional tooling/infra churn for KMP is pretty negligible, except for a one-time cost of separating common kotlin code from android-specific code. KMP updates are just Kotlin updates.
> If an iOS dev wants to work on a KMP project what's the ramp up time? How much less efficiently can they contribute compared to a pure native app?
Two answers here:
1. Kotlin, the language, is quite similar to Swift, and can call ObjC APIs (or Swift annotated with @ObjC) directly via cinterop, so you're calling the same iOS SDKs. Compose is a declarative UI framework in the same vein as SwiftUI and React (and IMO with fewer footguns and quirks than SwiftUI, though there are some). It renders more like Flutter (via Skia) but it's not hard to embed as a component of a SwiftUI app.
2. KMP libraries can also export ObjC or Swift APIs, called in Swift. It's fairly common for there to be a shared business logic / service layer within an app, perhaps even shared view models, and leave the UI layer itself to SwiftUI and Compose for each platform.
Compared to something like React Native, I find that KMP is much friendlier and less opinionated about how you use it and how much you integrate it. You can use it to share a small module, or the whole app, or anywhere in between, and the seams at the boundary are not nearly as painful as you'd expect crossing languages.
> How much time is spent on problems, bugs, issues, related to KMP. This is guaranteed non-zero for any tool.
Hard to quantify, but in my time working on MapLibre Compose for the last two years, I've run into a handful of Androidx bugs, and much fewer KMP / CMP bugs. Even the same APIs, on the Compose Multiplatform side tend to have fewer pitfalls and bugs in my experience than on the Android side.
That said, the time I've spent dealing with _IDE_ bugs in JB IDEs has been far too much. These days, I spend much less time in an IDE, so it hasn't mattered as much, but I'd _like_ to spend more time there as ideally, even if agents are generating code, I want to read and navigate it in a nice environment.
> Is there less benefit to KMP with coding agents? ... just that some things are not as bad now.
Probably depends where you are on the vibe coding vs ai-assisted engineering spectrum. I'm a heavy AI user these days, close to 100% since Fable/Sol/Astra, but on code I care about, I don't vibe code, I still spend time to understand and refine at least the architecture, if not the line-by-line code. So still I prefer the single codebase because that's one fewer set of abstractions, of failure modes, of guardrails, of test harnesses, etc to worry about.
But if you care deeply about the native UI, using Compose on Android, SwiftUI on iOS, and then KMP for a shared core is an excellent architecture. The opposite, a shared Swift core, I think is also becoming more possible as Swift targets Android, though I'm unsure what the kotlin-on-android -> swift integration experience is like.