AppKit, Catalyst, Cocoa, Marzipan, SwiftUI, UIKit… Cette liste ne vous inspire rien d’autre que des frissons ? C’est normal : cette soupe à l’alphabet n’a fait qu’épaissir au fil des années. Mais pour comprendre l’importance du projet Catalyst lancé à la WWDC 2019, et envisager les conséquences de SwiftUI, il faut connaitre ces mots. Revenons donc aux bases… et vingt ans en arrière.

Nous sommes en mai 1997. Apple vient d’acheter NeXT, Gil Amelio est encore CEO, mais Steve Jobs a déjà repris la barre. Au cours de la WWDC, il présente le système d’exploitation Rhapsody. Construit sur les ruines de NeXTSTEP, il conserverait une compatibilité avec les applications Mac OS par le biais de la Blue Box, et apporterait les innovations de NeXT par le biais de la Yellow Box.

En pleine transition technologique, Apple ne ferme aucune porte. Le noyau XNU développé par NeXT peut être remplacé par le noyau NT de Microsoft, ou un noyau Linux. La Blue Box spécifique au Macintosh peut être remplacée par un environnement Windows ou GNU/Linux, auquel cas l’interface Platinum de Mac OS laisse place au Windows shell ou une interface X11. Dans cette optique, la Yellow Box occupe une place centrale, elle qui renferme le cœur des technologies de NeXTSTEP.

La Yellow Box contient notamment Foundation Kit, la couche de base des fonctions des applications et des frameworks, et AppKit, qui fournit tous les objets pour construire l’interface d’une application. Apple affine ses choix technologiques, sous l’œil attentif de Microsoft et d’Adobe, les plus grands développeurs tiers. Rhapsody fera une brève apparition sous la forme de Mac OS X Server 1.0 en 2000, mais laisse place à Mac OS X, qui dispose d’une nouvelle architecture, dès juin 1998 (lire : Rétro MacG : Mac OS X est désormais plus vieux que Mac OS).

La Blue Box devient Classic, une couche de virtualisation de l’ancien Mac OS. Carbon fait le lien entre l’ancien et le nouveau monde, en permettant d’adapter les applications Mac OS 8/9 à Mac OS X. La Yellow Box devient Cocoa, le chocolat qui répond au café de Java¹, qui aurait bien pu devenir l’environnement de développement du Mac. L’interface Platinum vieillissante laisse place à Aqua, si belle « qu’on voudrait la lécher ».

Après quelques années, Mac OS X parvient à une certaine maturité. Puisque le souvenir de Platinum s’estompe, Apple ne mentionne plus Aqua, ou alors seulement en passant. L’environnement Classic disparait, et les développeurs sont invités à utiliser Cocoa plutôt que Carbon. Les rôles des différentes couches du système sont réorganisés et précisés.

« Oui mais justement, c’est quoi, leur rôle ? » Merci d’avoir demandé. Le noyau XNU est un noyau hybride, basé sur une implémentation libre du micronoyau Mach (OSFMK) et le noyau BSD. Cette couche basse du système gère l’accès aux ressources matérielles (système de fichiers, réseau, sécurité matérielle) et les pilotes (I/O Kit), ainsi que la communication entre les processus (XPC et IPC).

Core OS, littéralement le « système central », gère le paramétrage des composants matériels (System Configuration), l’identification (Open Directory), le montage des volumes de stockage, ainsi que les dispositifs de sécurisation des applications (sandboxing, Gatekeeper).

Core Services regroupe toutes les briques qui permettent de construire une application, du stockage (Core Data, Trousseau) à la synchronisation (CloudKit) des données, en passant par la communication avec le réseau (WebKit, Bonjour) et les ressources matérielles (Grand Central Dispatch), ainsi que l’installation et la distribution des applications. Les technologies permettant de créer des graphismes 2D et 3D, ou de manipuler le son et l’image, ont été récemment regroupées dans leur propre couche Media.

Enfin, la couche applicative regroupe tous les frameworks permettant de créer les parties visibles d’une application. On y retrouve Foundation et AppKit, qui restent des briques centrales dans la conception des applications Mac. AppKit permet de créer des fenêtres, des contrôles, des menus, des boites de dialogue ; de gérer les documents et les fenêtres ; de contrôler le presse-papier et l’enregistrement des données ; et généralement de coordonner le comportement des applications.

Apple a créé iOS à partir de Mac OS X, mais plutôt que d’adapter AppKit aux spécificités des écrans tactiles et de la manipulation directe, elle a préféré concevoir un « AppKit pour iOS ». UIKit, c’est son nom, permet de créer des vues et de réagir aux manipulations tactiles ; de gérer les documents et les données ; et généralement de coordonner le comportement des applications.

L’iPhone a servi de banque d’organes logiciels pour les autres appareils. L’Apple TV comme l’Apple Watch utilisent des systèmes dérivés d’iOS, qui intègrent une version spécifique d’UIKit, avec des éléments adaptés au grand écran du téléviseur comme au petit écran de la montre. Autrement dit, macOS est maintenant le seul système qui n’intègre pas UIKit. C’est précisément le « problème » que le projet Catalyst, autrefois connu sous le nom de Marzipan, vise à résoudre (lire : « Marzipan » : Apple veut-elle fusionner iOS et macOS ? et UIKit sur Mac : l’avis des développeurs sur le projet Marzipan).

Pour débarquer sur macOS, UIKit a dû apprendre à gérer plusieurs fenêtres qui peuvent être redimensionnées arbitrairement, à répondre au clic d’une souris, à remplir la barre de menus, ou encore à dessiner les éléments d’interface comme AppKit le fait. Mais soyons bien clairs, UIKit pour Mac est encore loin d’égaler AppKit, et il est probable qu’il ne le fera jamais.

Dans son implémentation actuelle, il rappelle furieusement la Blue Box. Allez fouiller dans le dossier Système, et vous trouverez un dossier iOSSupport, qui n’est pas loin d’être une version d’iOS intégrée à macOS ! Le projet Catalyst est moins une adaptation d’UIKit au Mac qu’une intégration au chaussepied. Dans l’état, c’est un pansement sur une jambe de bois, une manière de faciliter le portage des applications iOS vers macOS sans résoudre les problèmes de fond.

Reste qu’il produit des effets intéressants. Prenez iPadOS 13 : si l’iPad peut afficher plusieurs fenêtres d’une même application, ou réagir au pointeur d’une souris, c’est grâce au travail mené sur UIKit pour Mac (lire : Le projet Marzipan, une chance pour le Mac… et l’iPad). Dès le printemps prochain, toutes les applications iPhone devront être adaptées à l’iPad, si elles ne le sont pas encore. Dès lors, elles pourront être adaptées au Mac d’une case à cocher, grâce au projet Catalyst.

Le rêve des applications universelles, et d’un App Store unifié, commence à prendre forme. Mais le projet Catalyst n’est que le premier pas. Le futur, c’est probablement un framework commun à tous les systèmes, qui viendrait remplacer AppKit comme UIKit. SwiftUI représente probablement les prémices de cette troisième voie — qui vient cette fois de l’Apple Watch (lire : Catalyst aujourd’hui, Swift UI demain, Apple prépare le futur des interfaces).

Un seul noyau, un seul Core OS, les mêmes Core Services, les mêmes technologies multimédia, le même framework applicatif, le même langage de programmation, le même réseau de distribution… Seule l’interface changera, selon qu’elle s’affiche sur le petit écran de l’Apple Watch ou le grand écran de l’iMac, et pourquoi pas l’écran virtuel de futures lunettes. L’héritage technologique de NeXT aura été liquidé, mais pas son ambition.

---

1. Pour la petite histoire : avant de désigner l’API de développement orienté objet de Mac OS X, le nom « Cocoa » désignait un environnement de développement pour les enfants, conçus par l’Advanced Technology Group (lire : De petites équipes pour inventer le futur de l’informatique). Cocoa et le chocolat devaient être aux enfants ce que Java et le café sont aux adultes. Le projet avait été suspendu au retour de Steve Jobs, mais la blague collait toujours, et la marque était déjà déposée, et voilà comment « Cocoa » a survécu. ↩︎