Lors de son discours d’ouverture de la WWDC, Apple a annoncé sa transition vers l’architecture ARM qui durera deux ans. Elle se concrétisera à la fin de l’année par de nouveaux Mac avec des SoC maison (mais aussi des machines Intel). Les questions pour les développeurs sont nombreuses. Voici ce qu’il faut en savoir.

La grande annonce d’Apple avait été quelque peu soufflée depuis des semaines par des rumeurs de plus en plus précises. Il est devenu rare que la firme puisse encore surprendre, tant elle est scrutée de près. Et c’est encore plus vrai quand l’annonce touche un sujet aussi sensible que l’architecture utilisée pour le CPU de ses machines.

Le passage à Apple Silicon sera la troisième grande transition de l'entreprise, après l’abandon de l’architecture 68000 de Motorola pour PowerPC en 1994, puis celle de PowerPC pour Intel en 2005. Des bascules significatives à chaque fois, réclamant un gros travail des développeurs pour adapter aussi bien le système que le parc applicatif.

• Mac à base d'Apple Silicon : la fin d'une ère, AMD et Intel réagissent

La transition vers Intel, qui s’était bien déroulée, sert d’ailleurs de modèle. On retrouve ainsi Rosetta et les binaires Universal. Une reprise de noms pour des concepts finalement logiques : assurer la compatibilité des applications actuelles sur les prochains Mac à base de SoC ARM et distribuer les prochaines pour les deux architectures.

Car même si la fin de l’année verra l’arrivée de nouvelles machines utilisant les puces Apple Silicon, d’autres modèles Intel continueront de sortir entre temps. Les deux vont cohabiter pendant un certain temps.

Steve Jobs lors de l'annonce de la transition vers Intel pendant la WWDC 2005

Qu’est-ce qu’Apple Silicon ?

C’est le nom générique désormais donné par Apple à ses puces ARM, dont celles qui équiperont ses Mac. L’entreprise n'y intègrera pas directement les puces Ax de ses iPhone et iPad, mais s’appuiera sur le travail déjà fait pour pousser plus loin les fonctions et performances.

• Apple vante ses SoC ARM, leurs fonctionnalités et la restauration de ses prochains Mac

Quelle architecture les développeurs devront-ils viser ?

La même que pour iOS/iPadOS : arm64. C’est l’une des idées les plus reprises par Apple dans sa communication aux développeurs. S’ils ont déjà créé des applications mobiles, alors ils compilent pour arm64, l’architecture des puces Ax depuis bien longtemps.

Conséquence d’ailleurs pour les applications iOS/iPadOS  – qui pourront fonctionner presque en l’état sur macOS Big Sur – le code pourra être repris en l’état. C’est du moins l’idée vendue, car on sait qu’une transition n’est jamais aussi simple.

L’objectif visé par Apple est de ne plus avoir à terme qu’une seule architecture, adaptée à ses différents appareils.

Quand la migration commencera-t-elle ?

On ne sait pas encore. Apple a présenté les grandes lignes pendant son Keynote d’ouverture, mais les détails sont pour l’instant techniques et à destination des développeurs.

Pour se « faire la main », ces derniers peuvent commander un Developer Transition Kit (DTK) vendu 500 dollars, qu’il faudra rendre ensuite. Il embarque une puce A12 (iPhone XS) modifiée (A12Z), épaulée par 16 Go de mémoire et un SSD de 512 Go. Son utilisation implique de ne pas parler de ce matériel avec qui que soit. Les testeurs ont également l’interdiction de lancer le moindre benchmark, ce qui n'empêche pas de premières fuites.

Il est probable qu’Apple se laisse de la marge pour surprendre sur le plan des performances, puisque c’est là qu’on attend le plus le constructeur. Si l’on en croit les rumeurs actuelles, un MacBook et un iMac seraient lancés vers la fin de l’année ou début 2021. La migration devrait s’étaler sur deux ans. On imagine que les machines les plus puissantes seront gardées pour la fin, le temps que la puissance des puces grandisse encore.

Ce qui attend les développeurs

On entre dans le vif du sujet. Apple s’est fait fort de communiquer intensément sur la facilité que les développeurs auront à « convertir » leurs applications pour l’architecture arm64. En fait, une part importante d’entre elles ne devrait pas requérir de modification particulière, ou alors de manière légère.

Les applications existantes, prévues pour x84_64, fonctionneront via Rosetta 2 sur les prochains Mac ARM. Apple promet, là encore, des performances à la hauteur. Mais tout le monde attend bien sûr de voir des résultats concrets, car la communication – qui cherche surtout à rassurer sur ce point – ne saurait remplacer de véritables résultats sur des applications plus ou moins gourmandes ou même le ressenti de l’utilisateur face à sa machine.

Les développeurs sont largement encouragés cependant à mettre à jour leurs applications afin de les compiler nativement pour arm64. Xcode 12, dont la bêta peut être récupérée depuis le site Apple Developer (elle réclame au moins Catalina 10.15.4 pour fonctionner), permet de générer des paquets Universal 2, qui réuniront les version Intel et ARM du code.

Ce sera d’ailleurs le mode par défaut pour toute nouvelle compilation. Dans le cas où des makefiles ou scripts personnalisés seraient utilisés, arm64 devra être ajouté manuellement.

Le code ainsi généré sera proposé pour validation sur le Mac App Store ou stocké sous forme de DMG sur le site de l’éditeur concerné. Dans le premier cas, c’est la boutique qui sera chargée ensuite d’envoyer les bons binaires vers la machine cible. Dans le second, le DMG contiendra les deux versions et installera celle adaptée. Une situation identique aux premiers Universal Binaries, quand ils contenaient les binaires PowerPC et Intel.

Il s’écoulera nécessairement une période – qu’Apple veut la plus courte possible – où les machines ARM auront face à elles nombre d’applications encore exclusivement prévues pour l’architecture x86_64. Mais que les développeurs soient prêts, car Apple enclenchera tôt ou tard un mécanisme dont elle a l’habitude : imposer ses conditions.

Il y a fort à parier que les règles du Mac App Store seront mises à jour afin que les nouvelles applications et mises à jour soient obligatoirement en Universal 2. Potentiellement avant que Big Sur n’arrive, afin que le parc applicatif ait le temps de « mûrir » dans les mois qui précèderont l’arrivée de cette nouvelle génération de Mac.

Il y aura des erreurs

Même si le message est centré sur le mot « facilité », il arrivera souvent que la compilation arm64 génère des erreurs. Car le code devra pouvoir être compilé aussi bien pour tout ce qui touche à l’interface graphique (GUI) qu’à l’espace utilisateur. La transition devient encore plus complexe pour les outils systèmes et/ou ayant besoin d’un accès particulier au matériel.

Apple a consacré pendant sa WWDC une vidéo de 40 min environ au sujet, avec des exemples simples. Même si Xcode 12 est prévu pour mâcher une partie du travail, les développeurs ne pourront pas éviter de plonger les mains dans le cambouis, car il existe d’importantes différences entre les architectures x86_64 et arm64, même si les paramètres de compilation n’auront pas besoin d’être modifiés.

Par exemple, la taille des pages CPU est de 4 ko pour Intel, mais 16 ko pour arm64. La macro PAGE_SIZE n’est donc plus une constante et Apple donne des méthodes alternatives dans sa vidéo. Notez que Rosetta 2 fournira automatiquement des pages de 4 ko pour les applications Intel sur Mac ARM.

Le problème s’étend à toutes les différences architecturales : fonctions variadiques, mémoire pouvant simultanément être écrite et exécutée, compilation Just-in-Time, threads temps réel, priorités explicites des threads et ainsi de suite.

Les développeurs devront également renoncer à des instructions spécifiques, notamment AVX, AVX2 et AVX512. Si des applications y font appel, leur compilation pour arm64 génèrera des erreurs. Les optimisations liées devront être soit remplacées par des équivalents – s’ils existent – soit supprimées, purement et simplement.

Une consolation tout de même, le boutisme des deux architectures est le même : little-endian.

S’éloigner des spécificités, des anciennes technologies et du matériel

Apple recommande aux développeurs d’analyser leur code à la recherche des éléments suivants :

• Interactions avec des bibliothèques tierces (donc sous contrôle d’une autre personne, physique ou morale)
• Interactions avec le noyau ou le matériel
• Besoins de comportements spécifiques du GPU
• Instructions en assembleur
• Gestion ou optimisation particulière des threads
• Code spécifique à un certain matériel ou des optimisations de performances

L'entreprise présente cette liste comme un point de départ : elle donne une idée des pans de code pouvant poser problème à la compilation. Cas classique, celui des bibliothèques tierces. Cupertino rappelle donc que tout le code d’un même processus doit s’adresser à une même architecture. Il ne sera par exemple pas possible de produire une version universelle si les bibliothèques tierces n’ont pas évolué.

Ce qui explique d’ailleurs qu’il ne faudra pas compter sur Rosetta pour se charger d’une partie de code non traduite. Un processus est soit exécuté nativement, soit traduit, dans les deux cas en intégralité.

Il est chaudement recommandé aux développeurs de s’éloigner d’un certain nombre d’anciennes technologies dépréciées comme OpenGL et OpenCL, pourtant supportées par les puces Apple Silicon. La solution proposée est bien entendu de passer à Metal. D’autres anciennes API comme AdressBook ou celles de Carbon ne devraient plus être utilisées, même si Big Sur restera compatible. Le fonctionnement des applications ne sera cependant pas garanti.

L’accès au matériel change également avec Big Sur (macOS 11). Tout pilote devra obligatoirement avoir été créé depuis DriverKit. Les développeurs d’extensions noyau devront probablement y avoir recours aussi. Globalement, Apple suggère de laisser ses technologies de haut niveau s’occuper de la plupart des aspects, et donc de ne plus réaliser soi-même certaines tâches de bas niveau, notamment dans la gestion des threads.

Pour ce point, la firme demande aux développeurs de laisser Grand Central Dispatch s’occuper du travail, afin notamment que le code soit analysé et les actions réparties entre les cœurs d’exécution qui sont asymétriques (2 performants et 4 basse consommation pour les derniers en date). GCD ne pourra bien sûr pas paralléliser de lui-même le code. Il incombera toujours aux développeurs de découper les tâches lourdes afin que Dispatch puisse créer ses files d’attente.

Apple reconnait toutefois que sa technologie ne peut pas prendre en charge tous les cas, et que les développeurs pourront être amenés parfois à gérer eux-mêmes les threads et les optimisations de performances. La société y consacre d’ailleurs une fiche récapitulative.

Apple très active sur l’aide aux projets open source

Elle ne compte pas attendre que les développeurs gèrent par eux-mêmes la transition, intervenant parfois directement. Elle a ainsi annoncé une aide à bon nombre de projets open source.

Parmi les plus importants, Chromium, même si Microsoft avait largement préparé le terrain en s’occupant de la compatibilité avec Windows on ARM. Bien que la plateforme finale soit différente, le code de Chromium est censément déjà compilable pour arm64. Il devrait donc plus s’agir d’un travail de finition.

On trouve également Electron, le framework permettant de développer des applications multiplateformes avec les technologies du web. Là encore une participation essentielle, puisque les nouveaux Mac s’assureront une compatibilité d’emblée avec de nombreuses applications connues. Skype pour ordinateurs l’utilise par exemple.

Les gestionnaires de paquets Homebrew et MacPorts, la plateforme .NET Mono, les langages Go et Python 3, la bibliothèque Qt, le framework Node.js ainsi que Nginx, Bgfx, Blender, Boost, Skia, Zlib-Ng, cmake, FFmpeg, Halide, Pixar USD, Swift Shader, nmap, OpenCV, OpenEXR, OpenJDK, SSE2Neon, Redis, Cineform CFHD, et V8 sont aussi dans la boucle.

La participation active d’Apple ne repose bien sûr pas que sur la générosité. En annonçant aller spontanément aider les développeurs, l’entreprise s’assure aussi que le sujet de transition est bien sur la table. Plus globalement, elle veut inciter par l’exemple. Si de grandes entreprises comme Adobe et Microsoft travaillent déjà à la recompilation de leurs produits pour arm64 et que de nombreux projets open source en font état, le mouvement est d’autant plus visible.

Catalyst nettement enrichi

Catalyst est pour rappel une technologie lancée l’année dernière avec macOS Catalina. Elle permet à des applications iPad d’être transformées en versions macOS, en adaptant le code automatiquement et en laissant les développeurs s’occuper des finitions. Elles peuvent d’ailleurs s’avérer nombreuses, car il faut s’assurer non seulement que l’interface correspond aux canons Mac, mais aussi des interactions, car passer du 100 % tactile au duo clavier/souris n’est pas toujours si simple.

Catalyst a cependant une grosse limitation : de nombreuses API spécifiques à iOS n’ont aucun équivalent sur Mac. Il fallait donc que les développeurs placent dans leur code des exclusions conditionnelles. Le retard est maintenant rattrapé.

Puisque les applications iOS peuvent en théorie s’exécuter sans modification sur Big Sur, il fallait que Catalyst suive le mouvement. Ce qui inclut des ajouts récents comme la gestion des évènements clavier dans iOS, disponible pour Catalyst dans la dernière révision de Catalina et la bêta de Big Sur. Un support crucial, car des actions aussi simples qu’utiliser les flèches du clavier n’étaient pas permises dans les applications iPad après leur transition vers le Mac.

Dans la même veine, la méthode NSCursor est également supportée, permettant des actions supplémentaires sur le curseur de la souris. Par exemple le rendre invisible dans certains contextes (comme la lecture d’une vidéo) ou lui faire adopter une forme différente selon son positionnement (curseur texte, marqueur de redimensionnement, symbole d’ajout, etc.). Des actions très classiques auxquelles, là encore, les applications Catalyst n’avaient pas droit.

Parmi les autres contrôles maintenant autorisés, on trouve le sélecteur de couleurs (qui renvoie vers l’interface standard de macOS), le sélecteur de date et d’heure, les menus pull-down, les fenêtres popover, le support de trois colonnes pour UISplitViewController ou encore celui de SF Symbols.

Catalyst propose en outre un nouveau mode baptisé « Optimized for Mac », qui proposera aux développeurs des étapes supplémentaires pour s’assurer que l’interface de l’application est bien adaptée à macOS. La mise à l’échelle, actuellement de 77 %, passe notamment à 100 %. De nouveaux éléments y seront proposés, comme les cases à cocher.

C’est également l’occasion pour Apple de remettre en avant sa technologie SwiftUI, qui permet pour rappel de concevoir des interfaces en les modélisant graphiquement, créant le code Swift correspondant. Si une application a été entièrement conçue avec SwiftUI, elle n’aura pas besoin de Catalyst pour être envoyée sur Mac.

Au sujet des applications iOS sur Big Sur

Comme dit, la transition vers ARM déverrouille une possibilité attendue de longue date sur l’écosystème Apple : la capacité de faire fonctionner des applications iOS directement sur un Mac équipé d’une puce Apple Silicon, en les récupérant depuis l’App Store. La thématique semble fortement liée à Catalyst, mais est pourtant différente.

Cette possibilité renvoie en effet au fonctionnement natif et sans recompilation d’une application, qui sera donc exécutée telle quelle. Il ne s’agit pas de prévoir à l’avance qu’elle sera exécutée sur macOS, en prévoyant des contrôles spécifiques et une compilation s’appuyant sur le SDK idoine. Comme on s’en doute, il y aura des avantages et inconvénients.

Gros avantage : nul besoin de toucher à quoi que ce soit pour de nombreux comportements comme la génération de fenêtre, l’intégration à la barre Menu, le panneau des préférences, le Dock, le mode sombre, la gestion du texte, les panneaux des polices et couleurs, la Touch Bar, l’impression, les notifications et le glisser-déposer.

Gros inconvénient : il ne faudra pas en demander plus. C’est toute la différence entre ce fonctionnement et celui d’une application passée à la moulinette de Catalyst. Apple l’explique clairement dans sa vidéo dédiée au sujet. Si un développeur veut pousser plus loin, avoir des contrôles spécifiques, mieux intégrer son application dans macOS et profiter des API et frameworks de ce dernier, il faudra travailler un peu.

En outre, pour qu’une application iOS puisse fonctionner sur macOS 11, elle ne devra être dépendante d’aucun framework qui ne serait pas présent nativement dans le système. Plus surprenant, Apple avertit que toute application détectée comme compatible sera automatiquement proposée sur le Mac App Store.

Les développeurs, bien sûr, auront le dernier mot. Ils peuvent s’y opposer pour de nombreuses raisons : présence d’une application dédiée pour macOS, intérêt financier, expérience utilisateur jugée inférieure (avec risque de mécontentement des utilisateurs), etc. Mais même dans le cas d’une compatibilité automatique, Apple pointe trois domaines de différences marquées entre les environnements iOS et macOS : matérielles, d’interface et de système.

Les différences matérielles comprennent notamment les interactions très différentes entre l’un et l’autre. iOS s’appuie sur des interactions tactiles directes, macOS sur le clavier et la souris, indirects. La majorité des manipulations tactiles sont traduites automatiquement en équivalents clavier/souris, mais les gestes personnalisés auront besoin de débouchés spécifiques. De même, il faudra prévoir quoi faire dans le cas d’applications s’appuyant sur les capteurs des appareils mobiles : accéléromètre, gyroscope, magnétomètre, profondeur de champ et GPS. Notez que la fonction GPS sera automatiquement liée à CoreLocation sur Mac. La position obtenue sera moins précise, mais fonctionnelle.

Pour l’interface, Apple insiste pour que les développeurs s’en remettent aux méthodes existantes, sans chercher à réinventer la roue, particulièrement sur des actions comme sélectionner un fichier. De même, le recours à AutoLayout permettra aux applications d'être redimensionnées de manière cohérente. Mais ces constats sont vrais uniquement pour celles destinées aux iPad. Une exclusivement pensée pour iPhone, comme Instagram, s’exécutera dans une fenêtre de taille fixe (il est probable que Facebook en bloque la publication sur le Mac App Store).

Une grande partie du travail est déjà accomplie par Apple. Mais puisque l’éditeur ne peut prendre en compte les comportements personnalisés créés par les développeurs, la traduction automatique se fera sur la base des API et frameworks qu’il connait, les siens. Plus une application s’appuiera dessus, moins il y aura de travail d’adaptation.

De nombreuses réponses encore en attente

Cette transition, attendue depuis des années, va procurer à Apple de nombreux avantages. Pour une société tablant sa réussite sur l’intégration serrée du matériel et du logiciel, le contrôle de la puce centrale est un élément crucial. En outre, c’est un sérieux mouvement de simplification dans la technique des gammes. À terme, les développeurs ne cibleront qu’une seule architecture – arm64 – et un lot grandissant d’API de haut niveau, communes à toutes ses plateformes.

C’est également une démonstration de maitrise technique, car Apple a une longueur d’avance dans le domaine des SoC. Ses puces Ax font systématiquement mieux que la concurrence, au point que l’on se retrouve aujourd’hui avec un iPhone SE à 489 euros dont les performances surpassent des modèles vendus plus de 1 000 euros. La majeure partie des constructeurs Android est dépendante de Qualcomm pour ses SoC milieu et haut de gamme.

La feuille de route des Mac sera ainsi débarrassée d’Intel, dont les développements ces dernières années ont accumulé trop de retard. Mais cette indépendance a un prix : l’utilisateur doit n’y voir, si possible, que du feu. Plus la transition sera invisible, plus l’entreprise aura réussi son pari. Car Apple sera largement attendue sur deux aspects : les performances et la logithèque. Il est probable qu’elle ait dans ses cartons de « bonnes surprises » en préparation.

Des performances décevantes ou trop limitées hors de l'utilisations de certains accélérateurs seraient d’emblée un facteur bloquant d’achat. La question de la logithèque est beaucoup plus complexe. Qu’Adobe propose son Creative Cloud ou Microsoft sa suite Office ne répond pas à toutes les questions. Se posera particulièrement le cas des jeux : dans quelle mesure les titres actuellement prévus pour les Mac Intel et exploitant des GPU AMD ou NVIDIA pourront-ils fonctionner ?

Transiter vers ARM signifie exploiter également la partie graphique intégrée. macOS pourrait devenir paradoxalement la plus grande plateforme de jeux, pour peu que ceux pour iOS s’y déversent. Les studios concernés auront le dernier mot. La présence ou non des Radeon dans cette nouvelle aventure n'a pour le moment pas été confirmée.

Cette grande transition venant tout juste d’être annoncée, les informations continueront d’arriver progressivement dans les mois à venir. La situation devrait être beaucoup plus claire d’ici la sortie de Big Sur puisque le système, en plus de présenter un important renouvellement, alimentera les futurs Mac équipés de puces Apple Silicon.

On en saura également davantage sur le fonctionnement des applications iOS sur Big Sur, en particulier qui autorisera quoi. Il est peu probable par exemple que Microsoft laisse les applications iOS Word, Excel et PowerPoint être reprises telles quelles dans le Mac App Store.