Fermer le menu

Marzipan : est-ce une bonne idée d'unifier les apps iOS et macOS ?

Stéphane Moussie | | 20:30 |  82

À la fin de l’année, quand vous téléchargerez une application sur votre iPhone, elle s’installera peut-être aussi automatiquement sur votre Mac, en plus de votre iPad, votre Apple Watch et votre Apple TV.

Apple prévoit en effet de donner la possibilité aux développeurs de créer des applications vraiment universelles, fonctionnant à la fois sur iOS et sur macOS, a révélé récemment Mark Gurman. La nouvelle, qui reste une rumeur à ce stade, mais une rumeur à prendre très au sérieux au vu du pedigree du journaliste, a fait sursauter toute la communauté des développeurs Apple.

C’est que le projet secret, qui porte le nom de code Marzipan, pourrait bouleverser la création des applications et le marché. Une perspective qui réjouit autant qu’elle inquiète les développeurs.

WWDC 2017

Un framework commun en vue

Bien que macOS et iOS partagent des technologies communes, les développeurs doivent utiliser actuellement deux boîtes à outils différentes pour créer des applications sur chaque plateforme.

Le framework du Mac, dont les origines remontent à NeXTSTEP (d’où le préfixe NS de ses classes), s’appelle AppKit. Le framework d’iOS, qui a été créé de zéro pour ne pas s’embarrasser du vieil héritage du Mac, se nomme UIKit.

Ces frameworks ont chacun leur propre logique. Pour prendre un exemple parmi tant d’autres, la classe UIColor d’UIKit sert à la même chose que la classe NSColor d’AppKit, mais elle s’utilise différemment. Il ne suffit pas de remplacer les préfixes UI par des NS pour convertir une application iOS en application Mac, ou inversement.

C’est cette bipartition qu’Apple veut faire disparaître au plus tôt cette année, selon le journaliste de Bloomberg. Il ne cite pas explicitement la création d’un framework commun, mais c’est ce qui sous-tend la possibilité de « concevoir une seule application qui fonctionne avec un écran tactile ou une souris selon qu’elle tourne sur un iPhone ou un Mac. »

Une lecture renforcée par l’existence d’UXKit, un framework utilisé en catimini par Apple qui facilite la transition d’iOS à macOS. Vous pouvez remplacer les préfixes UI par des UX, et le résultat fonctionne sur Mac, comme le montre l’exemple ci-dessous avec UITableView converti en UXTableView.

Mais ce nouveau framework, qui est utilisé par l’application Photos et l’application Prix des Apple Store, n’a toujours pas été officialisé par Apple et ne peut donc être exploité par les développeurs. Le projet Marzipan (massepain en français, un biscuit aux amandes) consiste peut-être en son perfectionnement et son lancement public.

Les craintes

L’idée d’un nouveau framework commun à macOS et iOS fait frémir des développeurs pour plusieurs raisons. Certains imaginent déjà un abandon d’AppKit et UIKit au profit de Marzipan (appelons-le comme ça) à long terme, ce qui obligerait à réécrire toutes les applications.

« On ne peut pas le nier, ce serait emmerdant pour une partie des développeurs, explique l’un d’entre eux, Joe Cieplinski, dans une longue analyse de la rumeur. Ceux qui auraient la meilleure raison de se plaindre de Marzipan, ce sont ceux qui ont les plus gros projets historiques. »

Une telle transition, purement spéculative au moment de la rédaction de ces lignes, faut-il le rappeler, a déjà eu lieu avec le passage du jeu d’API Carbon à Cocoa qui s’est étalé sur plusieurs années.

Sur les 30 années passées à développer l’utilitaire PopChar, « le plus gros changement a été la transition de C++ (avec Carbon) vers Objective-C (avec Cocoa) », nous avait indiqué son créateur Günther Blaschek. « Il a fallu tout reprendre de zéro ; pas seulement l’interface utilisateur, mais toutes les technologies fondamentales de polices. »

Et une réécriture pour quel résultat ? Pour une application que l’on ne pourra facturer qu’une seule fois ? Qui dit application complètement universelle, dit en effet achat unique de la part du consommateur. À l’heure où des éditeurs font toujours payer séparément leurs applications iPhone et iPad, cela risque de faire grincer des dents.

C’est peut-être pourquoi Apple pousse fortement le modèle de l’abonnement depuis 2016. Plutôt que de faire payer cher le téléchargement d’une application compatible avec l’iPhone, l’iPad et le Mac, les éditeurs pourraient lisser le coût sur la durée avec un abonnement.

Se pose aussi la question de la qualité des applications Mac nouvellement créées. Ne va-t-on pas voir déferler un torrent de portages d’apps iOS fait à la va-vite, sans bonne adaptation à la souris et au clavier ? C’est une appréhension de certains développeurs Mac « historiques », dont Michael Tsai :

Je ne veux pas utiliser le plus petit dénominateur commun, [c’est-à-dire] les portages iOS. J’aime utiliser le Mac parce que ses applications tirent vraiment partie de tout ce qu’un environnement de bureau a à offrir. Je suis toujours ennuyé par les applications qui consistent essentiellement en une interface iOS dans une fenêtre et qui ne prennent pas en charge les conventions ou les fonctionnalités du Mac.

Les espoirs

« Mais qui s’en soucie ? lui répond indirectement Joe Cieplinski. Il y a déjà une tonne de merdes disponibles sur Mac. Voilà ce qui compte : les gens pour qui les bons logiciels sont importants sépareront le bon grain de l’ivraie. Et les gens pour qui créer un bon logiciel est important feront leur boulot. »

Interrogé par nos soins bien avant la rumeur Marzipan, en février 2016, le développeur Steven Troughton-Smith réfutait pour sa part qu’un framework commun entraîne forcément de mauvaises apps Mac :

Les applications tvOS sont parfaitement adaptées aux téléviseurs, en dépit du fait qu’elles sont créées avec le même UIKit que nous utilisons pour les apps iOS. [Un framework commun] ne signifierait pas qu’OS X aurait de simples applications iOS. Ça signifie au contraire que les développeurs pourraient concevoir et fabriquer des applications sans se soucier d’un second paradigme.

Selon ces deux programmeurs, un framework unique pourrait être une immense chance pour les créateurs d’apps et au bout du compte pour les utilisateurs.

Les bons développeurs iOS qui ne codent pas pour Mac à cause de la barrière des frameworks pourraient finalement s’intéresser aux applications de bureau, et inversement. Cela baisserait aussi la barrière à l’entrée de l’écosystème Apple pour les nouveaux développeurs, armés dès le départ pour créer des applications Mac et iOS. « Plus de sang neuf est synonyme de plus d’innovation, plus de créativité et plus de diversité », fait valoir Joe Cieplinski.

Les développeurs Mac + iOS actuels pourraient aussi y trouver leur compte. Un framework unifié leur permettrait de réduire le nombre de lignes de code (et corolairement le nombre d’erreurs possibles) en partageant plus d’éléments entre les différentes versions d’une même application.

Quant à la question d’une éventuelle réécriture, cette opération serait effectivement chronophage, mais elle permettrait de repartir sur une nouvelle base plus saine, comme en témoignait l’auteur de PopChar : « Au bout du compte, j’ai été surpris de voir que le résultat était bien plus propre et cohérent. »

On peut même voir en Marzipan un moyen de stopper (un peu) la prolifération des applications écrites avec des technologies multiplateformes qui ont généralement des performances bien en deçà des apps natives. En facilitant le développement pour ses deux principales plateformes à la fois, Apple encouragerait peut-être une petite partie des éditeurs à privilégier ses outils plutôt que d’autres.

Enfin, plutôt que tiré vers le bas, le Mac pourrait ressortir grandi en bénéficiant de nouvelles fonctionnalités en même temps qu’iOS, ce qui n’est pas le cas aujourd’hui. Il y a l’exemple symptomatique du Mac App Store, qui est à mille lieues de l’App Store. À ce sujet, les nouveautés de l’App Store d’iOS 11 (mise en avant de la compatibilité avec les appareils, fiches Mac App Store visibles sur iPhone…) ne sont-elles pas annonciatrices d’une fusion des boutiques d’applications ?

Rendez-vous à la WWDC ?

Alors, le verre sera-t-il plus à moitié plein ou à moitié vide ? Il faudra attendre la WWDC, probablement, pour connaître les plans exacts d’Apple et se faire une opinion plus précise, car pour l’heure, on en reste au stade des spéculations.

Mais il est indéniable que macOS est désormais l’« intrus », pour reprendre un terme de Steven Troughton-Smith, dans l’écosystème de développement Apple. Et au vu de la mutualisation en cours dans le matériel, avec l’intégration des puces Tx au Mac, il serait surprenant qu’Apple ne fasse pas la même chose sur le plan logiciel.

Catégories: 

Les derniers dossiers

Ailleurs sur le Web


82 Commentaires Signaler un abus dans les commentaires

avatar ThonyMora 17/01/2018 - 20:36 via iGeneration pour iOS

Espérons que cela fonctionne et ça arrive vite... ça serait idéal 😉👍🏻

avatar C1rc3@0rc 17/01/2018 - 22:16

Tout depend en fait de l'idee d'Apple derriere.
Si c'est pour finir d'enterrer le Mac en en faisant un probleme secondaire qui va heriter d'une application iOS qui suit bien les lignes de conduites, ça va etre catastrophique.

Pourquoi je dis ça?
Eh bien parce qu'a la base du succes et de la reputation du Mac il y a... l'interface graphique!
Ce qui a fait la difference entre Apple et IBM puis Mcrosoft c'est l'interface "user friendly" du Mac.

Et pour les developeurs qui ont connu l'Apple d'avant MacOS X ou NeXT, voire meme les premieres annees de MacOS X, ou pour ceux qui comme moi sont passionnés par l'histoire informatique, ils se souviendront de la qualité et de la rigueur des manuels de programmation de MacOS abordant specifiquement l'interface graphique.
Et si dans la bible Inside Macintosh il y avait specifiquement une partie exclusive dediee a l'interface graphique, tous les tomes sont impregnés de la culture de cette interface et de son ergonomie.

Inside Macintosh c'est, avant d'etre une reference de programmation, un manuel d'ergonomie logicielle!

Ce qu'il faut comprendre c'est que la conception d'une interface d'un PC et d'un device sont deux choses totalement antagonistes.
De fait, si on peut "porter" directement un moteur de calcul d'un PC sur un device, le travail sur l'interface ne peut se faire qu'en partant de zero sur la plateforme.
Et il est plus cohérent d'adapter une interface Windows ou Linux(gnome) sur MacOS qu'un interface iOS sur MacOS.

L'idee d'une interface commune et "adaptative" n'est pas nouvelle et a ete expérimenté plusieurs fois, avec des catastrophes a la cle:
- Windows mobile 5 et 6 (oui, la version d'avant le rachat de Nokia)
- Metro, l'interface de Windows 8
- Swing, de Java (write once, run everywhere... a tel point que Google a cree son UI pour Android...)
- HTML5: un site "responsive" consiste a ecrire une interface pour chaque format en realité que ce soit de façon statique ou dynamique (a l'aide de bibliotheque JS: une horreur pour la pérennité de l'information)

L'approche de Jobs de refuser le tactile sur Mac etait aussi dans cette ligne: il faut concevoir une application desktop pour l'usage de la souris/trackpad et clavier, pas pour etre un ecran manipuler avec les doigts. L'idee de ne pas integrer le stylet dans l'interface iOS etait similaire ( bon, ok, il aurait pour decider de limiter l'usage du stylet au dessin comme c'est heureusement ecore le cas)

Avec une UI commune le developpeur qui va vouloir faire du fric vite-fait va designer une interface tactile pour iOS et... c'est tout. L'experience sur MacOS va devenir pire qu'elle ne l'est deja avec la plupart des immondices provenant de "portages" d'iOS sur MacOS.
Mais le pire c'est le melange. Si le gars melange UI MacOS et iOS, on va avoir un truc batard, qui sera imprengné de manipulation tactile sur MacOS et de pilotage au stylet sur iOS... et la on va arriver aux interface de Windows et Wnidows Mobile.

apres, on peut comprendre aussi l'idee des dirigeants d'Apple: imposer l'apprentissage d'un framework specifique au Mac, veut dire qu'il faut mettre des ressources pour le developper et motiver les developpeurs a l'utiliser... pour un produit qui est devenu accessoire pour Apple - le Mac - et qui a moyen terme etait condamné, c'est pas tres coherent, ni rentable.

avatar PowerGlove 18/01/2018 - 08:33

@ C1rc3@0rc
N'importe quoi comme d'habitude...
Quel est le rapport entre des applications unifiés entre les plateformes et l'os??

" Si le gars melange UI MacOS et iOS, on va avoir un truc batard, qui sera imprengné de manipulation tactile sur MacOS et de pilotage au stylet sur iOS... et la on va arriver aux interface de Windows et Wnidows Mobile."

Ce qui a été reproché à microsoft c'est son os, pas les applications... Ton exemple prouve exactement le contraire de ce que tu dis... c'est justement parce que les applications et les développeurs ne sont pas rentré dans son jeux, que microsoft a fait machine arrière pour son interface. Personne ne croit qu'une application textuel ou un logiciel 3D va devenir tactile....

Il y a toujours eu des logiciels mal écrits depuis l'origine de l'informatique, et le fait de faire un univers de dévellopement plus simple va au contraire dans le bon sens. Ensuite les mauvais logiciels, personne ne les utilisent et donc ils disparaissent...



avatar C1rc3@0rc 19/01/2018 - 02:04

@PowerGlove

C'est pourtant tres exactement le principe de base de Metro lors de sa presentation... renseignes toi..

L'idee de Microsoft etait bien d'unifier l'interface pour que le developpeur n'ait qu'un seul developpement a faire, le deployement pouvant ensuite se faire automatiquement sur PC comme sur Windows Phone. MS comptait d'ailleurs sur cette dynamique pour compenser tres vite l'absence d'app sur Windows Phone...

Apres, je reviens sur mon propos sur MacOS et son framework.
Le developpeur est contraint par le framework pour realiser l'interface. Dans Inside Macintosh le principe ergonomique est omnipresent. C'est cela qui a guide le developpement d'applications de plus en plus ergonomiques sur Mac. Sans cela on en serait toujours a la ligne de commande.

avatar pat3 18/01/2018 - 12:26 via iGeneration pour iOS

@C1rc3@0rc

"- HTML5: un site "responsive" consiste a ecrire une interface pour chaque format en realité que ce soit de façon statique ou dynamique (a l'aide de bibliotheque JS: une horreur pour la pérennité de l'information)"

Euh… un site responsive ne s’écrit pas avec HTML5 mais avec CSS3, des médias queries, du flexbox et aujourd’hui des flexgrids. Relis Ethan Marcotte…

avatar C1rc3@0rc 19/01/2018 - 02:09 (edité)

HTML 5, meme si le terme est abusif, decrit l'ensemble des technologies implique dans ce qui est encore plus absusivement qualifie de Web 2.0. CSS3 et ECMAscript sont indisociables de HTML5 et les librairies sont la consequences de la complexite d'HTML5
Sinon expliques moi comment tu fais pour utiliser la balise canevas, qui est un ajout de HTML v5 a HTML...
De fait, un site responsive ne peut pas etre ecrit sans HTML5...

avatar pat3 18/01/2018 - 12:41 via iGeneration pour iOS

@C1rc3@0rc

"L'experience sur MacOS va devenir pire qu'elle ne l'est deja avec la plupart des immondices provenant de "portages" d'iOS sur MacOS."

Re-bullshit. C’est pénible, ces généralisations hâtives… Comme toujours, il y a des apps de merde, mais aussi des apps très bien faites démarrées sur iOS puis portées sur Mac (je pense à iThoughts et iThoughts X, voir https://toketaware/about/). Mais comme d’hab, tu généralises sans donner d’exemples…



avatar Jacti 18/01/2018 - 12:41

Je suis d'accord avec vous. J'ai toujours été et je le suis toujours contre le trop grand rapprochement entre MACOSX et IOS. Je suis contre le tactile sur le Mac car ça n'a aucun sens pour la plupart des logiciels que j'utilise, notamment metasynth, tassman et même Logic Pro. Je suis contre le fait que des app IOS s'installent automatiquement sur les autres appareils. Perso nous avons, avec ma femme, 2 iPhones, 2 iMacs, un iPad et un Apple TV4. Je n'ai aucune envie, pour la plupart des apps, qu'elles s'installent sur tous ces appareils. De toute façon le cloud est désactivé partout, le wifi de la livebox fibre est désactivé. Mon réseau domestique passe par ma borne Apple extrême (en partie par wifi, en partie par Ethernet (le wifi sur les iMacs est désactivé).

avatar reborn 18/01/2018 - 14:57 via iGeneration pour iOS

@Jacti

« Je suis contre le fait que des app IOS s'installent automatiquement sur les autres appareils »

Ça ne se fait pas automatiquement, il faut activer l’option

avatar Jacti 18/01/2018 - 17:08

Merci

avatar C1rc3@0rc 19/01/2018 - 02:16

Le gros probleme dans ce que tu decris c'est qu'Apple active a terme - d'origine - des systemes. On peut encore installer MacOS sans activer iCloud, mais on ne peut pas obtenir MacOS sans compte iCloud...
Et ces "options" comme presentees au depart deviennent particulierement compliquees a desactiver au fur et a mesure. Il y a ici une volonte d'emprisonnement et de contrainte de la part d'Apple qui est de plus en plus innaceptables et conduit a des catastrophes des que le systeme s'effondre sous son poids

Apple a quand meme reussi a imposer un OS sois disant gratuit, qui a chaque mise a jours quasi forcee diminue les fonctions de l'appareil et on ne peut pas revenir en arriere et jamais decider de la version utilisable. Et l'orientation va dans le meme sens pour MacOS

avatar JoTaPé 18/01/2018 - 21:45

Bon analyse comme souvent. Qui, des développeurs actuels chez Apple a lu Inside Macintosh et ses principes d'ergonomie ? Développer pour iOS, iPhone ou iPad, c'est développer pour un écran riquiqui et aussi bien sur le plan visuel que gestuel, il n'y a aucun point commun entre ces appareils et un ordinateur de bureau.Tout ce que tu cites de l'Apple d'avant est depuis quelques années déjà mis au rencart au seul profit du dieu Rentabilité.
On aime ou pas, Apple a changé, c'est tout.

avatar C1rc3@0rc 19/01/2018 - 02:17

Merci

avatar vlsf1 17/01/2018 - 20:38 via iGeneration pour iOS

Perso je suis pour, mais essentiellement parce que je suis fan de pate d’amande.

Et sinon j’ai très peu d’applications iOS qui me serviraient sur Mac... éventuellement Transit.

avatar Mickaël Bazoge macG 17/01/2018 - 20:48

C'est mal barré pour Transmit :-( https://www.igen.fr/app-store/2018/01/le-studio-panic-arrete-les-frais-fin-de-route-pour-transmit-sur-ios-102542
+1 pour la pâte d'amandes en revanche.

avatar Malouin 17/01/2018 - 21:18

Euh... Il s'agit de l'application Transit ! Qui, sur iPhone, est un Must ! Allez, vous êtes pardonné...
Pour autant, cette "plate-forme" commune ouvre des horizons inexplorés. Toutes mes applications Mac sont aussi présentent sur mon iPhone et mon iPad...

avatar Mickaël Bazoge macG 17/01/2018 - 21:20

😅 au temps pour moi ^^ j'ai lu trop vite. Mais sinon oui, ça ouvre des horizons intéressants, je pense en particulier à l'iPad qui pourrait bénéficier des apps macOS qui lui manquent (et inversement).

avatar Malouin 17/01/2018 - 21:33 (edité)

Je pense la même chose... Avec une ergonomie et des usages repensés. En tous cas, bravo pour votre site et pour vos articles ! Vous êtes clairement les meilleurs !

avatar IceWizard 17/01/2018 - 22:09

@Mickaël

"Mais sinon oui, ça ouvre des horizons intéressants, je pense en particulier à l'iPad qui pourrait bénéficier des apps macOS qui lui manquent (et inversement). »

Clairement NON ! Quelle que soit la technologie choisie par Apple, cela ne sera pas une boîte magique je-fais-tourner-une-app-macOS sous iOS. Le problème n’est pas technique mais ergonomique. On se dirige plutôt vers un système avec un moteur d'exécution et plusieurs interfaces intégrées dans l’application. Je ne pense pas qu’une app macOS « normale » puisse tourner efficacement sur un iPad, sans des modifications importantes, les paradigmes d’interface étant trop différents.

avatar Mickaël Bazoge macG 17/01/2018 - 22:11

Ah, je n'ai pas dit le contraire. Il ne s'agit pas de plaquer bêtement une app iOS sur Mac, et vice-versa sinon ça risque de ne pas fonctionner très bien. Disons que Marzipan devrait faciliter la vie des développeurs qui vont pouvoir se concentrer sur l'ergonomie justement.

avatar FloMo 17/01/2018 - 22:21 via iGeneration pour iOS

@IceWizard

Les apps Pages, Numbers et Keynote ont 80 % de leur code en commun sur macOS et iOS. Y compris côté UI.

Aujourd’hui, les frameworks graphiques Apple semblent clairement s’appuyer sur Metal qui est commun aux deux plateformes.

Le passage au 64 bits est bien forcé également.

Swift est naturellement cross-plateformes. En particulier grâce à LLVM.

On est à 2 doigts d’une fusion des technologies.

Ça fera comme les UI iPad / iPhone : ça s’adapte.

avatar IceWizard 17/01/2018 - 23:39

@FloMo
Euh .. je parle d’ergonomie, et d’adaptation optimale des interfaces aux différentes plates-formes et tu me répond technique et nombre de lignes de code..

Tu ne m’apprend rien là. Quand Apple a commencé à parler d’UXKit j’ai porté une application Swift iOS sous macOS pour voir ce que cela faisait. Il y a plus de 90% de code commun entre les deux, mais j’ai quand même méchamment dégusté pour me mettre à AppKit.

Franchement quelle importance que les composants graphiques soient conçus à partir de Metal, pour la création d’une interface utilisateur ? Un roman n’est pas meilleur s’il est écrit avec un crayon de papier, un porte-plume, un style bille ou un traitement de textes. D’ailleurs le premier tome d’Harry Potter a été rédigé dans un café, sur du papier avec un stylo.

Un composant graphique est un outil de communication destiné au cerveau humain. Il sert à transmettre une information ou permettre d’exécuter une action. Une interface est un objet complexe dont la création fait plus appel à l’esthétisme, à l’art, à l’ergonomie fonctionnelle et surtout au bon sens qu’à la programmation.

Quand aux UI communes iPad/iPhone .. c’est loin d’être encore l’idéal. On vois encore trop de jeux vidéo « universels » avec des textes minuscules, à la limite de la lisibilité sur iPhone, parce que les développeurs ont surtout conçus des interfaces iPad, avec un coefficient de réduction automatique pour iPhone, sans se préoccuper de la lisibilité réelle. Probablement même sans faire de tests, parce que « cela vas marcher, c’est certain, puisque c’est le même code ».

Ne parlons même pas des zones de clics devenant vraiment riquiqui sur iPhone, à cause du redimensionnement automatique qu’il faut parfois cliquer 5 ou 6 fois pour arriver à les activer. Ce n’est pas un problème technique mais d’une mauvaise conception et d’un manque de tests (ou un surplus de jean-foutisme).

Bref, il y a du travail HUMAIN à faire pour adapter les interfaces, même pour faire des choses simples.

avatar PowerGlove 18/01/2018 - 08:40

Perso j'ai pas mal d'application Ipad iPhone et je trouve globalement que le travail est bien fait dans les changements d'interface en fonction de la taille d'écran. On peux toujours voire le verre a moitié vide, mais je trouve que beaucoup de développeur travail bine la dessus. Ensuite c'est toujours plus confortable sur un grand écran, mais je n'ai jamais rien vu d'inutilisable sur iPhone.

avatar IceWizard 18/01/2018 - 10:20

Le problème ne se pose pas avec les applications iOS classiques, le système de contraintes AutoLayout et le mécanisme d’ajustement des polices d'Apple est efficace. Mais ces mécanismes n’existent pas sur les framework de création de jeu vidéo, où l’ajustement de la taille des polices se fait en fonction de la taille de l’écran. J’ai notamment vu le problème sur certains titres de Gameloft.

avatar BeePotato 18/01/2018 - 10:40

@ IceWizard : « Bref, il y a du travail HUMAIN à faire pour adapter les interfaces, même pour faire des choses simples. »

Tout à fait d’accord !

Pages