StreetComplete para iOS: mantenedor reporta 50% de avance
@programacion
Lo esencial
- El mantenedor de StreetComplete, westnordost, reporta que el port a iOS llegó al 50% en el primer semestre de 2024.
- El proyecto usa Kotlin Multiplatform para compartir el 100% de la lógica entre Android e iOS.
- La interfaz se migra con Compose Multiplatform, entonces en fase beta para iOS.
- El issue #5421 en GitHub coordina las tareas del port, abiertas a contribuciones de la comunidad.
- La estimación original calculaba un año-persona de trabajo para completar la migración.
Qué pasó
StreetComplete para iOS llegó a la mitad del camino: su mantenedor, el desarrollador conocido como westnordost, reportó en 2024 que la migración del código del port alcanzaba el 50% tras seis meses de trabajo a tiempo completo.
El reporte quedó documentado en el issue de coordinación en GitHub, el ticket maestro que centraliza todas las tareas del port. StreetComplete es una app de OpenStreetMap que guía a los usuarios a responder preguntas puntuales sobre el mapa, como el ancho de una calle o el material de una vereda, y envía esas respuestas directo a la base de datos abierta. La versión para Android existe desde 2017; la de iOS, hasta ahora, nunca se había lanzado.
Por qué tardó tanto en arrancar
El código de StreetComplete está escrito 100% en Kotlin. El issue #5421 reemplaza a un ticket anterior, el #1892, que durante años acumuló discusión y trabajo de investigación sin llegar a un plan ejecutable.
La estimación original del propio westnordost calculaba un año-persona de trabajo para completar el port: esa cifra no bajó. Lo que cambió en 2024 fue que el mantenedor pudo dedicarle tiempo completo al proyecto, algo que antes no era posible.
El enfoque: Kotlin Multiplatform
En vez de reescribir la app desde cero en Swift, el equipo eligió Kotlin Multiplatform, que compila el mismo código Kotlin a una librería nativa para iOS. La lógica de negocio (validación de preguntas, sincronización con los servidores de OpenStreetMap, manejo de datos geográficos) se queda en un único módulo compartido entre las dos plataformas.
La alternativa habría sido Flutter, el framework que usa la app rival Every Door. Con Flutter, todo el código Kotlin actual tendría que reescribirse en Dart. Con Kotlin Multiplatform, la base de lógica se mantiene intacta y solo cambia lo específico de cada plataforma.
La interfaz: de XML a Compose Multiplatform
La parte visual sigue un camino distinto, en tres pasos. Primero separar los datos y el estado de la interfaz pura usando ViewModels. Después migrar los layouts XML de Android a Jetpack Compose, el framework reactivo de Google. Recién al final, dar el salto a Compose Multiplatform, que en ese momento corría en fase beta para iOS.
Ese último paso es comparativamente pequeño, según describió el propio mantenedor. Una vez que una pantalla ya está escrita en Jetpack Compose, portarla a la variante multiplataforma implica cambios acotados en la API, no una reescritura completa.
Cómo se ve el código compartido
La separación entre lógica común y código específico de plataforma se resuelve con el patrón expect/actual de Kotlin Multiplatform. Un ejemplo simplificado de una quest (la unidad básica de StreetComplete) y el acceso a la ubicación del dispositivo:
// commonMain: la lógica de la pregunta es igual en Android e iOS
class WidthOfHighwayQuest {
fun isApplicableTo(tags: Map<String, String>): Boolean {
return tags["highway"] != null && tags["width"] == null
}
}
// commonMain: se declara la forma, sin implementación
expect class LocationProvider {
fun getCurrentLocation(): Pair<Double, Double>
}
// iosMain: implementación real usando CoreLocation
actual class LocationProvider {
actual fun getCurrentLocation(): Pair<Double, Double> {
TODO("implementación específica de iOS con CLLocationManager")
}
}La clase WidthOfHighwayQuest vive en commonMain y se compila igual para ambas plataformas. LocationProvider se declara una sola vez y cada plataforma aporta su propia implementación: CoreLocation en iOS, el LocationManager de Android. Ese es el límite exacto entre código compartido y código específico.
El cuello de botella es la comunidad
El propio westnordost fue explícito sobre la limitación real del proyecto: el avance depende de cuánta gente contribuya. Pidió ayuda en tres frentes: tomar tareas del tablero del proyecto en GitHub, familiarizarse con Jetpack Compose y Compose Multiplatform (tecnología que, según sus palabras, también era nueva para él) y sponsorear el desarrollo para poder dedicarle más horas pagas.
Ahí aparece un trade-off real. Compartir el 100% de la lógica reduce el mantenimiento a largo plazo, porque hay un solo codebase y no dos, pero exige que cada contribuidor entienda Kotlin Multiplatform, una tecnología todavía poco común fuera del ecosistema Android. Un port 100% nativo en Swift habría sumado contribuidores iOS puros más rápido, al costo de duplicar el mantenimiento para siempre.
Qué sigue
El issue #5421 funciona como tablero maestro y se actualiza de forma continua a medida que se completan tareas y se abren otras nuevas, muchas de las cuales dependen de que otras terminen primero. No hay fecha pública para una beta de iOS; el mantenedor evita comprometerse a un calendario y pide medir el avance por el progreso real de la migración, no por promesas.
Conclusión
El port de StreetComplete a iOS es, ante todo, un experimento sobre cuánto puede estirarse un codebase de Kotlin antes de tener que bifurcarse. Con la mitad del camino recorrido en 2024, la app muestra que Kotlin Multiplatform y Compose Multiplatform son una alternativa viable a reescribir todo en Swift, aunque el precio sea depender de que la comunidad open source aporte el tiempo que falta.
📖 Versión extendida con más detalle: https://elsolitario.org/2026/10/01/streetcomplete-para-ios-mantenedor-reporta-50-en-2024/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion