UXKit, la surprise cachée de Photos

Nicolas Furno |

La nouvelle bêta d’OS X Yosemite sortie hier soir est pleine de surprises. Cette nouvelle version ne contient pas beaucoup de nouveautés au niveau du système, mais elle embarque la toute première version de Photos, le nouveau gestionnaire d’images d’Apple. On a déjà eu l’occasion d’évoquer les nouveautés de ce logiciel pour l’utilisateur, mais ce n’est que la partie émergée de l’iceberg. Sous la surface, la nouveauté la plus importante est UXKit, un nouveau framework qui permet à Apple de réutiliser des éléments d’interface d’iOS dans ce logiciel OS X.

Pour le moment, UXKit n’est pas disponible pour les développeurs tiers et seul Apple l’utilise, uniquement dans Photos. Mais il semble évident que c’est une situation intermédiaire et que le constructeur ouvrira ce nouveau composant pour tout le monde. Il faudra probablement attendre OS X 10.11 qui sera a priori annoncé lors du WWDC de juin et qui devrait sortir à l’automne. En attendant d’en savoir plus, les développeurs qui ont installé la bêta peuvent jouer avec UXKit et créer des applications qui exploitent le nouveau framework, par exemple en utilisant ce projet Xcode prêt à l’emploi.

Une liste créée avec UXKit (image @Dmillian)

Avant de parler des nouveautés, il est important de rappeler que les développeurs conçoivent jusque-là leurs interfaces avec deux frameworks assez différents. Côté iOS, ils ont à leur disposition UIKit alors que sur le Mac, AppKit est à la manœuvre. Deux composants différents, avec des logiques différentes, ce qui complique la transition de l’un à l’autre : il faut le plus souvent repartir de zéro et on ne peut pas exploiter le code existant, du moins pas sans des modifications parfois importantes. Avec UXKit, Apple travaille sur un nouveau framework qui rapproche les deux plateformes.

Thomas Ricouard, principal développeur iOS de Glose, service de lecture avec une dimension sociale qui est présent sur l’App Store, a essayé UXKit et il ne cache pas son enthousiasme. Même si ce framework est encore loin d’être finalisé — il n’est même pas censé être utilisé par les développeurs, de toute manière — et même s’il manque encore plusieurs éléments pour qu’il puisse servir à des interfaces complètes, il est très prometteur selon lui.

L’ambition de UXKit est manifestement de simplifier au maximum la transition d’iOS à OS X. En théorie, explique Thomas, il suffit de remplacer tous les « UI » par des « UX » et on aura une application Mac fonctionnelle. C’est encore théorique, puisque le framework n’est pas finalisé et qu’il lui manque bon nombre d’éléments utilisés sur iOS, mais dans l’esprit, c’est aussi simple que cela. La raison est simple : les composants ont souvent les mêmes noms, excepté le préfixe qui change en fonction de la plateforme.

Si vous voulez créer une liste sur iOS, vous utilisez une classe nommée UITableView ; avec UXKit, vous pourrez utiliser la classe UXTableView. Le code est le même des deux côtés et le résultat est très similaire, comme le montre cet exemple que nous a envoyé Thomas Ricouard. On retrouve les mêmes animations et on retrouve les mêmes interactions au trackpad, par exemple ici pour passer d’un écran à l’autre.

À condition qu’Apple ait bien l’intention de proposer UXKit à tous les développeurs avec son prochain système d’exploitation (ou avant, mais cela semble moins probable), on devrait ainsi voir de plus en plus d’applications passer des appareils mobiles au Mac, ou réciproquement. L’investissement nécessaire étant moindre, les développeurs feront probablement plus facilement la transition. Pour prendre un exemple, un logiciel comme Reeder adopte déjà de nombreux éléments d’iOS, mais c’est parce que son développeur a tout refait lui-même. On peut penser qu’avec ce nouveau framework, il aurait pu faire la même chose avec beaucoup moins de travail.

Au-delà des applications multi-plateformes, passer d’AppKit à UXKit pourrait avoir des avantages pour les développeurs. Le framework actuellement utilisé est ancien (à l’échelle de l’informatique, naturellement) et il n’a pas bénéficié du travail de simplification mené pour iOS. En optant pour des composants proches de ceux du système mobile d’Apple, le développement de logiciels OS X pourrait ainsi être simplifié. Un exemple noté par plusieurs développeurs, on peut définir très simplement une couleur principale qui sera appliquée en divers points de l’interface, par exemple pour des titres. Avec AppKit, il y a beaucoup plus de travail pour obtenir le même résultat.

AppKit va-t-il pour autant disparaître ? Difficile de répondre à cette question, sachant que UXKit n’est à ce jour qu’un framework privé que seul Apple peut utiliser et que l’on ne sait même pas s’il sera un jour rendu public. Reste qu’il a nécessité beaucoup de travail et qu’on voit mal l’entreprise n’avoir entrepris tout ce travail que pour Photos. Peut-être qu’une partie des logiciels de base du successeur de Yosemite seront créés avec UXKit et peut-être que ce sera tout, mais on peut aussi se dire que ce travail d’adaptation a aussi été conçu en pensant aux développeurs tiers.

Du code exploitant UXKit

Tous les développeurs ne sont pas aussi enthousiastes sur UXKit toutefois. Brent Simmons, développeur qui travaille actuellement sur le gestionnaire de notes Vesper et sur OmniFocus, a ainsi publié un article sur son blog où il fait preuve de son scepticisme. Selon lui, AppKit est trop utilisé pour qu’Apple l’abandonne et surtout, il contient trop de fonctions spécifiques au Mac qui sont absentes du nouveau framework.

Il ajoute que si UXKit devait sortir de son cadre actuel — un framework privé réservé à Apple —, ce serait plutôt pour offrir un complément minimal aux développeurs iOS qui souhaiteraient porter leurs apps sur Mac. Il ne s’agirait pas de remplacer complètement AppKit, mais plutôt d’offrir les fonctions de base nécessaires pour faire une petite application. Mais dans ce cas, AppKit pourrait largement suffire, précise le développeur et dans ces conditions, à quoi bon compliquer l’offre en maintenant deux frameworks différents ?

On pourrait lui rétorquer que Photos n’est pas un petit logiciel alors qu’il exploite déjà UXKIt. Il paraît évident que, si Apple sortait ce nouveau framework, ce ne serait pas pour arrêter AppKit immédiatement. Mais il ne semble pas non plus impensable que les deux framework coexistent le temps que le nouveau venu s’enrichisse au fil du temps et qu’à terme, UXKit remplace AppKit.

De la même manière que, si tout va bien, Swift devrait remplacer un jour Objective-C, mais qu’en attendant les deux langages coexistent. D’ailleurs, Photos a été entièrement codé en Objective-C, la preuve que ce langage n’a pas dit son dernier mot, même si Swift est le futur.

avatar nono68200 | 

Vous avez bien résumé la situation.
Ça me fait rire ce genre de personne qui disent que ça ne remplacera jamais un vieux framework, parce qu'il est incomplet. Un framework, ça s'améliore, se complète... Si Le nouveau framework s'ouvre aux développeurs, il est certain que AppKit restera à ces côtés pendant un certain moment, mais ça n'empêche pas au nouveau framework de prendre sa place dans quelques années...

avatar bpisano | 

@nono68200 :
Exactement je suis de ton avis. Mais UXKit serait une bonne nouvelle et ça inciterai beaucoup de développeur à créer une version Mac de leur application iOS. Histoire de remplir ce MacAppStore.

avatar C1rc3@0rc | 

Le passage d'OS X a iOS n'est pas le problème.
C'est le passage d'un écran d'ordinateur, sur lequel l'utilisateur utilise une souris (ou un trackpad), a celui d'un iPhone ou iPad - sur lequel l'utilisateur agit avec ses doigts. Toute l'interface, dans la logique et sa réalisation est a refaire.

La ou une API unifiee a du sens c'est pour faciliter le passage (et l'indépendance) de la plateforme. Lorsque Apple va passer les Mac sous ARM, il n'y aura pas de Rosetta ou autre emulateur, les applications seront natives, et l'objectif d'Apple c'est que ça ne nécessite qu'une recompliation - une case a cocher dans XCode.

Aujourd'hui c'est quasiment possible iOS et OS X partage 95% de leur code et surtout les API. Le gros morceau ce sont les API graphique (interface utilisateur) qui changent. En encapsulant AppKit dans UXKit, Apple modernise AppKit et rend cette transition plus simple.

avatar pfx | 

Ça laisse présager l'iPad Pro avec un OS a mi chemin entre OS X et iOS! Qui remplacera peut-être un jour OS X!

avatar Hugualliaz | 

@pfx :
Peut être pas tout de suite mais je suis sur que l'on va vers une fusion du genre que l'on verra vers iOS X

avatar AllanZ | 

Très bonne nouvelle ! Le Mac AppStore en aurait bien besoin.

@pfx : Ça, ça m'étonnerait.

avatar YAZombie | 

"un logiciel comme Reeder adopte déjà de nombreux éléments d’iOS, mais c’est parce que son développeur a tout refait lui-même"
C'est pour ça qu'il ne répond JAMAIS aux demandes de support, même pas la simple courtoisie d'un accusé de réception? Silvio Rizzi a vraiment beaucoup de mal à respecter ses clients.

avatar Ali Baba | 

"Photos a été entièrement codé en Objective-C"

Normal en même temps, s'ils ont repris le code de l'app iOS.

avatar AllanZ | 

@Ali Baba :
Mais ils parlent de Photos sur iOS. ^^

avatar ovea | 

@Ali Baba : ça veux pas dire non plus que tout en étant développé en Swift il n'ont pas un traducteur vers O-C

avatar debione | 

Quand je vois la gueule des appli portée de iOS vers OSX, je me dis que c'est une très très mauvaise idée... Cela va remplir de merde l'app store, d'appli pas du tout optimisée, comme cela commence déjà à être le cas...

C'est du pognon pour du pognon, une appli faite pour fonctionner sur un écran de 5" tactile, doit-être complètement réécrite, son interface complètement réétudiée afin de fonctionner et d'être agréable sur un 27" clavier/souris.

C'est en fait déjà hyper visible avec Photos: La présentation sur un écran 27" est hyper bordélique... J'ai testé (je l'attendais avec impatience pour migrer d'Aperture), ben je vais rester sur Aperture encore un moment, en espérant une refonte de la présentation... Parce qu'avoir 20K de photos toutes bien triée, et devoir tout retrier parce que bon vous voyez, maintenant on classe différemment...

Bref, j'ai l'impression de voir l'évolution d'Itunes dans ce photos... De plus en plus compliqué, de moins en moins ergonomique, au point au j'ai actuellement une légère appréhension quand je dois faire quelques choses de très précis dans iTunes, car je sais que je ne vais pas simplement faire l'action, mais commencer par devoir fouiller parmi des termes de plus en plus obscures pour savoir ou c'est...

C'est peut-être la que ce sent plus l'absence de Jobs. La simplicité commence à disparaître (hyper visible dans iOS 8, ou je suis presque obligé de faire une recherche google afin de savoir ou se trouve la fonction que je recherche.) Bref, j'ai l'impression qu'Apple prend de plus en plus un visage windowsien en empilant les fonction les unes sur les autres, sans se soucier de la simplicité....

avatar RBC | 

Debione : Qu'elles fonctions n'avez vous pas trouvée dans IOS 8 ? Donnez nous des exemples ?

avatar debione | 

Le dernier en date: trouver ou se trouve la fonction localiser mon iphone afin de la désactiver... Ben j'ai du passer par google pour trouver, parce que c'est tellement évident d'avoir cette fonction sous... iCloud...
Genre comment trouver dans mail ou dans les réglages comment se débarrasser de certains dossiers mails, on peut continuer ainsi de tête me rappelle la prise de tête pour comprendre ou est quoi dans iCloud et ce qu'il fait... Il y a des menu iCloud partout, sans aucune explication, du coup j'ai désactivé... Chercher évidement comment changer le son de l'alarme, dans l'option son, ah ben non mon gars, tu peux pas régler ce son là (alors que tu peux pas virer le soft) dans cet endroit là, il faut aller sous le soft horloge..

Une chose est sur depuis le passage à ios8 c'est que j'ai jamais eu autant de gens qui sont venu me demander ce qu'il se passait avec leurs matos Apple, on te dis que ça synchronise, mais tu sais jamais quoi, des fois ça se synchronise avec l'ipad et l'ordi de la personne, mais pas avec l'iphone...

Je suis un Apple user d'assez longue date et j'ai toujours pu aider grandement les gens qui avait du mal... Mais la depuis iOS 8, j'ai repris un vieux réflexe windosien: Si dans les 10 secondes je n'ai pas trouvé le problème ben j'efface toutes les données de l'iphone et on réinstalle le tout... Tellement plus rapide que d'apprendre par coeur que telle fonction ne se trouve pas sous son nom mais sous un autre...

Bref on en arrive au point ou tu ne peux plus juste utiliser le produit, le temps de sa durée de vie, sans passer par quelqu'un qui t'aide, et la les gens qui ne s'intéresse pas à l'info (cad la majorité des utilisateurs) ne comprenne plus rien du tout...

iCloud, ils ne savent même pas ce que c'est, ni à quoi cela sert, ni si on peut ou pas s'en passer... Ca me rappelle une discussion avec un acteur de théâtre qui avait iphone, un ipad et un mba... Comment fait-on pour avoir côte à côte un texte qui pourra être poursuivi sur les différentes machines et l'autre pas? Ben la je lui ai conseiller de se payer un informaticien pour lui expliquer vraiment, car moi j'en suis bien incapable...

Bref, les fonctions sont intéressantes, mais j'ai l'impression que le temps du "tant que ce n'est pas implémenter exactement comme on le souhaite on ne met pas la fonction" est complètement révolu... Les gens qui avaient choisi le mac pour sa simplicité commence à se dire que cela devient comme window, une multitude de fonctions, dont le 95% des utilisateurs ignorent même la présence...

Va dans un Apple store, et demande au premier vendeur venu de t'expliquer le fonctionnement exact (pas juste l'idée) d'icloud... Tu verras que même ceux qui te vendent le matos Apple ne savent pas exactement de quoi ils parlent...

avatar Fego-007 | 

@debione :
+10000! Expliquer Icloud et toutes ses subtilités quand on a plus de 2 appareils ... Pas évident j'experimente Ca avec mes clients ( prestations informatiques ) et ils ont de plus en plus de mal à comprendre ..

avatar BeePotato | 

Boarf…
Franchement, ça n’a pas un énorme intérêt, ce framework.
AppKit et UIKit sont déjà très proches, bien plus proches que ce que laisse penser cet article — ce qui est normal, le second étant dérivé du premier. Ce n’est vraiment pas cassant de passer une application de l’un à l’autre.
Oh, bien sûr, c’est bien plus de travail que de juste recompiler en utilisant le framework magique qui fait tout le travail.
Mais justement, je doute fortement qu’il fasse tout le travail : le plus gros du boulot, c’est d’adapter l’interface de l’application, généralement en la revoyant de fond en comble ou presque, vu les différences ergonomiques entre un appareil sous iOS et un Mac.
Or ce genre de framework, ça va à l’encontre de cette approche, puisque ça incite à conserver tel quel tout ce qui se recompile sans problème, en faisant à peine un effort minimal de réorganisation de quelques éléments (et encore). On peut depuis longtemps voir ce que ça donne avec un exemple comme Qt.

Bref, je partage l’inquiétude déjà exprimée par d’autres ici de voir débarquer sur Mac un tas d’applications iOS non adaptées à Mac OS, si ce framework est un jour rendu public. On a déjà pu en voir arriver quelques unes, notamment faites par des développeurs qui ont considéré que leur temps était mieux utilisé à développer un équivalent d’UXKit qu’à faire une version Mac OS propre de leur application.
Je ne suis donc pas embalé du tout.

avatar alecail | 

Ce genre d'effets est visible dans XCode 6 depuis juin 2014. Quand vous avez des problemes de contraintes Autolayout, une petite fenetre glisse par dessus pour proposer les solutions possibles...

CONNEXION UTILISATEUR