« Avec Catalyst, il vous suffit de trois étapes pour que vos applications iPad tournent sous macOS ». C’est cette phrase, ou une formule approchante, qu’on a eu l’occasion d’entendre et ré-entendre tout au long de la WWDC. Evidemment, quand la promesse est belle, le doute est forcément de la partie.
Pour rappel, le projet Catalyst, que des fuites et indiscrétions avaient nommé Marzipan, vise à permettre à moindre effort de porter une application iPad vers macOS (et non l’inverse) ou de ne développer une appli qu’une fois pour les deux plates-formes que sont macOS et iPadOS. Historiquement, les programmes de la première reposent sur un socle appelé AppKit, tandis que les secondes utilisent le framework UIKit.
Trois étapes vers le bonheur ?
Quoi qu’il en soit, revenons aux trois étapes tant vantées par Apple lors de différentes sessions de sa WWDC. Avec un sourire de chat qui vient de trouver une souris endormie, l’ingénieur d’Apple nous la détaillait ainsi : « la première étape consiste à… cocher une case dans Xcode. » Devant l’air interloqué de l’assistance, il a joint le geste à la parole et a prouvé ce qu’il venait de dire.
La deuxième est à la fois évidente… et bien plus compliquée à mettre en oeuvre. Il faut avoir « une bonne application iPad ». Notez bien, iPad… et non iOS ou iPhone. Voilà en soi une bonne justification de l’introduction de l’appellation iPadOS. Si iPhone et iPad ont tous les deux des écrans tactiles, ce serait une erreur de les mettre dans le même panier. iPadOS est le nouveau chaînon manquant entre iOS et macOS.
Mais revenons à nos moutons. Schématiquement, une « bonne application iPad » respecte les recommandations techniques d’Apple et affiche le code le plus propre possible. Cela implique également que le développeur a fait en sorte que son programme soit capable de s’adapter à différentes tailles d’écran – 7,9, 9,7, 10,5, 11 et 12,9 pouces. Bref, en admettant que le développeur ait tout fait au mieux au fil des mois et des mises à jour, l’étape deux est une victoire acquise.
Vient la troisième étape, et c’est évidemment là que les choses se compliquent potentiellement. Ce dernier pas concerne les « finitions ». Autrement dit, faire en sorte que tout ce qui ressemble trop à une application iPad soit parfaitement adapté aux Mac.
Cela concerne aussi bien certains détails d’interface que des réglages plus en profondeur.
Les démonstrations qui nous ont été faites reposaient toujours sur des applications simples du point de vue ergonomique. Il « suffisait » ainsi de faire en sorte qu’une barre latérale soit partiellement transparente ou, plus complexe, de transformer un menu d’interface mobile en barre de menus comme on en trouve sur Mac depuis toujours. Avec la nécessité, en l’espèce, de remapper des commandes, de lier des actions à un sous-menu, d’ajouter des raccourcis clavier, etc.
Enthousiasme, inquiétude et prudence
Nous avons eu l’occasion de discuter avec une dizaine de développeurs croisés au hasard de la WWDC. Tous ou presque sont enthousiastes à l’idée de ce projet. Néanmoins, après quelques sessions ou de premières tentatives, certains nous ont rapporté des problèmes, notamment au niveau de la gestion des processeurs graphiques pour les applications les plus exigeantes. D’autres ont évoqué l’impossibilité d’importer certaines librairies nécessaires au fonctionnement de l’application et donc la perte de nombreuses fonctionnalités.
Quelques développeurs, parmi les plus sceptiques, s’inquiétaient même qu’en définitive les applications « universelles » d’Apple se résument à un gros « if ». Si l’application s’exécute sur l’iPad, alors on oublie telle partie du code, si c’est sur un Mac, c’est l’inverse.
Des craintes et interrogations somme toute logiques alors que le projet vient d’être officiellement ouvert aux développeurs tiers, Apple ayant donné un léger aperçu de son projet en dévoilant des applications iOS portées sur macOS lors de la WWDC 2018. Il faudra donc attendre de voir quelles difficultés vont rencontrer les codeurs, les solutions que pourra apporter Apple pour prendre la mesure du chantier tout juste initié.
Pas pour toutes les applications
Mais il est également nécessaire de prendre conscience que toutes les applications iPad -même les bonnes au sens d’Apple- ne sont pas appelées à être portées vers macOS. Soit parce que leur conception est trop intimement liée à iOS/iPad OS, soit parce que leur développeur n’en voit pas l’intérêt. Nous avons rencontré un représentant d’un éditeur de jeux français qui ne semblait pas particulièrement intéressé à l’idée de porter ses titres iOS vers macOS. Sans doute parce que la plupart d’entre eux ont été pensés pour les iPhone.
Certains développeurs qui travaillent à la création et au maintien d’applications de transport se montraient plus intéressés mais doutaient toutefois de la pertinence de porter leurs applications très « mobiles » vers macOS.
D’autres développeurs ont en revanche montré davantage d’enthousiasme. L’envoyé d’une banque française s’enthousiasmait ainsi de la possibilité de porter facilement son application iPad vers macOS. « C’est une solution parfaite pour éviter certains problèmes de sécurité, pour offrir une expérience cadrée et rapide, bien plus que sur le Web », nous a-t-il expliqué.
En définitive, au-delà de la question de la facilité et de la faisabilité technique va se poser celle de la pertinence de porter tout un ensemble d’applications. Une question qui prouve bien que les deux types d’appareils ne sont pas égaux – au moins dans la perception du public et des développeurs. C’est sans doute aussi cela qu’Apple va devoir corriger s’il entend faire de Catalyst un succès.
D’autres chantiers, un but ambitieux ?
Il faudra attendre l’automne et l’arrivée de macOS Catalina pour se faire une première idée. L’arrivée des applications iPad sur nos Mac produira-t-elle une vaguelette ou un raz de marée ? Apple pèse de tout son poids pour que tout se passe bien, même s’il est évident que cet outil est là pour servir une phase de transition.
L’introduction de SwiftUI, un framework qui permet de développer une application de manière très intuitive et simple en générant automatiquement de grosses parties du code, est aussi un effort qui va dans ce sens. Car SwiftUI offre également des choix d’interface et de mise en forme des informations qui deviendront ainsi de facto des normes. Or, adapter une norme homogène à deux plates-formes est bien plus facile.
L’enjeu derrière Catalyst est colossal. Au-delà de l’enrichissement de l’offre logicielle sur Mac, il est difficile de ne pas envisager l’arrivée à plus ou moins long terme de Mac sous ARM. Apple prépare le terrain en douceur, à son rythme, étape par étape, une fois encore.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
