StreetComplete on iOS Is Finally in Public Beta

For years, StreetComplete lived in an awkward place for iPhone owners: the app was known for making OpenStreetMap edits feel like a walk with a checklist, but that checklist only lived on Android. On September 30, 2026, the boundary finally moved. StreetComplete’s iOS public beta, version v64.0.0, became available through Apple’s TestFlight, the service used to distribute pre-release apps and collect tester feedback. This is not a final App Store launch, but it is the moment the iOS port became real enough for a broad group of people to use. The first build matches Android v64.0-alpha2, so it belongs to the same product line rather than being a disconnected experiment. (community.openstreetmap.org)

A familiar map with a different job

StreetComplete is an editor for OpenStreetMap, the community-built database behind maps of roads, buildings, paths, benches, hydrants, and countless other features. Instead of asking new contributors to learn a detailed tagging scheme, it shows nearby places that need information and presents a plain-language question. Each small task is called a quest. Answering it creates an edit that can be uploaded to OpenStreetMap, often while you are standing on the street looking at the feature in front of you. (github.com)

That design is why an iOS version matters. A person carrying an iPhone may notice that a curb ramp is missing, a shop has changed names, or a pedestrian path has the wrong surface. The information is easy to see, but without the right tool, turning that observation into a useful map edit has traditionally required a more complicated editor or a different device.

A public beta with a few rough edges

Public beta does not mean unfinished in the vague sense of being unusable. It means the build is available to external testers while the team watches for problems that are difficult to find in a small development group. TestFlight handles the invitation, installation, updates, and feedback loop, so the app can improve through real trips, real phones, and real map data before a wider release. (developer.apple.com)

The first StreetComplete iOS announcement is refreshingly specific about the rough edges. At launch, tapping the map did not close an open quest form, and another quest or overlay could not be opened directly while that form was visible. The back gesture was the reliable way to leave it. The announcement also listed a map-rendering problem on iOS 15.x, with the maintainer saying a fix was already prepared for the next alpha. These are small details on paper, but they are exactly the sort of friction that becomes obvious during a ten-minute walk.

Why an Android app cannot be copied to iPhone

How did StreetComplete bring an Android-first app to iPhone without maintaining a completely separate product? The answer starts with a distinction that can trip up beginners: a programming language is not the same thing as an operating-system platform.

StreetComplete was already written in Kotlin, a modern language also used widely in Android development. But Kotlin does not make Android APIs portable by itself. Code that talks to Android storage, sensors, background services, or screen components still depends on Android. An iPhone needs different system APIs, different packaging, and different integration points. An older StreetComplete design note described the original situation plainly: the app was a native Android application, and most of an iOS version would have required new work.

The project’s master iOS ticket, opened on December 20, 2023, turned that problem into a migration plan. Rather than throwing away the Kotlin code and rewriting everything in Swift, the team began separating platform-specific code from application logic, replacing Android-only dependencies where possible, and moving the interface toward a shared UI framework.

Kotlin Multiplatform is the bridge

Kotlin Multiplatform is a technology for sharing selected code between platforms while still producing platform-specific applications. The shared part can contain rules, data models, networking, synchronization, and state management. Android and iOS then compile that shared code for their own environments and provide separate implementations where the operating systems genuinely differ. (kotlinlang.org)

A simplified version of the architecture looks like this:

commonMain/
 quest rules
 OpenStreetMap data handling
 form state and validation
 shared Compose UI

androidMain/
 Android storage and services
 Android-specific integrations

iosMain/
 iOS storage and services
 iOS-specific integrations

iosApp/
 the Xcode application that packages the iOS build

The important word is shared, not identical. A quest can use the same validation rules on both platforms, while location access or a system permission prompt may need separate code. The current project structure reflects that approach with an iOS application module, Apple device and simulator targets, and common Kotlin dependencies alongside Android-specific ones. (github.com)

The screens still had to be rebuilt

The interface was the more visible part of the migration. Compose Multiplatform is a code-based UI framework that lets developers describe screens in Kotlin and share much of that code across Android and iOS. It follows a reactive model, meaning the screen is drawn from application state and updates when that state changes. The idea is similar to SwiftUI, but the existing Android screens could not be waved across to iPhone automatically.

StreetComplete’s plan called for recreating the UI incrementally. First, data access and UI state had to be separated from the code that draws buttons, forms, maps, and panels. A view model is the piece that holds that state and the actions a screen can perform; keeping it apart from the visual layer makes it easier to attach the same behavior to different platform surfaces. Only after that separation could the team move screens from Android layouts to Jetpack Compose and then toward Compose Multiplatform.

That explains why the beta can look familiar while still having iOS-specific behavior to polish. The same quest logic may be shared, but gestures, bottom sheets, map rendering, permissions, and navigation all meet the operating system at the edges.

A milestone for the project, not the finish line

The iOS beta is the visible result of a long migration rather than a sudden port. StreetComplete’s repository credits Prototype Fund support for iOS work in 2024 and a 2025 NLnet grant intended to help finish the multiplatform transition. The project’s maintainer has also emphasized that keeping one main codebase should prevent future maintenance from doubling every time a feature changes.

For users, the payoff is straightforward: an iPhone can now participate in the same small, useful mapping loop that Android users have enjoyed for years. For developers, the more interesting story is underneath the map: a mature native app crossed platforms by sharing the parts that describe the product and isolating the parts that belong to each operating system.

The first public build still has seams showing. That is what makes it a beta. But the hardest transition has happened: StreetComplete is no longer an Android-only idea with an iOS plan on a project board. It is now an iOS application that people can take outside, test against the real world, and help shape into a finished OpenStreetMap tool.