Google c’est trop des dingos. Du jour au lendemain, ils transforme un écosystème entier juste parce que ça les fait marrer. Bon, j’abuse un peu, mais par exemple, hier, ils ont décider de s’attaquer à un problème épineux : Comment faire le ménage dans l’univers des apps Android sans pour autant tuer la poule aux oeufs d’or ?

Et leur solution ça va être d’exiger la vérification de l’identité des développeurs pour TOUTES les installations d’applications sur les appareils Android certifiés. Et quand je dis toutes, c’est vraiment toutes : Play Store, stores tiers, et même le fameux sideloading. Oui, je sais, ça vous stresse un peu, mais vous allez voir, c’est pour le bien de tout le monde.

Pour comprendre l’ampleur du changement, il faut savoir que jusqu’à présent, seuls les développeurs du Play Store devaient passer par cette vérification. Selon Android Authority , Google étend maintenant ce système à tous les canaux de distribution Android avec pour objectif de combattre les malwares et les arnaques financières qui pullulent dans l’écosystème.

Le processus de vérification lui-même ressemble à “un contrôle d’identité à l’aéroport”, selon Google. Il s’agit de confirmer l’identité du développeur sans pour autant examiner le contenu des applications. Notez qu’il y aurait 50 fois plus de malwares provenant du sideloading que du Play Store, donc c’est peut-être pas une si mauvaise idée.

Google a même prévu un système séparé pour les étudiants et les développeurs amateurs puisque ces derniers bénéficieront d’un processus de vérification allégé, différent de celui imposé aux développeurs commerciaux. C’est pas con, je trouve car ça évite d’écraser la créativité et l’apprentissage sous le poids des contraintes administratives. Donc normalement, vous pourrez toujours vous dev une app custom rien que pour vous sans que ce soit trop contraignant.

Cette mesure s’appliquera dès 2026, mais ça va se passer en plusieurs étapes. D’abord il va y avoir un programme d’accès anticipé en octobre 2025 pour les développeurs motivés, puis ensuite une ouverture complète du processus de vérification en mars 2026. Les premiers utilisateurs concernés seront au Brésil, en Indonésie, à Singapour et en Thaïlande dès septembre 2026, avant un déploiement final mondial en 2027.

Pour les développeurs déjà présents sur le Play Store, la transition devrait être relativement douce car la plupart remplissent probablement déjà les critères de vérification. La nouvelle Android Developer Console, spécialement conçue pour ceux qui ne distribuent que hors du Play Store, nécessitera les informations légales habituelles, un numéro D-U-N-S pour les organisations, et évidemment des frais de 25 dollars.

Google assure que leur but n’est pas de contrôler le contenu des applications, mais bien de s’assurer qu’on sache qui se cache derrière chaque app. D’ailleurs, les autorités gouvernementales des pays pilotes ont accueilli favorablement cette initiative, y voyant un moyen de protéger les utilisateurs tout en préservant l’ouverture d’Android.

Maintenant, reste à voir si l’écosystème suivra le mouvement ou si y’aura de la résistance…

Source

Xcode 15 sur un iPhone XS Max, ça vous dirait ? Non, je ne vous parle pas d’une app Remote Desktop ou d’un streaming depuis votre Mac. Je parle bien de macOS 13.4 qui tourne nativement sur un iPhone, avec le Dock, le Control Center et même le Finder. Le tout grâce à une bidouille absolument folle qu’un développeur a réussi à mettre au point.

Le responsable de cette prouesse technique, c’est Duy Tran (khanhduytran0), un dev qui a réussi l’impossible à savoir faire tourner le WindowServer de macOS (le processus qui gère toute l’interface graphique) sur un iPhone XS Max jailbreaké sous iOS 16.5. Bon, avant que vous sortiez votre iPhone pour tenter le coup, sachez que c’est extrêmement technique et que ça nécessite un jailbreak… ce qui n’est pas disponible sur les derniers modèles et versions d’iOS.

Ce qui est marrant dans toute cette histoire, c’est la méthode employée. Au départ, Tran a voulu utiliser les drivers GPU M1 d’Apple pour avoir l’accélération matérielle, mais son iPhone plantait en boucle. Pas découragé pour autant, il a trouvé une approche beaucoup plus maline qui est d’utiliser le système de streaming Metal du simulateur iOS via XPC. En gros, au lieu de faire tourner le GPU en natif, il a fait transiter les commandes graphiques par un protocole de communication inter-processus. C’est astucieux !

D’ailleurs, cette approche n’est pas sans rappeler ce que fait UTM SE pour iOS, une version spéciale de l’émulateur UTM qui utilise un interpréteur au lieu de la compilation JIT pour contourner les restrictions d’iOS. Sauf qu’ici, on ne parle pas d’émulation mais bien d’exécution native du code macOS. La différence ce sont bien sûr les performances et le fait que le système tourne directement sur le kernel Darwin partagé entre iOS et macOS.

Pour comprendre pourquoi c’est possible, il faut savoir que macOS et iOS partagent le même kernel XNU, un noyau hybride qui combine des éléments de Mach et de FreeBSD. C’est ce qui permet théoriquement de faire tourner du code macOS sur iOS, même si Apple a évidemment mis des barrières pour empêcher ça. Mais avec un jailbreak et beaucoup de patches manuels, ces barrières peuvent être contournées.

Le projet montre d’ailleurs que le jailbreak permet bien plus que de simples customisations visuelles. Ici, on parle de transformer complètement l’usage d’un appareil iOS. Par exemple, avoir un iPad Pro M4 qui ferait tourner macOS de manière native avec tous les drivers GPU optimisés… Ce serait le rêve pour beaucoup d’utilisateurs qui attendent depuis des années qu’Apple fasse converger ses systèmes.

Actuellement, le système a ses limites car le contrôle se fait via VNC (donc clavier et souris à distance), il y a des bugs graphiques à cause des limitations du simulateur Metal, et surtout, ça nécessite, comme je vous le disais, un appareil jailbreaké. Mais selon Tran, la solution fonctionnerait particulièrement bien sur les iPad avec puce M, qui ont les mêmes drivers GPU natifs que les Mac.

Ce qui est intéressant aussi, c’est qu’Apple travaille justement sur le durcissement de son kernel XNU avec un système appelé “exclaves” qui isole des ressources critiques du kernel principal. C’est une nouvelle version de l’architecture de sécurité qui rendrait ce genre de bidouille encore plus difficile à l’avenir puisque les exclaves créent des domaines isolés qui protègent des fonctions clés même si le kernel est compromis.

Pour les curieux, Tran a publié son repository GitHub avec tous les patches nécessaires, mais attention, c’est vraiment pour les experts. Il faut patcher manuellement de nombreux composants système, gérer les problèmes de mémoire partagée entre processus, et contourner les restrictions de chargement des bundles XPC. Donc pas vraiment le genre de truc qu’on fait en suivant un tuto YouTube de 5 minutes. Et ne comptez pas sur moi pour vous faire ça en vidéo… lol.

Cela prouve qu’Apple pourrait techniquement faire tourner macOS sur iPad sans trop d’efforts. Les bases techniques sont là, le hardware en est capable, et visiblement même un iPhone peut gérer l’interface de macOS. Mais alors pourquoi Apple ne le fait pas ? Probablement pour des raisons de positionnement produit et de revenus car un iPad qui ferait tourner macOS cannibaliserait les ventes de MacBook.

En attendant qu’Apple se décide (ou pas), des projets comme celui-ci montrent que la communauté du jailbreak continue d’explorer les limites de ce qui est techniquement possible avec le matériel Apple. Et voir Xcode tourner sur un iPhone, même si c’est juste pour la beauté du geste, c’est quand même assez impressionnant.

Voilà, donc si vous avez un vieil iPhone jailbreaké qui traîne et que vous aimez les défis techniques, pourquoi ne pas tenter l’expérience ? Au pire, vous aurez une bonne histoire à raconter. Au mieux, vous pourrez dire que vous faites du développement iOS… sur iOS.

Source