westnordost

It is a multiplatform app with one codebase, compiling to both iOS or Android.

This has been the most controversial quest in StreetComplete for a while. Following several discussions about it, I have now removed it for the upcoming version (i.e. v64.0).

I can't compare it to Flutter, I haven't used it.

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.

Have you tried out the Things or Places overlay? Second button from the right at the top, looks like a cake.

Overall, my experience has been pretty smooth. Just look at how little platform specific code is found in the streetcomplete repo and how straightforward these connect with the common code.

Or maybe I have been using it too long so that I don't notice the awkward bits anymore.

Any specific parts you are after?

In this case, the intended flow is that you tap "Uh..." -> "Differs along the way..."

You will then be led to another UI in which you can split the road into several sections.

There is an undo button on the lower left corner of the screen. Try it!

(It only shows edits made in the last 24 hours IIRC, but this limit is chosen quite arbitrarily. If there is a use case for it, it can be extended.)

It works offline, for one. A lot of datais kept persistently in a SQLite database.

Well, sort of. That'd be very bluesky. What's closer, actually, would be a desktop version, or rather, a version for Linux mobile like postmarketOS (would run like a desktop app in a JVM, but for a mobile target, the layout and UX wouldn't need to be changed.

When you are out of quests in your area, check the overlays! (Button to the left of the menu)

In my opinion, gamification that makes one addictive is very unethical.

So, any measure that aims at keeping users engaged (as the duolingo icon for example) should be viewed cautiosly.

Also, specifically with apps with which people provide real data, the more they see it as a game, the more the system will be gamed. When users start to guess, without really confirming it on-site, this leads to outright incorrect data.

What's fine, in my book, is to make the experience more gratifying, more "fun". That's probably what you meant, with firework animation etc.. The progress bars however already fall somewhat in the former category.

By the way, edits are accepted immediately. There is no verification step by the community (just like in wikipedia), all the more important it is that people don't start seeing it as a game first and as a way to contribute to a libre map second.

In regards to your edit: Yes, this is exactly correct.