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

Stéphane Moussie |

À 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.

avatar ThonyMora | 

Espérons que cela fonctionne et ça arrive vite... ça serait idéal ???

avatar C1rc3@0rc | 

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 | 

@ 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 | 

@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 | 

@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 | 

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 | 

@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 | 

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 | 

@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 | 

Merci

avatar C1rc3@0rc | 

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é | 

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 | 

Merci

avatar vlsf1 | 

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 | 
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 | 

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 | 
? 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 | 

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 | 

@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 | 
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 Florent Morin | 

@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 | 

@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 | 

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 | 

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 | 

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

Tout à fait d’accord !

avatar C1rc3@0rc | 

Je vois pas une application native embarquer le foutoir qu'est un site Web "responsive"

Un modele mutliplateforme existe depuis un moment: c'est Qt (y en a d'autre mais c'est le plus abouti).
Le gars qui utilise Qt va pouvoir faire du tres bon travail et vraiment faire du multiplate-forme en limitant l'ecriture et en se concentrant sur les specificités que le framework ne gere pas.

Mais s'il va pouvoir faire un design unique pour les PC (MacOS, Windows, Linux) qui fonctionne bien, il va falloir qu'il fasse un design specifique pour iOS et Android.
Et chaque application est generée nativement pour chaque plateforme, c'est le seul moyen d'avoir un soft un peu optimisé.

Je n'aborde pas le cas du jeu: sur MacOS c'est un desert et sur iOS c'est une production qui se fait derriere Unity et Cie, avec l'interface que celles ci permettent et qui est specifique.

Mais si on prend la majorité des applications iOS, ce sont d'abord des interfaces graphiques d'acces a des services Web, avec tres peu de "mecanique" (moteur de traitement). Pourquoi? Parce que l'interface native iOS est bien plus pertinente qu'une interface Web "responsive". Et que jusqu'a maintenant, un device, c'est toujours un outil de consultation.

Pour MacOS on a surtout des applications avec des "gros moteur", qui sont de plus en plus des portages qui viennent de Linux ou Windows, et une interface specifique.

Bref, l'idee d'une app "universelle" qui soit conçue pour iOS d'abord et qui embarque une interface MacOS... je pense que c'est juste une marche funebre pour MacOS.

avatar JoTaPé | 

"Bref, l’idée d'une app "universelle" qui soit conçue pour iOS d'abord et qui embarque une interface MacOS... je pense que c'est juste une marche funèbre pour MacOS."
Oui, le corbillard est bien en route.

avatar Jacti | 

Moi c'est l'inverse. Je n'ai absolument pas les mêmes utilisations pour ces différents appareils.

avatar C1rc3@0rc | 

Tu pourrais développer?

avatar Jacti | 

J'utilise l'iPhone principalement pour téléphoner ou prendre des photos, l'iPad pour la domotique, télécommande pour différents appareils, lire la presse etc. et le Mac pour faire de la musique (Logic Pro, Metasynth, Tassman, MachFive 3, etc.) ou du développement Java ou C++. Je n'ai donc aucun besoin d'avoir des applis universelles et je ne souhaite pas que les différentes interfaces soient plus ou moins homogénéisées. A priori, il n'y a que pour l'utilisation des réseaux sociaux que les usagers souhaitent disposer de la même interface partout, non ? mais moi je n'utilise que très peu les réseaux sociaux et les SMS.

avatar asheden | 

J’avoue être particulièrement intrigué par le fonctionnement de ce système. Intéressant en tout cas

avatar roccoyop | 

Je pense qu’Apple prépare aussi le terrain pour les Mac sous ARM. Comme ça ils pourront dire que c’est une révolution, qu’il y a déjà XXXX applications compatibles et qu’il ne faut pas tout racheter (pour une fois).

avatar C1rc3@0rc | 

@roccoyop

«Je pense qu’Apple prépare aussi le terrain pour les Mac sous ARM.»

Non, clairement passer d'UIKit a UXkit n'a rien a voir avec un passage de MacOS Intel a MacOS ARM.

Pour faire tourner MacOS sur une machine ARM c'est le kernel de MacOS (darwin donc) qu'il faut porter. Et ça c'est deja le cas en tres grande partie puisque c'est... iOS.

Le reste du framework est inedependant de la plateforme (a quelques exceptions pres comme celle qui gere la telephonie, et encore...)

Le probleme du Mac ARM pour Apple c'est que c'est d'abord un Mac, un produit qui etait en route pour le cimetière et qui devait etre remplacé par l'iPad Pro et l'iPhone.

On peut esperer que depuis une petite annee cette aberration ne soit plus d'actualité, mais bon la diva a la tete de la creation d'Apple n'a pas ete remplacé et son aversion pour le Mac n'est pas un facteur d'optimisme. Et puis quand on voit l'iMac Pro, une ineptie qui utilise ARM pour en faire un monstre tirer des cauchemars de la mini-informatique des annees 70, ça n'arrange pas les choses.

avatar PowerGlove | 

@C1rc3@0rc
J'aimerais comprendre:
Tu commence ton message par quelque chose de cohérent. L'interface n'a rien a voir avec le kernel.
Ensuite, je ne sais pas pour quelle raison, tu dévies comme d'habitude vers ta théorie du mac qui est mort.... et ta haine des mac actuels qui seront remplacés par l'pad et l'iphone, pourquoi ??
C'est juste ton point de vue, partagé par..... personne.... et lancé comme un argument... On a l'impression de lire une voyante...

avatar C1rc3@0rc | 

@PowerGlove

Apparamment tu n'as pas lu ou pas compris le commentaire auquel je repond. Le sujet en est le MacARM et l'auteur voit dans la fusion UIkit UXkit un pilier de la construction du MacARM.
Cela amene donc a repondre a la fois sur la nature du framework et sur l'absence ou la probabilite d'emergence d'un Mac sur une architecture ARM.

Nulle deviation mais bien un adequation au sujet.

De plus, ne denis pas l'existence de ceux qui partagent le point de vue que j'exprime, moins prompts a manifester leurs adhésion de manière affective que d'autres leurs haines ou agacement, meme si ne c'est pas le tiens.

avatar JoTaPé | 

On se demande comment une entreprise informatique sérieuse a pu mettre sur le marché ces aberrations que sont le cylindre MacPro et ce dernier iMacPro. Mac ou iMac peut-être mais vraiment rien de Pro ni pour les Pros dans ces deux machines destinées à je ne sais quels allumés fortunés.

avatar webHAL1 | 

Intéressant, Apple prend la même voie que Microsoft, mais avec quelques années de retard. Ce genre de transition prend beaucoup de temps, il faudra voir quelles incitations et quels obstacles la Pomme met à disposition des développeurs.

Cordialement,

HAL1

avatar reborn | 

@webHAL1

Vu le résultat sous windows ? c’est une des raisons qui m’a fait quitter W10

Ils se sont pas fait chier Microsoft, ils proposent la meme UI de partout..

avatar fousfous | 

Ce serait logique que ce soit en même temps que le passage à ARM non?

avatar IceWizard | 

@fousfous
"Ce serait logique que ce soit en même temps que le passage à ARM non? »

Rien à voir. Les applications iOS tournent très bien sur un processeur Intel, à condition d’avoir un framework adapté. Depuis 9 ans, Xcode génère les applications iOS en code Intel si elle doivent être testés sur le simulateur du Mac, ou en code ARM si c’est pour une installation sur un device.

avatar sensass | 

Peut-être que tu as raison, mais je pense aussi que ça facilite le passage vers ARM. Les développeurs font déjà leur application pour des smartphones ARM. Et là Apple veut simplifier la création d'application macOS et iOS en leur donnant une certaines similarité. Non seulement plus de logiciel seront créer sur le mac Apple store mais aussi ca permettra d'ajuster facilement les application lors du passage au mac ARM.

Pour résumer, je le vois comme un moyen à terme de fournir un catalogue assez conséquent d'applications en utilisant pour ça les développeurs iOS, lors du passage au mac ARM.

De toute façon on verra bien...

avatar occam | 

Logique et inévitable. Grabuge et chambardement garantis.

La question est de savoir si, en fin de parcours, il restera grand-chose de la plateforme Mac, telle qu'on la conçoit.
Bien des applications historiques qui sont indispensables à la conception du Mac comme "Unix à visage humain" risquent de ne pas survivre à une telle transition. Gageons qu'Apple y serait, au mieux, indifférent. Les racines trop anarchiques-autonomes du Power User (utilisateur-programmeur-dévelopeur) empiètent trop sur la conception du client-consommateur-vache-à-lait qui est le paradigme actuel d'Apple.

avatar Artefact3000 | 

Considérant ce que Apple a fait de Pages, pour le rendre semblable autant sur iOS que sur Mac (et en ligne), en lui retirant des fonctions, non, je ne suis vraiment pas certain que ce soit une bonne idée pour ceux qui préfèrent travailler sur MacOS plutôt que sur iOS.

avatar glaglasven | 

A mon sens c'est un scandale qu'on doive payer deux fois la même appli sur un même support software pour macos et ios ou ipad

avatar Lightman | 

Comme le disait @C1rc3@0rc je crois, s'il s'agit d'une encapsulation des deux builds, pourquoi pas ? Mais s'il s'agit de bibliothèques unifiées, ça me fait très peur : est-ce que Apple n'utiliserait-elle pas ce moyen pour « enfermer » l'utilisateur final sur macOS comme elle le fait sur iOS, avec évolution à marche forcée, etc. ?

Mes préoccupations premières sont philosophiques à long terme plus qu'économique à court terme. Une fois que l'utilisateur sera complètement ficelé dans cette prison dorée, la situation risque de se refermer comme une huître. Par exemple : ne pouvoir exécuter sur sa machine que ce qu'une autorité a décidé que l'on peut exécuter (connection permanantes voir apps dématérialisées), siffler la fin de la partie pour une application donnée (avec le modèle de l'abonnement), couper la connexion à n'importe qui (opérateurs-éditeurs), …

Peu de personnes apparemment ont le recul nécessaire pour voir les enjeux plus loin que le bout de leur nez. Malheureusement.
Macgé, ce serait bien que lors de votre travail de journaliste, vous aidiez les lecteurs à décrypter ces risques.

Heureusement, @C1rc3@0rc vient parfois contrebalancer ce manque, même s'il n'est pas très aimé par certains.

avatar reborn | 

@Lightman

Pas obligé de passer par le mac appstore

avatar Lightman | 

@reborn

Pour l'instant…

Depuis Snow Leopard, chaque version du système bride un peu plus l'utilisateur en rendant de plus en plus compliqué de faire certaines choses. Avec évidemment l'agitation de 2 chiffons habituels : sécurité et simplification. Comment expliquer par exemple que la fonction d'effacement de l'espace libre sur le disque dur est été supprimé dans outils disque dur ? Sécurité ? Désorientant pour Madame Michu ?

C'est pourquoi je suis toujours sous Snow Leopard.

avatar macam | 

@lightman :
Il me semble que l’effacement du disque a été supprimé parce que ça use prématurément les SSD (idem pour la corbeille qui ne peut plus être effacée en mode sécurisé).

avatar C1rc3@0rc | 

@macam

Non, en fait c'est plutot que c'est un vrai casse tete d'effacer un SSD.

Sur un disque a plateau, l'effacement securisé consiste a reperer le secteur (les secteurs en faits, en cas de fragmentations peut y en avoir un paquets a droite et a gauche) et ecrire dans ces secteurs des block aleatoires des 0 et 1, plusieurs fois de suite.

Sur un SSD en fait, l'OS a aucun moyen de savoir dans quelle celulle sont reparties les donnees. Donc on peut bien essayer de reecrire le fichier avec des aleatoire, rien ne permet de savoir si les données effectives sont ecrites sur des nouvelles cellules ou des qui sont deja utilisées...

Il faut comprendre qu'un SSD c'est un ordinateur dans l'ordinateur. On lui jette en pature des donnees, il les range comme il estime que c'est le mieux.

La solution c'est de chiffrer systématiquement les donnees. ce que va alors ecrire le SSD ce sont donc des donnees chiffrées. A ce moment, pour effacer les donnees, on se casse pas la tete, il suffit de dereferencer le fichier. L'index disparait et a la place il reste des donnees reparties dans les cellules du SSD qui finiront par etre remplies par autres chose a un moment donné...

avatar Lightman | 

@C1rc3@0rc

Merci pour les explications.

Pages

CONNEXION UTILISATEUR