Encender un teléfono Android y encontrar iOS 16.5 en pantalla
En un Xiaomi POCO X5 Pro 5G, la pantalla de bloqueo, los gestos del sistema y el Centro de control responden con total fidelidad a iOS 16.5. Al entrar en Ajustes > General > Información, el modelo aparece identificado como iPhone X. El dispositivo no ha sido flasheado ni se han modificado sus particiones: todo el sistema arranca directamente en la memoria RAM mediante fastboot boot. Con un simple reinicio, el terminal vuelve sin rastro a Android.
Esta es la propuesta de HackiOS, un proyecto de código abierto que adaptó el kernel XNU publicado por Apple (xnu-8796.121.2, correspondiente a iOS 16.5) a la plataforma Snapdragon. Sobre él arranca un espacio de usuario de iOS 16.5 sin modificar, extraído de un archivo oficial IPSW: procesos como launchd, backboardd y SpringBoard inician con normalidad y las aplicaciones se abren. Liberado el 22 de octubre, el repositorio acumuló 489 estrellas y 93 bifurcaciones en apenas 24 horas.
Lo que este experimento mide en la práctica es mucho más elocuente que la mera anécdota de portar iOS: el auténtico muro entre los sistemas operativos móviles no está en el kernel, sino en la maraña de controladores propietarios y firmware cerrado.
Figura: Pantalla de inicio de iOS funcionando en un teléfono Android. Fuente: Repositorio HackiOS
El kernel siempre fue de código abierto: la barrera no está ahí
Apple publica el código fuente de su núcleo XNU desde el año 2000. Los kernels de macOS e iOS están a la vista de cualquiera bajo la licencia Apple Public Source License (APSL), que permite modificarlos y redistribuirlos. De hecho, el repositorio de HackiOS no contiene una sola línea de código privativo de Apple: el espacio de usuario lo extrae cada usuario directamente del paquete de restauración oficial, eludiendo problemas legales de distribución.
Si el núcleo fuera el obstáculo real, este hito se habría alcanzado hace dos décadas. El motivo del retraso es elemental: una vez que el kernel arranca, necesita comunicarse con el hardware, y esa conversación se realiza mediante controladores (drivers). Los controladores de Apple Silicon y sus periféricos dedicados son binarios cerrados bajo estricto control de Apple, inaccesibles y sin licencias para terceros.
El enfoque de HackiOS consistió en sustituir esa capa completa: programaron un cargador EFI propio para gestionar el arranque, diseñaron controladores personalizados para reemplazar los módulos cerrados de Apple, portaron el entorno UEFI al dispositivo e integraron una capa de compatibilidad para usar los controladores Wi-Fi de Linux. Dado que la comunidad Linux ya disponía de soporte para Snapdragon, la capa de compatibilidad permite al entorno iOS tomarlos prestados. La secuencia de arranque es limpia: fastboot boot levanta el entorno UEFI (adaptado de Project Silicium), UEFI ejecuta la aplicación xnuloader, y esta cede el control al kernel personalizado.
El kernel se puede tomar del código abierto; los controladores hay que reescribirlos uno a uno. Así se mide el verdadero grosor del muro.
Figura: Pantalla de Ajustes > General mostrando el modelo como iPhone X. Fuente: Repositorio HackiOS
Lo que funciona, lo que falla y un detalle revelador
La lista de componentes funcionales supera cualquier previsión: la pantalla de bloqueo, la navegación por gestos, el Centro de control, los Ajustes y las aplicaciones integradas funcionan. Las capturas del archivo README muestran la pantalla de inicio, Reloj, Calendario, Música, Wallet, Mapas y Mensajes. Incluso se renderizan las pestañas de App Store, aunque la descarga de contenidos y el inicio de sesión con Apple ID no funcionan al carecer el terminal del módulo físico Secure Enclave.
La lista de ausencias aporta todavía más contexto técnico: la conectividad móvil (red celular) y el Bluetooth no responden. La razón enlaza con la sección anterior: los protocolos de enlace del módem de banda base y del chip Bluetooth residen en la capa más hermética del software propietario, inalcanzable para una capa de traducción simple. Ambas funciones delimitan la frontera exacta entre un teléfono funcional y una placa de desarrollo con interfaz gráfica.
Hay además un detalle sumamente elocuente: bajo este kernel la carga de batería no responde, por lo que el teléfono solo se descarga. La gestión de entrega de energía por USB depende de otro protocolo de firmware cerrado cuya lógica aún no ha sido descifrada por los controladores caseros. Un teléfono que pierde batería aun estando enchufado ilustra la brecha de controladores con mayor claridad que cualquier esquema de arquitectura.
Figura: Centro de control. Fuente: Repositorio HackiOS
El reto de la cámara también fue superado
Uno de los componentes que más interés despertó en los foros fue la cámara. En el ecosistema de Linux móvil, los módulos de cámara representan históricamente uno de los obstáculos más duros. Sin embargo, en la tabla de características del README, la aplicación Cámara lista la cámara frontal y trasera, la vista previa en vivo, el enfoque automático y la captura en formato HEIC como plenamente operativas: una vez dominada la canalización de vídeo de la GPU, el subsistema de captura terminó cediendo.
Otro aspecto destacado por los desarrolladores fue la autoría de los commits: el registro de cambios incluye la etiqueta Co-Authored-By: Claude Opus 5.5. El README define con precisión el alcance: se trata de un banco de pruebas para investigación, no de una ROM de uso diario. Cada sesión dura únicamente una cantidad determinada de segundos antes de reiniciar el kernel a un estado limpio con registros despejados, lo que facilita el trabajo iterativo de agentes de software automatizados. Antes de la publicación el 22 de octubre solo existían vídeos demostrativos sin código fuente, lo que generó escepticismo sobre su veracidad. Una vez publicado el repositorio, las dudas desaparecieron de inmediato.
El equipo responsable, bautizado como OOSEX GANG, está formado por cuatro integrantes: fundado por @oodze, con la participación de @netusd, @wannqn y @hxfuxyyXD. Cuatro ingenieros apoyados en herramientas de programación mediante IA lograron lo que antes exigía un departamento completo de ingeniería inversa.
Medir el muro del relato comercial de los fabricantes
Durante años, las narrativas corporativas han sugerido que iOS y Android son mundos diametralmente opuestos desde sus mismos cimientos. HackiOS ofrece una lectura mucho más pragmática: XNU se descarga del repositorio abierto de Apple, el espacio de usuario se toma de la imagen oficial y el sistema responde. La verdadera barrera reside exclusivamente en el ecosistema de controladores y firmware privativo, un obstáculo forjado por volumen de horas de ingeniería y blindaje legal antes que por incompatibilidades insalvables de diseño.
Esto explica asimismo por qué no hace falta flashear el dispositivo: el sistema se ejecuta por completo en la memoria RAM, sin tocar las particiones de almacenamiento. No entraña riesgo de inutilizar el teléfono y no supone una amenaza comercial directa para los ecosistemas cerrados: un terminal sin datos celulares no puede reemplazar al teléfono de diario. Lo que se ha resquebrajado es el mito tecnológico; el modelo de negocio comercial sigue intacto.
En esto reside el valor de HackiOS: es un banco de experimentación, no un producto comercial. Ha revelado que el duelo de los sistemas operativos móviles no se decide en el kernel, sino en esa trinchera de controladores y firmware que ningún fabricante está dispuesto a liberar. Solo queda un hito por esperar: el día en que la conectividad móvil funcione. Cuando eso ocurra, este POCO que solo se descarga se habrá convertido, de verdad, en un iPhone.
Enlaces de referencia:
- Repositorio del proyecto HackiOS (README, historial de commits y capturas)
- Debate en Hacker News (item?id=50196718)
