Un récent article de Bloomberg a lâché une « bombe » : Apple travaillerait sur une approche universelle des applications, qui fonctionneraient alors aussi bien sur iOS que sur macOS. L’objectif ultime, en somme, de l’actuel projet Marzipan, annoncé lors de la WWDC 2018.

Bien que présenté presque en marge de la conférence, UIKit pour Mac laissait déjà présager de ce que sera l’avenir de l’écosystème applicatif sur les appareils Apple.

Mais d'abord, qu’est-ce qu’UIKit ? Une infrastructure de construction d’interfaces pour les applications iOS et tvOS. Les éléments graphiques, interactions avec l’utilisateur, évènements tactiles et autres lui sont dévolus. Ce framework existe depuis des années, et les développeurs le connaissent donc bien.

Il s'agit du pendant mobile, dans les grandes lignes, d’AppKit sur macOS. Aussi, quand Apple a annoncé l’arrivée d’UIKit sur macOS, il y avait de quoi se poser des questions. Pour ne pas trop rester d’ailleurs dans la théorie, la firme s’est empressée de montrer quatre exemples concrets, les fameuses applications iPad introduites dans Mojave : Bourse, Dictaphone, Maison et News, même si cette dernière n’est pas encore disponible en France.

Impossible de se tromper, tant leur interface ressemble à celle pour iPad, dans une formule adaptée. Cette présentation était le premier cas pratique d’UIKit pour Mac. Apple a vite ajouté que le projet allait s’étaler dans le temps, sans plus de précisions. C’est dans ce contexte que Bloomberg évoque des applications communes pour iPhone, iPad et Mac dès 2021.

L’aboutissement de Marzipan

Ce serait donc l’objectif ultime, celui finalement d’une boutique commune pour proposer des applications capables de fonctionner sur les principaux produits Apple.

Marzipan – qui n'est qu'un nom de code – serait un projet en plusieurs étapes, chacun rapprochant les développeurs de cette opportunité. Selon Bloomberg, ils obtiendraient ainsi un binaire unique contenant toutes les ressources nécessaires à la bonne marche de leur création sur iOS et macOS. L’extension, en fait, des applications universelles qui avaient déjà permis la publication d’un seul binaire pour iPhone et iPad.

Toujours selon nos confrères, la prochaine étape serait de permettre le portage des applications iPad vers macOS. Ce qui semble logique, ces applications possédant déjà un mode d’affichage en paysage correspondant plus facilement à un écran d’ordinateur. On ne parlerait pas encore de binaire unique, mais d’un kit de conversion. Il autoriserait la reprise du code, mais nécessiterait encore une publication séparée sur chaque boutique.

L’année prochaine, Apple envisagerait de faire de même avec les applications pour iPhone, exactement comme les Chromebook peuvent exécuter des applications Android s’ils sont compatibles. Les questions d’ergonomie – nous y reviendrons – s’intensifient puisque les interfaces du smartphone sont avant tout pensées pour le mode portrait.

2021 serait finalement l’année de la boutique unifiée. Le gros de l’impact serait évidemment sur les Mac, puisque le Store y permettrait alors de télécharger des applications initialement conçues pour iOS. Les sources de Bloomberg évoquent des « plans fluides mais qui pourraient changer », et au vu des défis qui attendent Apple, on comprend pourquoi.

Boutique unique : un concept agréable, une réalisation complexe

Difficile d’aborder une telle fusion sans penser aux actions déjà menées par la concurrence. L’exemple le plus récent est l'arrivée des applications Android sur les Chromebook. Dans la plupart des cas, le lancement se fait « tel quel », sans adaptation autre que celles fournies par Chrome OS pour rendre l’application utilisable au clavier et à la souris.

Mais l’exemple le plus parlant est celui de Microsoft. Le Store de Windows 10 contient en effet des applications capables de fonctionner sur tous les appareils ayant le même socle technique. Bien que les Windows Phone soient pratiquement éteints, ils pouvaient également récupérer les mêmes applications. C’était tout du moins l’idée.

Le cas de Microsoft illustre parfaitement les difficultés majeures de réaliser une telle unification. Les développeurs n’avaient pas obligation, bien sûr, de proposer une mouture pour chaque type d’appareil. S'ils souhaitaient proposer une application UWP (Universal Windows Platform, un nom particulièrement évocateur des ambitions de la firme) pour les seuls ordinateurs, il suffisait de l’indiquer dans Visual Studio avant envoi pour validation.

S’ils voulaient au contraire publier pour tous les appareils, la manipulation était faisable sans presque toucher à rien. Mais cette apparente facilité cachait un vrai problème : l’absence de travail sur l’ergonomie devenait criante. Résultat, l’utilisation de l’application était désagréable, montrant vite les limites d’une approche automatisée.

Bien sûr, Google comme Microsoft avertissent : une ergonomie se doit d’être adaptée à l’environnement visé. Microsoft notamment fournissait des guides, mais les développeurs se retrouvaient limités d’une autre manière : les barrières imposées par UWP elle-même. Un défi colossal, avec des API bien loin de couvrir tout ce que permettait Win32 et la nécessité d’une approche ergonomique globale pour répondre aux besoins des développeurs.

Le Windows Store s'est finalement rempli de nombreuses applications bâclées. Aujourd’hui, deux courants récents peuvent redonner de l'espoir à Redmond. D’un côté, le support des PWA, dont les éditeurs profitent davantage. Twitter a d’ailleurs été le premier gros acteur à s’y mettre. Ensuite, un environnement .NET Core qui pourrait bien représenter l’avenir du développement d’applications chez Microsoft.

Si nous abordons autant le cas du père de Windows, c’est qu’il illustre très bien les problèmes auxquels Apple sera probablement confrontée. L’entreprise a tout intérêt à prévoir soigneusement les étapes de son projet pour ne pas finir comme Microsoft, les technologies nécessaires arrivant trop tard.

Ergonomie : le vrai danger

Apple a fait un excellent travail avec Bourse, Dictaphone et Maison. En l’état, les applications ressemblent bien à leurs grandes sœurs sur iPad, mais leur interface a été suffisamment travaillée pour qu’elles n’aient pas l’air d’avoir été simplement placées là sans plus de réflexion. Un exemple à suivre, donc.

Durant la présentation, les remarques d’Apple rappelaient largement celles déjà faites par Google et Microsoft : les développeurs devront faire attention. Lorsque le kit de développement sera disponible, ils devront ainsi veiller à travailler chaque ergonomie pour qu’elle corresponde au mieux à l’appareil visé.

Une application iOS est par définition tactile. On imagine sans peine une traduction automatique de ces contrôles vers des équivalents clavier/souris, autant qu’une impossibilité dans certains cas. Surtout, il faudra que la version macOS ait l’air d’avoir été taillée pour elle. Les développeurs n’auront peut-être pas à réécrire la base du code, mais le travail de conversion sur l’ergonomie pourra être important. Peut-être davantage qu’en partant d’une feuille vierge.

En clair, Apple doit éviter coûte que coûte un phénomène semblable à Electron qui, s’il simplifie la vie de certains éditeurs, est aussi une solution de facilité se traduisant parfois par des performances moindres et des interfaces pas toujours adaptées. Dans le cas d’Apple, il se traduirait par des applications iOS bêtement encapsulées et vaguement travaillées pour l’ergonomie d’un ordinateur.

C’est peu dire que l’historique de la firme cadre mal avec une telle évolution. La plateforme macOS, en perte très nette de vitesse vis-à-vis d’iOS, en serait fragilisée et deviendrait alors citoyenne de seconde zone d’un monde applicatif focalisé sur le mobile. La perspective de la boutique unique est pourtant loin d’être dénuée d'intérêt.

Du potentiel oui, mais pas pour tout le monde

Les développeurs ayant déjà une application macOS n’auront probablement que peu d'avantages à utiliser UIKit, même s’ils le font déjà pour iOS. Le langage de développement est le même – Swift – et les briques logicielles souvent identiques, comme l’ensemble des Core Services et Metal. Seule grande différence : les applications macOS reposent sur AppKit.

Mais qu’en est-il des très nombreux développeurs à n’avoir créé que des applications et jeux pour iPhone et iPad ? Après tout, les ventes d’appareils mobiles enterrent largement celles des Mac. Dans ce cas, la situation change, les ordinateurs devenant un nouveau marché potentiel sans avoir à réapprendre la moindre technologie.

Reste bien entendu le problème de l’ergonomie.

Apple cherche probablement un cercle vertueux – en fait le même qui a permis l’essor de l’iPhone. Si les développeurs peuvent « arroser » d’une traite tous les produits iOS et macOS, ils pourraient être tentés par une nouvelle aventure. Plus de développeurs signifie plus d’applications, donc un Store mieux rempli, donc davantage de raisons d’acheter un Mac. L’équation basique du succès d’un produit depuis que les boutiques d’applications existent.

Idéalement, UIKit aurait les mêmes capacités qu’AppKit, pour qu’Apple ne se retrouve pas dans la même situation que Microsoft avec un socle UWP loin des possibilités de Win32, surtout à sa sortie. Et il faut rappeler qu’UIKit est déjà utilisé par tvOS depuis un moment. Les mêmes éléments sont interprétés différemment selon leur environnement d’exécution.

D’un autre côté, Apple a peut-être lancé ce projet pour couper l’herbe sous le pied d’Electron et autres solutions du même acabit. Elles ont néanmoins l'intérêt d'être multiplateforme.

Le choix technologique

C’est un fait : Apple n’apprécie guère les technologies du web. C’est le seul des géants américains actuellement à avoir une approche extrêmement sélective sur le sujet : la firme est régulièrement fière des progrès réalisés sur Safari, mais tout ce qui touche au web doit s’y cantonner.

Cas le plus flagrant : les Progressive Web Apps. Propulsées par Google, de plus en plus utilisées, elles sont même depuis l’année dernière acceptées en l’état dans le Store de Windows 10. Elles y ont la même place que les applications UWP ou Win32 (une fois passées à la moulinette du Desktop Bridge). Comme déjà mentionné, Twitter s’est précipité sur cette opportunité, supprimant dans la foulée son ancienne application, peu entretenue.

Et tout le problème est là : le développement dans son ensemble vise une approche multiplateforme avec réutilisation du code. Apple ne laisse pas passer les technologies web : hors de question pour la firme qu’elles aient les mêmes capacités que le code natif, largement privilégié par la pomme. iOS 12 a par exemple beau avoir progressé notablement sur nombre de points, une application web épinglée sur l’écran d’accueil ne sera rien d’autre qu’une icône : pas de stockage indépendant, pas de notifications, rien.

Dès lors, face à un mouvement de fond irrésistible, comment procéder ? UIKit pour macOS serait la réponse, en partant du principe que les développeurs connaissent déjà iOS et UIKit, de la même manière que les développeurs web peuvent créer des applications pour smartphones et ordinateurs.

Le message serait alors simple : « Créez facilement la version macOS de votre application mobile ». Ce qui éviterait la solution web ou – pire – pas d’application du tout. Apple capitaliserait ainsi sur les connaissances acquises, sans répondre toutefois à toutes les problématiques. Après tout, si un développeur veut toucher d’un coup un maximum de plateformes concurrentes, UIKit ne lui sera d’aucun secours. Contrairement aux technologies web ou des produits comme Xamarin.

Des années de funambulisme à prévoir

Apple va devoir travailler très soigneusement sa communication et ses priorités. Les années à venir vont être capitales, alors même que le discours de la firme est ambivalent sur un point crucial : elle répète inlassablement – encore à la WWDC 2018 – qu’il n’est pas question de fusionner iOS et macOS.

L’argument est toujours le même, à savoir que chaque produit à son approche propre. Tim Cook disait encore tout le mal qu'il pensait d'un tel rapprochement en avril 2018, évoquant des compromis qui ne satisferaient personne.

Des systèmes parfaitement séparés donc, mais avec des briques logicielles communes, exploitables par un langage unique. Tous les signes pointent dans cette direction et les informations obtenues par Bloomberg semblent s’aligner comme autant de planètes.

Cette insistance à séparer Mac et iPhone/iPad pourrait encore perdre en profondeur dès l’année prochaine. Les rumeurs vont bon train en effet sur de premiers Mac équipés de puces ARM dès l’année prochaine. Axios indique par exemple que le sujet serait vif chez Intel, le fondeur pouvant perdre l’un de ses plus gros clients. Ce, alors que Microsoft et certains partenaires proposent déjà des machines exploitant Windows 10 on ARM. 

Apple est après tout coutumière des transitions technologies radicales : le passage à Intel s’était fait en 2006 au détriment de l’architecture PowerPC, qui n’évoluait pas assez vite au goût de Steve Jobs.

Les rumeurs semblent concorder vers une évolution importante dans les deux ans à venir, tant pour les applications que le matériel. Si toutes se confirment, la communication la plus à surveiller sera celle destinée aux développeurs.

L’une des clés du succès de l’écosystème Apple aujourd’hui réside dans la manière qu’a eue la firme de les accompagner à travers des transitions lourdes. Les binaires universels en sont un exemple, mais on peut aller plus loin avec Rosetta, qui permettait le fonctionnement des logiciels conçus pour PowerPC sur des Mac Intel – au prix d’une importante dégradation des performances.

Si la feuille de route de Bloomberg est correcte, Apple devrait donc en confirmer la deuxième étape dans moins de trois mois. L’édition 2019 de la WWDC verrait donc les présentations d’iOS 13, macOS 10.15 et du kit permettant la transition des applications iPad vers les Mac. Selon nos confrères, Apple pourrait même en profiter pour donner un aperçu du nouveau Mac Pro, que les rumeurs décrivent comme un grand retour à la modularité.