⏱️ Reading time: 9 min
The app that millions of volunteers use to fix OpenStreetMap from Android has spent almost three years trying to reach the iPhone, and the ticket coordinating that effort for StreetComplete for iOS just confirmed the migration is halfway done.
📑 En este artículo
Issue #5421 on GitHub, opened on December 20, 2023 by the project’s maintainer (identified as westnordost), replaces an earlier thread and describes the plan: rewrite the interface with Compose Multiplatform while the app’s core stays shared in Kotlin between Android and iOS.
TL;DR
- The StreetComplete for iOS port was about 50% done by mid-2024, according to GitHub issue #5421.
- The migration replaces the Android interface with Compose Multiplatform to share code with iOS.
- Westnordost estimates one person-year of total work to finish the port.
- A GitHub Project Board lists the open tasks available to contribute to.
- Compose Multiplatform avoids rewriting the app in Dart, unlike Every Door with Flutter.
What StreetComplete for iOS Is
StreetComplete for iOS is the project that brings the popular quick-editing app for OpenStreetMap, native to Android, to the iPhone using Kotlin Multiplatform and Compose Multiplatform, sharing the same Kotlin codebase instead of rewriting it entirely in Swift.
The original app lets anyone answer short questions about their surroundings (whether a street has sidewalks, what surface a path has, how many floors a building has), and those answers get uploaded directly to OpenStreetMap, the collaborative map used by apps like OsmAnd and Organic Maps. So far there’s no official iPhone version, and that gap is exactly what issue #5421 is trying to close.
What Happened
On December 20, 2023, the project’s maintainer, identified on GitHub as westnordost, opened issue #5421 as the master ticket to coordinate development of the port. The thread replaces an earlier one, #1892, which had already built up discussion and research work on how to approach the jump to iOS.
The plan described in the issue is concrete: instead of maintaining two separate codebases, rewrite the interface layer with Compose Multiplatform while the application’s core (networking logic, data models, persistence) stays shared in Kotlin between Android and iOS. The ticket itself notes that this keeps future maintenance effort contained, since there will still be a single codebase instead of two.
According to the thread’s most recent update, during the first half of 2024 the author was able to work on the port full-time, and the migration reached close to 50%. The issue works as a living log, updated as the work progresses, and links to a Project Board in kanban style with the pending tasks, many of them open for anyone in the community to pick up.
Context and History
StreetComplete has 4.9 thousand stars and 456 forks on GitHub as of October 1, 2026, a considerable user and contributor base for a citizen-mapping app. Until now that base only ran on Android: anyone with an iPhone who wanted to contribute to OpenStreetMap with the same experience had to turn to another app.
The best-known alternative is Every Door, a quick-editing app for OpenStreetMap built with Flutter that has run on both Android and iOS from the start. Issue #5421 itself mentions it as a point of comparison: Flutter would have solved the cross-platform problem, but at the cost of rewriting all of StreetComplete’s logic in Dart, a different language from the one the project already uses.
That comparison pushes the decision toward Kotlin Multiplatform. By 2023, several of the dependencies StreetComplete already used had migrated to pure Kotlin libraries, which made it feasible to share code without relying on Android-exclusive APIs. That maturing of the ecosystem, according to the author, didn’t exist when the port was first discussed in issue #1892.
Technical Details
Kotlin Multiplatform doesn’t translate Kotlin code into another language: it compiles it directly. For Android, the compiler generates JVM bytecode as usual; for iOS, it uses Kotlin/Native to produce native binaries that run without a virtual machine. The result is that the business logic (how a response is validated, how it syncs with the OpenStreetMap server, how it’s cached) lives in one place and gets compiled twice, once per platform.
The part the user sees follows a different path: Compose Multiplatform. It’s a fork and extension of Jetpack Compose, Android’s declarative UI framework, that reuses almost all of its API. On iOS, instead of relying on UIKit or SwiftUI, Compose Multiplatform draws the interface with Skia, the same 2D rendering engine used by Chrome and Android. That’s why the issue describes the work as recreating the entire interface incrementally in Compose: there’s no way to reuse the screens that already existed in XML, they have to be rebuilt.
flowchart TD
A["Shared Kotlin code"] --> B["Android target (JVM)"]
A --> C["iOS target (Kotlin/Native)"]
B --> D["UI with Compose Multiplatform"]
C --> D
D --> E["Render via Skia"]The issue lays out the plan’s steps in order: first separate platform-specific code from application logic, replacing Android/Java dependencies with multiplatform equivalents. Then migrate the UI in two stages: separate data access and pure interface state using ViewModels, and migrate screens still using Android XML layouts to Jetpack Compose, something that can be done incrementally working bottom-up. Only at the end, with the UI already on Jetpack Compose, does the jump to Compose Multiplatform become a small step compared to the first one, according to the ticket’s own description.
| Approach | Codebase | What needs rewriting | Example |
|---|---|---|---|
| Kotlin Multiplatform + Compose Multiplatform | Single, in Kotlin | Only the UI layer, incrementally | StreetComplete for iOS |
| Full rewrite in Flutter | Two bases: Kotlin (Android) and Dart | All app logic, not just the interface | Every Door |
📌 Note: Compose Multiplatform for iOS was in alpha/beta phase when the issue was opened, according to JetBrains’ own documentation: the project depends on that support continuing to mature to reach production.
Impact and Analysis
The StreetComplete for iOS case matters beyond a single app. It’s one of the most visible attempts by a large, 100% Kotlin project maintained mostly by volunteers, to reach iOS without duplicating its codebase. If it works, it serves as a reference for other Android apps with active communities that today rule out iOS because of the cost of maintaining two codebases in parallel.
The issue itself is honest about the scale of the problem: the estimate of one person-year of total work, made a while back according to the ticket’s text, still holds as an order of magnitude.
There’s also a real limit in the development model: the ticket depends on the community picking up tasks from the Project Board and on sponsors willing to fund more full-time hours for the maintainer. Without that, the pace of progress stays tied to the availability of a single person working part-time, the most likely scenario outside periods of full-time dedication.
What’s Next
The Project Board linked in the issue remains the source of truth on what’s left: screens still to be migrated to Compose Multiplatform, Android dependencies that don’t yet have a multiplatform replacement, and research tasks that, per the ticket itself, depend on other tasks being completed first. The author specifically asks for help from anyone with experience in Jetpack Compose or Compose Multiplatform, and notes that it’s new technology for him too.
There’s no announced release date for the iOS version of StreetComplete, and the issue itself avoids committing to one: the ticket gets updated continuously as work progresses, with no fixed deadlines. The funding route the author mentions is the repository’s sponsor button, with the argument that more funds translate directly into more development time dedicated to the port.
Try it yourself: follow the Project Board for issue #5421 to see in real time which iOS port tasks are open to pick up.
Frequently Asked Questions
What is Kotlin Multiplatform and why did StreetComplete for iOS choose it?
It’s a Kotlin technology that compiles the same source code to different targets: JVM bytecode for Android and native binaries via Kotlin/Native for iOS. The project chose it because it avoids maintaining two separate codebases, something key for an app sustained mostly by volunteers.
Why doesn’t the app’s iPhone port use Flutter like Every Door?
Because StreetComplete is already 100% Kotlin. Switching to Flutter would have meant rewriting all the app’s logic in Dart from scratch, while Kotlin Multiplatform allows reusing that existing code and migrating only the interface layer.
When will the iOS version of StreetComplete launch?
There’s no confirmed date. Issue #5421 reported close to 50% progress by mid-2024, with a total estimate of one person-year of work, but no commitment to a release date.
What is Compose Multiplatform?
It’s the UI framework used by the port: an extension of Jetpack Compose that renders with Skia instead of UIKit or SwiftUI, and that allows reusing almost all the Compose API already used by Android apps.
How can I contribute to StreetComplete’s Kotlin Multiplatform project?
By picking up a task from the Project Board linked in issue #5421, commenting on the specific ticket before starting, or funding development through the repository’s sponsor button on GitHub.
References
- GitHub: issue #5421: master ticket where westnordost coordinates StreetComplete’s iOS port.
- GitHub: StreetComplete repository: source code for the app and its technical documentation.
- Kotlin: official Kotlin Multiplatform documentation: how to share code between Android and iOS by compiling to Kotlin/Native.
- JetBrains: Compose Multiplatform: declarative UI framework used to share the interface across platforms.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
Featured image: Foto de Balázs Kétyi en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments