L’annonce a beaucoup fait parler : le framework UIKit, qui permet de construire des applications iOS et tvOS, sera bientôt disponible sur macOS. Enfin… elle a surtout fait parler les journalistes et les commentateurs. Les développeurs sont restés étonnamment discrets, eux qui sont pourtant les premiers concernés, sans doute parce qu’ils sont dans l’expectative.
En effet, Apple se réserve la primeur d’UIKit sur Mac, et se donne jusqu’à 2019 pour l’améliorer avant de le confier aux développeurs. En attendant, ces développeurs ont bien un avis sur la question. Pour savoir lequel, nous avons interrogé une demi-douzaine de développeurs français et européens.
« Prudence », voilà le maître-mot des développeurs que nous avons interrogés. Avant de s’engager, ils attendent bien sûr d’en savoir plus. Une prudence qui ne les empêche pas d’avoir un avis, parfois tranché, sur les choix d’Apple. Raphael Sebbe, le fondateur de Creaceed, dit ainsi qu’il aurait « préféré un rapprochement d’AppKit et UIKit » :
Comme Apple l’a fait avec tvOS, qui utilise UIKit avec des extensions qui sont propres à [l’Apple TV]. Ici avec le déploiement d’apps iOS directement sur Mac, ça fait quand même un peu bâclé en termes d’expérience utilisateur, même si cela peut avoir du sens dans certains cas pour des apps « monolithiques » et que cela peut ramener de la vie sur le Mac, qui en a bien besoin.
Florent Morin, développeur freelance spécialiste d’iOS, est plus optimiste et « trouve que l’idée de porter UIKit sur Mac est cohérente » :
Aujourd’hui, quand on écrit des frameworks iOS, ils sont pour ainsi dire déjà prêts pour macOS, watchOS et tvOS. Cela est notamment dû au fait que les quatre OS partagent leurs bibliothèques bas niveau ainsi qu’un langage de programmation commun. On peut également ajouter le web, qui est également une plateforme qui peut partager une partie du code avec les quatre plateformes Apple grâce à Swift. […]
watchOS partage certains composants UIKit avec iOS : UIImage par exemple. Pour autant, certains composants iOS sont absents de watchOS (UIViewController) mais ont leur équivalent adapté à l’appareil (WKInterfaceController). De la même manière, tvOS partage beaucoup de composants avec iOS (UIViewController, UITabBarController) mais dispose depuis iOS 12 de ses propres composants au travers de TVUIKit (TVDigitEntryViewController).
D’ailleurs, certains composants UIKit sont disponibles exclusivement sur iPad. Et cela ne choque personne. macOS est la seule plateforme a avoir uniquement la couche bas niveau en commun avec iOS. Cela me semble cohérent que macOS dispose de ses propres composants, associés à une expérience orientée Mac.
Aucun des développeurs que nous avons interrogés ne remet en cause la pertinence du choix d’Apple, mais beaucoup s’inquiètent des conséquences pour le devenir de la « plateforme Mac ». Raphael Sebbe, qui a commencé sa carrière avec des applications Mac mais propose aujourd’hui une gamme d’applications sur iOS, craint ainsi que UIKit « risque aussi d’être utilisé à outrance [pour porter] toutes les apps iOS, et pourrait produire l’effet inverse ».
Paulo Andrade, le développeur portugais du gestionnaire de mots de passe Secrets, disponible sur les deux plateformes, attaque le problème par l’autre bout :
Même avec Marzipan [le nom du code du projet dont UIKit sur Mac dérive], les applications iOS resteront des citoyens de seconde zone. Avec Marzipan, les développeurs resteront déconnectés d’AppKit, comme les applications Electron le sont aujourd’hui. Apple essaiera de le cacher, bien sûr, de créer des ponts vers le plus grand nombre possible d’API.
« Electron », le mot est lâché, et revient régulièrement, comme un repoussoir. « En tant qu’utilisateur », dit Florent Morin, « si cela peut m’éviter de subir les apps web embarquées dans des conteneurs macOS, je ne m’en plaindrai pas non plus ! » Raphael Sebbe craint pourtant que l’approche choisie par Apple ne « fragilise davantage le Mac, en décourageant les développeurs de faire des apps classiques, s’orientant plus vers iOS ou Electron ».
La firme de Cupertino enverrait des signaux contraires : « si Apple elle-même développe ses nouvelles apps Mac en UIKit, pourquoi cela aurait-il du sens pour les développeurs de continuer en AppKit ? » Max Seeleman, fondateur et directeur du développement d’Ulysses, pense qu’il s’agit d’un faux problème. De son point de vue, UIKit est désormais une technologie « native » au Mac, sur le même plan qu’AppKit :
Je suis persuadé que nous n’avons encore rien vu. Cette technologie a un potentiel énorme — pour nous, mais aussi pour la plateforme. Pour la plateforme, […] je vois un intérêt à développer des applications véritablement natives, plutôt que d’utiliser Electron ou des techniques similaires. Pour nous, j’espère que [UIKit] nous permettra d’augmenter la part de code partagé dans notre application, que cela nous rendra plus efficaces et nous permettra de proposer de nouvelles fonctions plus rapidement.
Raphael Sebbe le reconnaît lui-même : « il est aussi possible que les apps UIKit deviennent un genre de standard chez Apple, des “rectangles interactifs” qui seraient une alternative plus puissante aux pages web car natifs ». Mais Paulo Andrade ne croit pas que les adeptes d’Electron seront convaincus :
Electron est populaire auprès des développeurs qui veulent cibler le Mac. […] Apple pense peut-être pouvoir combattre cette tendance, et convaincre certains développeurs de porter leur application iOS vers macOS [avec UIKit] plutôt qu’Electron. Mais franchement, je ne suis pas certain que cela va marcher. Je crois que lorsque les développeurs choisissent Electron plutôt qu’AppKit, c’est parce qu’ils peuvent réutiliser leur code sur Windows et Linux, pas parce qu’ils détestent le développement natif. Marzipan n’y changera rien.
Florent Morin préfère replacer le choix d’Apple dans une longue succession d’évolutions techniques. Apple assure ne pas vouloir fusionner macOS et iOS, mais travaille depuis plusieurs années à rapprocher progressivement les deux plateformes, jusqu’aux frameworks applicatifs, pour aboutir à un véritable coreOS commun. « Pour aller jusqu’au bout », dit Morin, « il faudrait qu’Apple sorte de UIKit certains composants propres à iOS » :
Le procédé a vraiment bien fonctionné avec tvOS : les composants UIKit remplissent le même rôle que sur iOS, mais leur interface est adaptée à l’interface de la TV, manipulée à la télécommande. Si la même méthode est employée, et il n’y a aucune raison pour qu’elle ne le soit pas, c’est un vrai tremplin pour l’adoption de macOS par les développeurs : la courbe d’apprentissage est drastiquement réduite.
Apple nous incite depuis quelques années à sortir le code et les éléments communs aux différentes plateformes au sein de frameworks. Cela fait partie d’un tout. In fine, Apple reste totalement en phase avec sa politique vis-à-vis des développeurs : en suivant bien les recommandations, sans essayer de mettre en place des procédés exotiques, le cap se passe aisément.
Au final, cette évolution est tout à fait cohérente : le code qui est commun aux différentes plateformes est mis en commun, y compris côté interface quand c’est possible, le code propre à chaque plateforme, en général liée aux interfaces, est adapté au cas par cas.
Paulo Andrade parle même d’un framework unifié :
Cela ne veut pas dire que les applications auront la même apparence sur les deux plateformes, bien sûr, mais cela signifie que les développeurs pourront partager de plus en plus de code d’interface entre macOS et iOS. Le fait que les deux plateformes n’aient pas le même mode d’interaction n’est pas un obstacle : le mode d’interaction de l’iPhone est radicalement différent de l’Apple TV, et ils utilisent pourtant tous deux UIKit.
Apple l’a dit et redit : différents usages appellent différents matériels utilisant différentes interfaces. Avec UIKit et demain un processeur ARM, un Mac ne sera rien d’autre qu’un iPhone sous une autre forme. L’interface des applications s’adaptera aux conditions d’usage, du petit écran de l’Apple Watch au poignet au grand écran de l’iMac Pro sur le bureau, en passant par l’iPhone dans la poche.
Un défi pour les développeurs, qui vont devoir changer leur manière de concevoir leurs applications, et sans doute leur manière de les promouvoir. « Il est encore trop tôt pour en parler », dit Mick Payne, le directeur du marketing de Cultured Code, l’entreprise allemande développant le gestionnaire de tâches Things :
Nous avons déjà une application Mac entièrement native, donc nous n’avons aucun intérêt particulier à utiliser [UIKit]. Il semble s’adresser à des entreprises qui ne possèdent pas encore d’application Mac, qui pourront être convaincues […] de porter leur application un peu plus facilement qu’auparavant.
Paulo Andrade ne compte pas plus abandonner son application Mac : « Secrets continuera de faire évoluer sa version Mac, et restera un citoyen de première zone sur le Mac ». Mais Jérémie Francone, le cofondateur de 1Button, voit l’occasion de simplifier le développement des versions macOS de ses nombreux jeux :
On peut certes voir [UIKit] comme un moyen au rabais de porter des apps iOS sur Mac. Pour nos jeux on utilise OpenGL/ES (et bientôt Metal…), le portage du jeu lui-même serait donc assez aisé. Mais pour les menus on utilise UIKit, ça pourrait donc grandement faciliter le portage de certains de nos jeux.
Et « bien sûr », l’équipe de développement iOS/tvOS de Canal+ réfléchira à porter son application iOS vers macOS, myCanal étant déjà proposé sur Windows par le biais du Microsoft Store. Les choses doivent encore se décanter, et les avis s’affineront à mesure que l’on y verra plus clair.
Une chose est sûre : l’arrivée d’UIKit sur Mac ne résout pas tous les problèmes de la plateforme. Raphael Sebbe le résume mieux que personne : « il existe d’autres leviers, à mon sens, si Apple veut rendre le Mac App Store plus intéressant pour les utilisateurs et les développeurs, comme la modernisation des modèles économiques : de vraies périodes d’essai, des mises à jour payantes, un abonnement unique à la SetApp… ».
Avec Mickaël Bazoge, Florian Innocente, Christophe Laporte, et Stéphane Moussie. Certaines citations ont été éditées pour des raisons de brièveté et de clarté.
Source : Image de Une Aurélien Guichard (CC BY SA 2.0).
