How to Get StreetComplete on iOS Now

StreetComplete is the OpenStreetMap surveyor app that turns missing map data into small questions you answer on foot, and for nine years it has only been available on one platform. The September 2026 pre-releases changed that. The v64.0-alpha2 release notes say contributor @sargunv completed the final steps for a fully working iOS version, and the map and all interactions now run on a shared multiplatform UI framework. The iosApp/ directory in the repository is now an active build target.

This is an alpha release, not an App Store listing or an officially announced public beta. The project has published a working iOS build without a launch date, TestFlight link, or store page.

Key Takeaways:

StreetComplete’s iOS version reached a working state in the v64.0-alpha2 pre-release on September 28, 2026, after the map and app shell moved to Compose Multiplatform.

The port is a Kotlin Multiplatform migration, not a rewrite: one shared codebase now targets Android, iOS, and eventually Linux.

The work was funded by an NLnet NGI0 Commons Fund grant starting April 2025, with the maintainer estimating the full port at roughly one person-year.

This is an alpha, not an App Store release, and the project has not announced a formal public beta launch date.

What the iOS Build Actually Is

StreetComplete has not released an iOS version on the App Store, and its materials do not mention a formal public beta launch. What exists is a pre-release build: v64.0-alpha1 from September 18, 2026 and v64.0-alpha2 from September 28, 2026, both labeled “Pre-release” on GitHub.

The alpha1 notes describe the change as “huge” but “mostly invisible.” Maintainer Tobias Zwick redesigned the UI for every quest form while migrating to the multiplatform UI framework, and wrote that “an iOS version of app has now come within reach.” Ten days later, alpha2 completed the remaining work: the map, app shell, and navigation all moved to shared Compose code, which the notes identify as the final steps toward a fully working iOS version.

How the Multiplatform Port Works

The architecture is a Kotlin Multiplatform migration. The issue #5421 explanation states that the codebase was already fully Kotlin, many dependencies were pure Kotlin libraries, and Kotlin compiles to machine code similarly to Swift. This allowed building an iOS version with Kotlin Multiplatform, sharing the UI through Compose Multiplatform, a Jetpack Compose fork with a mostly identical API.

The migration proceeded in three phases. First, separate platform-specific code from app logic and replace Android/Java dependencies with Kotlin Multiplatform equivalents. Second, gradually move the UI from Android XML layouts to Jetpack Compose. Third, switch from Jetpack Compose to Compose Multiplatform, which Zwick describes as “a small step compared with the first one.” The second phase required the most effort; the third was mostly mechanical once the first two were complete.

A related OpenStreetMap app took a different approach. The issue notes that Every Door used Flutter, which required rewriting its entire codebase in Dart. StreetComplete keeps a single codebase, so maintenance costs “will not increase significantly” as it supports more platforms. The trade-off is that Compose Multiplatform for iOS was still in alpha/beta when the port began, so the team worked on a framework that was still stabilizing.

The funding is public and specific. The NLnet project page shows a grant from the NGI0 Commons Fund starting April 2025, aimed at “OpenStreetMap editing beyond Android” using Kotlin Multiplatform and Compose Multiplatform, targeting iOS and eventually Linux. The GitHub README confirms a 2025 NLnet grant enabled Zwick to complete the multiplatform migration so the app “runs also on iOS.” This is one of four NLnet grants supporting the project, with earlier ones in 2021 and before.

The Quest Model Behind the App

StreetComplete identifies missing data nearby and presents it as quests on a map. You complete a quest by visiting the location and answering a simple question: whether a path has a surface, what a building’s house number is, or when a shop opens. The answer is added directly to OpenStreetMap under your name, without opening a separate editor.

The repository README describes the app as aimed at non-technical users and “presented in slightly gamified fashion.” The community maintains a list of all quest types on the OSM wiki, and the changelog shows the catalog continues to grow. Alpha1 added quests like “How much do you need to pay to park here?”, “What doctors are present here?”, and “What type of vending machine is this?”

Here is a simplified view of the data model a quest represents. StreetComplete’s actual implementation is more complex, but the core interaction is a tag key with a candidate value resolved against OpenStreetMap.

# A quest is a question about a specific OpenStreetMap element.
# The app resolves the answer into an OSM tag and uploads the change.
# Note: production use should validate against the OSM tagging schema
# and handle conflicts where another editor changed the element first.

QUEST_TYPES = {
 "surface": {
 "question": "What surface does this path have?",
 "answers": {"asphalt": "surface=asphalt", "gravel": "surface=gravel",
 "dirt": "surface=dirt"},
 },
 "opening_hours": {
 "question": "When is this place open?",
 "answers": {"24/7": "opening_hours=24/7",
 "Mo-Fr 09:00-18:00": "opening_hours=Mo-Fr 09:00-18:00"},
 },
}

def resolve_quest(quest_type, answer):
 return QUEST_TYPES[quest_type]["answers"].get(answer)

print(resolve_quest("surface", "asphalt"))
# Expected output: surface=asphalt

The same process applies on iOS and Android because the quest logic is in the shared Kotlin module, not in any platform-specific layer. A new quest type written once becomes available on all targets simultaneously, rather than being reimplemented for each platform.

A second pattern shows how the app decides which quest to present. Not every missing tag is worth asking about; the app filters candidates so it only asks about elements the user can realistically reach and answer.

# Decide whether a missing tag is worth asking the user about.
# Note: production use should add distance checks, element-type rules,
# and a cooldown so the same element is not re-asked after a recent edit.

def is_questable(element, tag_key, user_location):
 if tag_key in element.get("tags", {}):
 return False # already answered
 if element.get("deleted"):
 return False
 return True

element = {"id": 4821, "tags": {"highway": "footway"}, "deleted": False}
print(is_questable(element, "surface", None))
# Expected output: True

What Beta Testers Actually Do

The CONTRIBUTING.md lists “Test and report issues” first, before translating the app, addressing notes left by other users, or suggesting new quests.

For the iOS build, testers fill a role automated checks cannot. The port depends on Compose Multiplatform rendering consistently across two operating systems, and the alpha notes already report regressions that only appear on real devices. Alpha2 fixed a zoom animation that stopped when the map followed the user’s position, a selected-language bug where the system default overwrote the user’s choice, and a keyboard that covered the quest form. These are platform-interaction bugs rather than logic errors, exactly the kind of issues a multiplatform port is likely to introduce.

The repository has 4,862 stars and 456 forks as of October 1, 2026, with 12,954 commits and 137 open issues. It is actively maintained, with a push within the last week. The alpha release notes credit @sargunv, @mcliquid, @kiliankoe, @maxwellward, @paulklie, @peternewman, @kmpoppe, @Amaanprobably, and @marekkrug across the two pre-releases. This distributed contribution pattern reflects how a one-person-year port gets completed.

A small function illustrates the format of a bug report testers submit for a port like this. Platform-specific regressions require recording the device and OS version, since the same quest can behave differently on different targets.

# A minimal bug report for a multiplatform app.
# Note: production use should add a screenshot path, a log excerpt,
# and a check that the platform value is one the project supports.

def format_report(quest, symptom, platform, os_version):
 return (f"[{platform} {os_version}] {quest}: {symptom}")

print(format_report("surface", "keyboard covers the answer buttons",
 "iOS", "26.1"))
# Expected output: [iOS 26.1] surface: keyboard covers the answer buttons

Trade-offs and Limitations

The iOS build is functional but incomplete. The release notes and issue tracker describe an alpha with ongoing work, not a polished beta.

The clearest limitation is timing. Zwick estimated in issue #5421 that a full iOS port would require “one man-year of work,” and as of early 2024 the migration was “about 50% complete.” The alpha releases indicate the finish line is close, but the project has not published an App Store listing, TestFlight invite, or formal beta launch announcement.

A second limitation is dependency risk. Compose Multiplatform for iOS was in alpha/beta when the port began, which Zwick acknowledged: “This is very new to me too.” Building a production app on a UI framework that is still stabilizing means the team must handle upstream changes. The alpha notes’ fixes for zoom interruptions, keyboard occlusion, and locale overrides reflect the cost of that choice.

A third limitation is scope. The migration targets iOS “and eventually Linux,” but the README still describes the project as an “Easy to use OpenStreetMap editor for Android,” and the download links point to Google Play and F-Droid. The Android app remains the stable, supported product; iOS is still experimental.

Dimension	Android (stable)	iOS (pre-release)
Distribution	Google Play and F-Droid	GitHub pre-release builds only
UI framework	Jetpack Compose (migrated from XML)	Compose Multiplatform
Release stage	v63.x stable line	v64.0-alpha2 (September 28, 2026)
Codebase	Shared Kotlin module + Android shell	Same shared module + thin iOS shell

The table reflects the project’s own materials: the Android app is distributed through the stores named in the README, while the iOS build is available only as a GitHub pre-release. No verified price, download count, or App Store availability has been published.

What to Watch Next

The version tag is the key indicator. The project moved from “an iOS version has come within reach” in alpha1 to “last remaining steps for fully working iOS version” in alpha2 within ten days, which suggests a stable release is the next milestone. A v64.0 stable tag, an App Store listing, or a TestFlight announcement would each signal the transition from pre-release to public beta, but none has occurred yet as of this writing.

This development affects OpenStreetMap itself. The app’s stated goal is to allow “a significantly larger audience” to contribute missing data while on the move, and the NLnet grant exists because OpenStreetMap benefits when the barrier to entry lowers. An iPhone user who has never edited a map can, through StreetComplete, add a house number or a path surface in about thirty seconds. Every platform the app supports increases that capacity.

For developers, this approach is practical. A 100% Kotlin codebase migrating to Kotlin Multiplatform, with UI moved gradually from platform widgets to Compose Multiplatform, provides a repeatable path for any single-platform open-source app that wants to add another platform without rewriting. The cost is real (roughly a person-year and reliance on a still-maturing UI framework) but in this case it is a known, funded, and nearly finished effort. For how similar open-source projects organize contributor-driven maintenance, see our earlier article on an open source 3D printable desktop robot, which uses the same one-maintainer-plus-contributors model.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: