De NeXTSTEP à SwiftUI, comment Apple a réarchitecturé ses systèmes

Anthony Nelzin-Santos |

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.

Un schéma simplifié de l’architecture de Rhapsody. L’histoire mouvementée de Rhapsody est passionnante. Brendan Shanks propose de revenir sur la WWDC 1997 sur son site avec les vidéos et les présentations des sessions, dont celle sur les bases de Rhapsody.

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.

Un schéma simplifié de l’architecture de Rhapsody pour Mac (à gauche), pour Linux (au milieu), et pour Windows NT (à droite). Ironie de l’histoire : si la Yellow Box pour Windows NT a bien été distribuée aux développeurs, et que la Yellow Box pour Linux survit avec le projet GNUstep, la Yellow Box pour Mac OS n’a jamais vu le jour sous cette forme.

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 Java1, 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 ».

Un schéma simplifié de l’architecture de Mac OS X. Les couches se multiplient, mais les choses se clarifient, parce que les choix technologiques s’affirment.

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.

Un schéma simplifié de l’architecture de Mac OS X avant la présentation de l’iPhone. Dix ans après l’acquisition de NeXT, Apple ne mentionne plus Aqua, et clarifie la présentation des différentes couches du système.

« 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).

Un schéma simplifié de l’architecture de macOS. Vous vous demandez pourquoi certaines technologies apparaissent dans plusieurs couches ? La réponse est simple : le système n’est pas strictement organisé en couches imperméables et interchangeables, et ce schéma n’est qu’une représentation permettant d’appréhender le fonctionnement de macOS, sans toutefois le décrire précisément.

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.

Un schéma simplifié de l’architecture de macOS (à gauche) et d’iOS (à droite). En 2007, Apple parlait encore de Cocoa pour Mac OS X, et parlait donc de Cocoa Touch pour iPhone. Si l’on trouve encore des mentions de Cocoa dans la documentation aux développeurs, Apple préfère désormais parler de couche applicative, dans laquelle elle distingue particulièrement AppKit et UIKit. Ce schéma est (nécessairement) réducteur : non seulement une même couche ne renferme pas exactement les mêmes technologies selon le système, mais un même framework peut avoir un comportement différent selon l’appareil. Même si macOS et iOS se sont beaucoup rapprochés ces dernières années, on ne peut pas (encore ?) parler d’un système unifié, dont seule la couche applicative changerait d’un appareil à l’autre.

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).

Un schéma simplifié de l’architecture de macOS Mojave et macOS Catalina.

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).

Le futur des systèmes d’Apple ?

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. ↩︎
avatar Pse | 

Merci pour cet article !

avatar umrk | 

Mission impossible que d'écrire un article sur un sujet pareil (mais chapeau l'artiste) .... On a affaire à un volume de code inimaginable ...

Pour ma part, je m'en tiens à quelques constations simples : un iPad s'utilise sur ses genoux, assis dans un fauteuil (posture adoptée par Steve, ce n'est pas un hasard ...), une machine de bureau s'utilise .. assis devant un bureau, et un smartphone n'importe où (mais le plus souvent debout) .....

Trois irréductibles situations ("use cases") différentes, trois solutions techniques différentes (même si bien sûr on peut toujours trouver quelques zones de recouvrement, à la marge) ....

Après, évidemment, il n'est nullement interdit de factoriser du code, c'est une bonne pratique de gestion de projet .... (mais une cuisine, qui, finalement, n'intéresse que les développeurs)

avatar reborn | 

@umrk

Pour ma part, je m'en tiens à quelques constations simples : un iPad s'utilise sur ses genoux, assis dans un fauteuil (posture adoptée par Steve, ce n'est pas un hasard ...)

L’iPad a évolué aujourd’hui, ce n’est plus seulement un appareil de consultation c’est aussi un puissant appareil de production

avatar lawappe | 

@umrk

Ça s’appelle Surface, avec Windows 10.

Microsoft, a mon avis, a toujours eu la meilleure vision sur ce sujet là. Alors qu’Apple s’est enfermé dans son discours, technique initialement, commercial ensuite, adapté à chaque plateforme.

On se rend bien compte aujourd’hui, que même si la partie visible de l’iceberg s’adapte à chaque type de device, la partie invisible s’unifie.

Ce que Microsoft propose depuis des années maintenant...

avatar Thms | 

@lawappe

Je vois les choses différemment ; Apple expérimente le futur de l’informatique sur iPad, iPhone, Apple Watch, pour aboutir à terme à une solution nouvelle et moderne, qui replacera les vieux OS de bureau des années 80 (comme on en trouve sur ta Surface).

Architecture ARM, sécurité, biométrie, Swift, App Store etc.

La vision d’Apple est la bonne de mon point de vue.

avatar lawappe | 

@Thms

Je n’ai pas de Surface ? Je suis sur Mac depuis très longtemps. Et pas vraiment envie d’en changer.

En revanche, tout ce dont tu parles n’est que matériel. Or je parlais des couches logicielles.

Apple innove dans le matériel, certes. Pas toujours de manière élégante d’ailleurs ces derniers années.

Mais je suis persuadé que Microsoft a eu la bonne inspiration : simplicité. Ce qui était l’adage du Mac auparavant. Avec leurs déclinaisons de noms d’OS, ils embrouillent tout le monde.

D’autant plus lorsque tu n’as qu’une case à cocher pour compiler une application pour un système « différent ».

Ils se sont enfermés dans leur discours « différent » pour se positionner face à Microsoft. Et sur ce coup là, ce n’était pas une bonne idée.

Je suis prêt à parier qu’un jour prochain, les utilisateurs vont scander « innovation », « génie » lorsque Apple sortira soit un OS unifié, soit une liste de cases à cocher dans Xcode. Alors que Microsoft propose ça depuis longtemps...

avatar reborn | 

@lawappe

C’est arrivé trop tôt et l’exécution de leur projet était mauvaise.

Et le message d’Apple n’est pas: "utilisez la même interface de partout"

Bref c’est du passé ils poussent les apps électron et autre PWA maintenant.

Sinon UXkit remonte à 2014 (Photo), et depuis 2015 l’on a vu des bribes du support des fenêtres sur iPad avec iOS 9

C’est n’est pas quelque chose qu’ils ont bricolé en 2 ans vite fait

avatar armandgz123 | 

@lawappe

Je suis du même avis

avatar xDave | 

@lawappe

Mouais enfin l’OS de Microsoft, on en parle ?
Les tablettes pseudo ordinateur inutilisables sans clavier ou souris.
Donc à part un OS pour ordinateur je vois pas

avatar lawappe | 

@xDave

C’est marrant, l’iPad supporte maintenant clavier ET souris ?

avatar xDave | 

@lawappe

Oui et ?
Il y a aussi dans ta phrase

avatar MacTHEgenius | 

@lawappe

Le support de la souris est un réglage d’accessibilité. On est loin de ce qu’un Mac peut faire.

avatar skynext | 

@xDave

J’ai quand même l’impression que Microsoft proposait quelque chose de plus abouti il y a quasiment 10 ans avec l’ancêtre de l’UWP (https://en.wikipedia.org/wiki/Windows_Runtime) que ce qu’Apple offre pour le moment en terme d’UX avec Catalyst

avatar xDave | 

@skynext

D’UX?
?

avatar skynext | 

@xDave

Bah oui les app UWP sont à mon sens largement supérieur aux Apps Marzipan (que l’on ne sait même pas redimensionner correctement). Et pourtant je ne suis pas un fan de Windows

avatar reborn | 

@skynext

Considérons Catalyst comme la version 2 de Marzipan présenté l’an dernier.

Catalyst prend en charge bien plus de caractéristiques natives du mac que ce qu’Apple a présenté l’an dernier.

UIkit sur mac, UIkit, et Appkit peuvent être utilisé au sein d’une même app sous macOS

avatar IGerard | 

@lawappe

Comme le faisait Steve Jobs ... Apple a le discours pour vendre ce qu’elle a à vendre... un discours unifiant c’est très simple d’en avoir l’idée, c’est la base de l’approche industrielle et logicielle: économie d’échelle en factorisant au Max les efforts.

L’approche qui a consisté par contre a insisté sur une ergonomie tablette a été une stratégie mûrie par l‘expérience... sans contrainte forte le Dev va au plus simple ... ça a fait naître tout un superbe écosystème d’applications vraiment adaptées à l’ergonomie de la tablette. Donc oui, expérience différente mais technologies de plus en plus communes.

La semaine dernière, meeting avec les gars de Microsoft azure qui avait tous des surface pro... qu’ils n’ont utilisé toute la semaine que comme un laptop ultra léger

avatar XiliX | 

@lawappe

"On se rend bien compte aujourd’hui, que même si la partie visible de l’iceberg s’adapte à chaque type de device, la partie invisible s’unifie.

Ce que Microsoft propose depuis des années maintenant..."

Non je ne pense pas, et très loin même
L’approche de Microsoft est de faire fonctionner « une même » application sur différentes plateformes. Desktop/Laptop et Tablette.

L’approche d’Apple ici est nettement plus intelligente. Même code pour n’importe quel device. Ça ne veut pas dire que la même application aura le même comportement selon la plateforme.
Impossible de garder le même comportement d’un « combobox » par exemple sur un ordinateur que sur un mobile. Même une tablette.

Donc NON, ce n’est pas du tout la même approche. Et personnellement l’approche d’Apple est plus intelligente. Car un mobile n’a pas la même utilisation qu’un ordinateur.

avatar lawappe | 

@XiliX

Microsoft n’a pas de « mobile » à supporter.

avatar XiliX | 

@lawappe

"Microsoft n’a pas de « mobile » à supporter."

Et Tablette Surface ?
Elle est ce qu’on appelle mobile device. Pour difference avec desktop/laptop.
Il ne faut pas prendre pour un « mobile » phone

avatar XiliX | 

@XiliX

"Pour difference"

Pour différencier*

avatar Ramlec | 

@lawappe

N’a plus*

avatar iPop | 

@lawappe

Après le départ de Jobs, APPLE entreprit de copier, mimer IBM. Pas sûr que c’était une bonne chose. L’histoire se répète.

avatar MacTHEgenius | 

@lawappe

Les couches sous-jacentes à AppKit et UIKit ont toujours été les mêmes. Cependant, selon la plateforme, certains frameworks étaient disponibles dans leur intégralité, partiellement ou pas du tout.

Un exemple donné lors d’une session WWDC2019 est RealityKit qui gère tout ce qui ce nomme la réalité augmentée. Ce framework n’est que disponible sur iOS, parce qu’il ne fait pas de sens sur macOS.

avatar tempest | 

Super article qui me rappelle comme le temps passe.
Un jour un petit article sur OpenDoc avec IBM serait cool.

Pages

CONNEXION UTILISATEUR