Démarrer un smartphone Android pour y découvrir iOS 16.5
Prenez en main un Xiaomi POCO X5 Pro 5G : l’écran de verrouillage, les gestes de navigation et le Centre de contrôle répondent rigoureusement comme sur iOS 16.5. Dans Réglages > Général > Informations, l’appareil s’identifie comme un iPhone X. Pourtant, le smartphone n’a pas été flashé et ses partitions n’ont subi aucune modification. Le système complet démarre en mémoire vive grâce à la commande fastboot boot. Un simple redémarrage, et le téléphone repasse immédiatement sous Android.
Cette prouesse est signée HackiOS, un projet open source qui a porté le noyau open source XNU d’Apple (xnu-8796.121.2, correspondant à iOS 16.5) sur l’architecture Snapdragon. Il initialise un espace utilisateur iOS 16.5 strictement intact, extrait d’un fichier officiel IPSW : launchd, backboardd et SpringBoard s’exécutent en cascade et les applications se lancent. Mis en ligne le 22 octobre, le dépôt GitHub a recueilli 489 étoiles et 93 forks en l’espace de vingt-quatre heures.
Ce que cette expérience met en lumière dépasse largement le défi technique du portage : la véritable frontière entre les systèmes d’exploitation mobiles ne réside pas dans le noyau, mais dans les couches de pilotes et de microprogrammes fermés.
Figure : Écran d’accueil iOS fonctionnant sur un téléphone Android. Source : Dépôt HackiOS
Le noyau a toujours été open source : le verrou est ailleurs
Apple publie le code source de son noyau XNU depuis l’an 2000. Les noyaux de macOS et d’iOS sont accessibles à tous sous la licence APSL (Apple Public Source License), qui autorise leur modification et leur redistribution. De fait, le dépôt de HackiOS ne contient pas la moindre ligne de code propriétaire Apple : les utilisateurs extraient eux-mêmes l’espace utilisateur depuis les archives officielles de restauration, écartant tout litige sur la distribution.
Si le noyau constituait le véritable rempart entre les plateformes, un tel projet aurait abouti il y a vingt ans. La raison de ce délai est évidente : une fois le noyau initialisé, il doit communiquer avec les composants matériels, ce qui nécessite des pilotes. Or, les pilotes d’Apple Silicon et des périphériques propriétaires sont des binaires fermés jalousement gardés par Cupertino, inaccessibles et non concédés sous licence.
L’équipe de HackiOS a choisi de réécrire cette couche dans son intégralité : conception d’un chargeur EFI sur mesure pour piloter l’amorçage, développement de pilotes maison pour relayer les modules fermés d’Apple, portage de l’environnement UEFI sur l’appareil et intégration d’une couche de compatibilité pour exploiter les pilotes Wi-Fi développés par la communauté Linux pour Snapdragon. La séquence de démarrage est limpide : fastboot boot initialise l’environnement UEFI (issu du projet Silicium), qui exécute l’application EFI xnuloader, avant de transférer l’exécution au noyau modifié.
Le noyau peut être emprunté à l’open source ; les pilotes doivent être réécrits un par un. C’est précisément ainsi que se mesure l’épaisseur réelle de la muraille.
Figure : Page Réglages > Général indiquant le modèle iPhone X. Source : Dépôt HackiOS
Ce qui fonctionne, ce qui bloque, et un détail éloquent
Le périmètre fonctionnel dépasse les espérances : écran de verrouillage, navigation gestuelle, Centre de contrôle, Réglages et applications intégrées sont opérationnels. Les captures du fichier README illustrent l’écran d’accueil, l’Horloge, le Calendrier, Musique, Cartes, Plans et Messages. Même les onglets de l’App Store s’affichent correctement — bien que le chargement des données et la connexion au compte Apple ID échouent en raison de l’absence physique de l’enclave sécurisée Secure Enclave.
Les fonctionnalités inopérantes sont encore plus instructives : les réseaux cellulaires et le Bluetooth sont aux abonnés absents. La raison renvoie directement aux pilotes : les échanges d’initialisation du modem bande de base et de la puce Bluetooth se situent au niveau le plus hermétique des micrologiciels propriétaires, hors de portée d’une simple couche d’émulation. Ces deux fonctions tracent très exactement la ligne de partage entre un téléphone fonctionnel et une carte de développement animée d’une belle interface.
Un détail matériel mérite une attention particulière : sous ce noyau, la charge de la batterie ne fonctionne pas et le téléphone ne fait que se décharger. La gestion de l’alimentation par port USB repose sur un autre protocole de microprogramme propriétaire dont les spécifications n’ont pas encore été percées. Un smartphone qui perd de l’énergie alors même qu’il est branché sur secteur illustre le fossé des pilotes plus concrètement que n’importe quel schéma d’architecture.
Figure : Centre de contrôle. Source : Dépôt HackiOS
L’obstacle de l’appareil photo également franchi
Dans les discussions communautaires, le module photo a cristallisé une grande part des interrogations. Dans l’écosystème Linux sur smartphone, la prise en charge de la caméra représente traditionnellement l’un des défis les plus ardus. Pourtant, dans le tableau des fonctionnalités du README, l’application Appareil photo indique que les objectifs avant et arrière, la prévisualisation en direct, la mise au point automatique et la capture au format HEIC sont pleinement opérationnels : la chaîne d’affichage GPU une fois maîtrisée, la prise en charge de la caméra a pu suivre.
Un autre élément a retenu l’attention des développeurs dans l’historique des commits : la mention Co-Authored-By: Claude Opus 5.5. Le README clarifie sans détour la vocation du projet : il s’agit d’un banc d’essai dédié à la recherche technique, et non d’une ROM destinée à un usage quotidien. Chaque session ne dure qu’un nombre défini de secondes avant que le noyau ne soit réinitialisé dans un état propre, produisant des journaux nets propices au travail méthodique d’agents d’automatisation IA. Avant la libération du code le 22 octobre, le projet n’avait montré que des vidéos sans instructions de compilation, suscitant un certain scepticisme quant à sa reproductibilité. Dès la publication des sources, les doutes se sont dissipés.
L’équipe du collectif OOSEX GANG réunit quatre développeurs : initié par @oodze, épaulé par @netusd, @wannqn et @hxfuxyyXD. Quatre développeurs combinés à des outils de programmation assistés par IA ont accompli un travail qui aurait autrefois nécessité toute une équipe d’ingénierie inverse.
La rhétorique des constructeurs confrontée aux faits
Depuis des années, le discours officiel des fabricants laisse entendre qu’iOS et Android reposent sur des fondations techniques totalement étrangères l’une à l’autre. HackiOS en donne une illustration beaucoup plus pragmatique : XNU fonctionne dès lors qu’on compile ses sources publiques, et l’espace utilisateur tourne tel quel une fois extrait de l’image officielle. Le cloisonnement véritable n’existe qu’au niveau des pilotes et des microprogrammes propriétaires — une barrière érigée à coups de volumétrie d’ingénierie et de verrouillage juridique, bien plus que par incompatibilité architecturale fondamentale.
Cette réalité éclaire également pourquoi le projet se passe de tout flashage : le système réside exclusivement en mémoire vive, sans jamais toucher aux partitions de stockage de l’appareil. L’utilisateur ne court aucun risque de briquer son matériel, et la forteresse commerciale des constructeurs n’est nullement menacée dans l’immédiat : privé de réseau cellulaire, l’appareil ne saurait devenir un smartphone du quotidien. C’est le mythe technique qui a volé en éclats ; le modèle économique, lui, n’a pas perdu une seule brique.
C’est là tout l’intérêt de HackiOS : un banc d’expérimentation pour la recherche, et non un produit fini. Il montre que la bataille des systèmes d’exploitation mobiles ne se gagne pas au niveau du noyau, mais dans cette tranchée obscure des pilotes et des firmwares qu’aucun géant de la tech n’est prêt à ouvrir. Une seule échéance reste désormais à guetter : le jour où la connectivité cellulaire sera opérationnelle. Ce jour-là, ce POCO qui ne sait que se décharger deviendra véritablement un iPhone.
Liens utiles :
- Dépôt du projet HackiOS (README, historique des commits et captures d’écran)
- Discussion sur Hacker News (item?id=50196718)
