Alright, let's see:

> KMP stability

Regarding moving parts in KMP, I have the impression that it is quite stable now, and has been for some time. I feel it is less maintenance work than having an Android project that uses the Android UI framework and system APIs. Google loves to deprecate and invent new APIs every few years. I feel there is very little in the way of breaking changes that need changes in the code in KMP. Most of that comes from some third party libraries on major new versions. The biggest change recently was a change in the Android Gradle plugin that required to change the project structure. Arguably, that again was more of an Android than a KMP thing.

> iOS developers

Well, the app is Kotlin Multiplatform + Compose Multiplatform as UI framework. So, while it runs on iOS, the parts that would feel native to an iOS dev are near zero: There are about 50 lines of code in Swift in the project and about 1000 dealing with iOS APIs, but written in Kotlin.

As Kotlin and Compose is used in Android development, the project will always feel more accessible to Android developers. That said, Kotlin is somewhat similar to Swift and Compose is also a declarative reactive user interface framework, i.e. similar to SwiftUI. As for the setup, they need at least IntelliJ/Android Studio to compile all that Kotlin to native code before launching the app from XCode in a simulator. That's my setup at least. Certainly one could also just use gradle (the build system) from the commandline.

> KMP bugs

KMP bugs, none that I remember. About platform-specific issues we will see what will surface during the beta test. So far, one thing surfaced, but it was found easily and necessitated changing 4 lines of code.

Compose (the UI framework) is a different matter. At times, I feel it is quite unwieldy when not solving standard problems. Being designed primarily by Google, I also find that best practices change and deprecations happen fairly frequently. Certain features lacking in Compose Multiplatform I need to implement myself. For example, there are still no scroll bars.

> Coding Agents

I have little experience with that, but what I have seen, the agents have no problem generating working code for the platform-specific parts of the implementation. Some un-slopping is necessary as always.

And, as I wrote, the platform specific code takes up a tiny part of the whole code base. Of the 80k lines of source code in the production code, 2k lines of source code are platform specific.

StreetComplete on iOS is now in public beta