L'interface multiplateforme pour iOS et macOS pourrait arriver en 2019

Florian Innocente |

La capacité pour des apps iOS à fonctionner sur macOS a plus de chances de survenir en 2019 qu'à la rentrée prochaine, écrit John Gruber sur Daring Fireball. Le blogueur a discuté de ce projet initialement connu sous le nom de code "Marzipan", révélé en décembre dernier.

Gruber, sur la foi de plusieurs sources de première et de seconde main « surtout de seconde main, mais elles disent toutes la même chose » raconte qu'il y a effectivement un projet chez Apple visant à mettre au point les moyens d'obtenir une interface multiplateforme pour les applications iOS et macOS.

Aujourd'hui chacune a sa boite à outils : AppKit sur Mac, UIKit sur iPhone et UXKit qu'Apple s'est réservée pour Photos sur Mac lorsqu'il a été réécrit pour succéder à iPhotos (lire Marzipan : est-ce une bonne idée d'unifier les apps iOS et macOS ?).

"Marzipan" fut peut-être, à un moment donné, au tout début, un nom de code utilisé, dit Gruber, mais ses informateurs en connaissent un autre, encore inconnu du public (qu'il a obtenu mais choisi de ne pas révéler pour le moment). Certains chez Apple connaissent le projet mais n'ont eu vent de ce nom de "Marzipan" qu'en lisant l'article de Bloomberg.

Sur la nature exacte de ce chantier, Gruber confesse n'avoir que peu d'informations. C'est aussi le flou général, sur le plan des détails techniques, de l'article initial de Bloomberg qui l'agaçait car il ouvrait toute grande la porte à toutes sortes de spéculations chez les développeurs :

Je n'ai pas énormément de détails, mais cela a tout l'air d'être une API déclarative qui permet de contrôler l'interface. L'idée générale est que plutôt que d'écrire du code procédural classique pour, disons, créer un bouton, puis configurer le bouton, puis positionner le bouton dans une vue, vous déclarez plutôt ce bouton puis tous ses attributs par un autre moyen. Le HTML est probablement l'exemple le plus simple pour le comprendre. En HTML, vous ne créez pas d'éléments tels que des paragraphes, des images et des tableaux, vous les déclarez avec des balises et des attributs. Il y a une tendance dans l'industrie à aller vers ce principe de la déclaration, peut-être est-ce mieux illustré par React, qui pourrait pousser Apple dans cette direction.

Ces « ragots » comme les surnomme Gruber, ne donnent pas d'indications complètes sur ce qu'Apple prépare sinon qu'un effort est mené pour faciliter la vie des développeurs tentés de basculer sur macOS des apps déjà existantes sur iOS et la partie interface est cruciale à ce titre.

Au vu de ce qu'il a glané, Gruber doute sérieusement que ce projet verra le jour lors de la prochaine WWDC de juin, ni même que cela était envisagé en décembre dernier, lorsque l'info est sortie pour la première fois.

Il mise sur 2019 avec macOS 10.15 et iOS 13. C'est par ailleurs cette version d'iOS qui devrait recevoir des changements d'interface importants (lire Apple va repousser plusieurs nouveautés pour se concentrer sur la fiabilité d'iOS) prévus à l'origine pour 2018.

avatar Quentin2106 | 

Ca va être sympa le Keynote de la WWDC cette année ?

avatar cecile_aelita | 

Au contraire ça me va parfaitement !!
Un ios12 ultra stabilisé et performant avec très peu de nouveauté visible (que je ferais une joie d'être mon dernier os pour mon 6S) et un ios13 barder de nouveautés qui va bugger à mort (et que j'éviterais comme la peste) ??
Comme ça tout le monde sera content !
Ceux qui veulent avoir un os qui marche resteront sur ios12 (un peu comme les LTS sur Linux ?) et ceux qui veulent juste faire les bêta testeur sur une version bugger iront sur ios 13?

avatar C1rc3@0rc | 

@romainB84

+1
Cook t'entende! des OS Apple LTS, le Graal attendu par... tout ceux qui ne sont pas des geek compulsifs.

En fait Apple et en chute libre depuis au moins Mac OS 10.10, voir 10.9 et iOS 7. Les fonctions gadgets se sont multipliées, pendant que la qualité, la stabilité, l'efficacité et la fonctionnalité s'effondrait.

Les OS sont devenus gros, gras, lourds, habillés d'atours a fanfreluches ridicules qui les rendent dysfonctionnels. Les materiels c'est pas mieux, tout ce qui est sorti depuis 2012 ou presque est un ratage.

L'actualité d'Apple sur ses OS ce sont les failles de securité et les bugs improbables toujours plus sortis d'epoque surannées que l'on pensait depassées.

Le pinacle de cette debandade c'est MacOS HS 10.13, une reference d'incuries et d'incongruence, osant un FS absurde de par son immaturité et imposé de manière outrageuse avec un recul magistral.
Mais l’écueil massif c'est iOS 11, l'OS emblématique du batterygate (même si techniquement c'est iOS 10 qui a introduit la fonction scélérate).

C'est que pour arriver a une telle catastrophe ça ne s'est pas fait en un jour et que le chaos a mis plus de 5 ans a prendre assez de vitesse pour s’abîmer contre le mur.
Apple a construits une serie d'echec tout azimut a la manier de Microsoft avec Vista.

Aujourd'hui les clients esperent un Windows 7, un OS stable, fiable, optimisé qui fait table rase de l'obsolescence programmée et assure que les applications tournent comme des horloges dans un espace de securité. C'est fou, mais le client - hormis le fanboy bien sur - attend juste un produit fonctionnel qui fasse ce que faisait iOS 6 ou MacOS Snow Leopard...

Quand l'avenir attendu c'est le passé, ça veut dire juste une chose: c'est qu'il faut reformer massivement la machine de production...

avatar Sgt. Pepper | 

Synchronisé sur les premiers Mac avec processeur ARM d’Apple ? ?

avatar jean_claude_duss | 

Sympa ça ! C’est sur que c’est ultra rapide de coder en réact (même si le JavaScript ....)

avatar Florent Morin | 

Les syntaxes sous forme de balises, ce serait une évolution de Interface Builder, qui repose déjà sur XML.
Après, Swift apporte une souplesse qui permettrait en effet de simplifier UIKit, pour gagner en lisibilité, comme cela a déjà été fait avec Autolayout.
Une forme de HTML qui génère du code : cela ressemble beaucoup à ce que propose Apple TV avec TVML et TVMLKit qui repose sur du JS.
Il vaut mieux ça que du React Native : c’est plus sécurisé, plus performant et surtout garanti sur la durée.
Mais la fusion des frameworks UI ressemble à autre chose. Apple explique déjà comment à l’heure actuelle on peut utiliser du code UI commun. Ce serait juste une forme d’aboutissement.

avatar melaure | 

@FloMo

Si l'aboutissement c'est la fusion des OS, c'est l'horreur au bout du chemin ...

Attention aux initiales, les non initiés ne sauront pas que tu parles du format JSON, et pire JS cela fait penser a Java Script ;)

avatar Florent Morin | 

@melaure

L’idée n’est pas la fusion des OS, mais la fusion de ce qu’ils ont en commun (80% du code pour Pages, Numbers, Keynote).

Plus j’y réfléchis, plus je vois un lien avec la compilation du JS sous forme de bitcode LLVM.

Et un autre lien : l’acquisition de SproutCore en framework web. On peut imaginer des apps JS « natives » avec version light en PWA. Et un code unique.

Cela suffirait à fermer la porte aux solutions hybrides dont le résultat pénalise au final la plateforme Apple.

avatar C1rc3@0rc | 

@FloMo

Moais, la chimere de l'interface declarative... vieux serpent de mer qui revient comme la TV 3D quand il manque de vent pour avancer.

La derniere evolution en terme de construction d'interface c'est... Interface builder sur NeXT et les polices vectorielles (mais ça c'etait plus ancien)

La prochaine evolution c'est une interface vectorielle. Parce qu'aujourd'hui faire une applicaiton iOS ça veut dire multiplier les images bitmap a gogo. Et encore, impossible d'etre certain du resultat avec la valse des formats d'ecrans et la salete de 18.9 de l'iPhone X ne fait qu'empirer les choses.

Ce qui fait peur c'est surtout les inepties comme justement les interfaces universelles declaratives. On a un bel exemple du mur qui est a se prendre avec Microsoft et son interface Metro: une seule interface pour tous les appareils... Une horreur cumulant les erreurs ergonomique et un echec massif qui est une des principales sources d'echec des Windows Phone.

Et pitié, assez de machines virtuelles et de massacres du Web.
Le Web c'est un ensemble de protocoles permettant de produire des documents hypertextes, pas un outils de developpement d'applications. Si on veut des applications on les programme pour la machine cliente et si besoin on les alimentent en données avec un serveur qui balance un format de donnees optimisées et chiffrées histoire arreter l'inflation de la graisse qui coule par les tuyaux.

Les saletes types Flash et plugin Java pour faire des immondices qui caviardent le poste client, on a donné, on s'en est debarassé, pas la peine de faire de JS un nouveau Flash. Pour rappel, la force du Web c'est de l'hypertexte indexable et rien d'autre!

JS sous forme de bytecode LLVM... mais pitié!
Les compilateurs JIT pour JS on en a atteint toutes les optimisations possibles avec le moteurs de Chrome et de Firefox. Ca bouffe de la ressource de maniere monstrueuse. Pour faire tourner le moindre petit truc hyper leger en langage compilé il faut des ressources de supercomputer avec du JS. Google travaille a en ameliorer la securité, mais la machine JS c'est toujours plus une autoroute a failles critiques exploitables souvent a distance.

Le JS c'est un langage de script primitif fait pour controler une valeur dans un formulaire et faire un effet visuel simpliste. Faut pas vouloir faire un avion de ligne avec une trottinette.

Developper une application client/serveur ça demande des competences d'une equipe, du temps et des ressources. Faire croire qu'avec un librairie grasse JS un graphiste va pouvoir construire un systeme d'information c'est un mensonge et rien d'autre.

Et produire une interface graphique pour une machines mobile tactile c'est un travail différent d'une interface pour un PC de bureau.
Alors qu'Apple rationalise ses API, les consolide, les assainisse, tres bien en y a besoin, mais une app iOS n'est pas une application de Mac et un site Web c'est pas une application...

avatar maatthieu (non vérifié) | 

Je suis pas vraiment d'accord sur le fait que le qu'un site web n'est pas une application. Gmail, la suite bureautique en ligne de Google ou meme celle d'Apple sont autant d'exemple montrant des vrais applications quasiment aussi réactive et completes que leur version "client lourd". D'ailleurs ma grande question est dois-je me spécialisé dans swift ou dans javascript...

avatar iDanny | 

@maatthieu

Ça c’est le constat actuel, mais c’est possible car on a des postes clients + puissants et des connexions internet + rapides qu’il y a 20 ans.
Mais c’est vrai qu’à l’époque, on n’imaginait pas qu’on ferait tout ça avec juste du JS, qui n’était pas « prévu pour » à la base.

Ça me rappelle un prof d’info qui refusait qu’on lui envoie des e-mails avec des pièces jointes (et autrement qu’en « plain text »), car ça n’était pas prévu dans les RFC initiales du format ?
Sacré lui, j’me demande ce qu’il devient tiens ?

avatar klouk1 | 

Je me demande comment vont réagir les éditeurs qui vendent une application 15 € sous iOS et la même sous osX 150€

avatar cecile_aelita | 

Il la vendront 150 pour le tout ?
Du coup personne n'achètera et ils passeront à du 15€ pour tout ?

avatar marenostrum | 

quelqu'un que je connais, il a fait un app gratuite mais limitée (pas en fonctions, mais en nombres de fiches crées) sur iOS, et complet sur macOS. il faut acheter la version complète pour macOS, pour libérer la version mobile (iPad, iPhone).

d'ailleurs il pensait au départ qu'Apple n'allait pas l'accepter sur leur store ce système.

avatar TrollMan06 | 

@marenostrum

C'est débile si la personne n'a pas de Mac. ?‍♂️

avatar marenostrum | 

s'il n'a pas de Mac ou Pc, donc d'ordinateur, il en a pas besoin de cette app, très spécifique. c'est un truc professionnel, la version mobile n'est que pour compléter. "travailler" en mobilité. avoir un oeil plutôt sur ce qui se passe dans ta basse de données, qui est faite pour travailler à plusieurs (bref en réseau).

mon exemple c'était en fait pour donner une réponse à la différence de prix, que c'est vrai va poser un problème à tous ceux qui s'adressent à une clientèle réduite. un app que tu le vends plus de 1000€ tu ne vas (ou peux) pas le proposer à App Store. même la différence entre 100 et 10 euro (entre boutiques) va poser problème à beaucoup de développeurs. ils peuvent pas vivre avec de tels prix bas, 5, 10€. ils doivent vendre par milliers pour rentabiliser, mais que leur secteur d'activités ne le permet pas.

avatar webHAL1 | 

@marenostrum
« Une app que tu le vends plus de 1000€ tu ne vas (ou peux) pas le proposer à App Store. même la différence entre 100 et 10 euro (entre boutiques) va poser problème à beaucoup de développeurs. ils peuvent pas vivre avec de tels prix bas, 5, 10€. ils doivent vendre par milliers pour rentabiliser, mais que leur secteur d'activités ne le permet pas. »

C'est malheureusement le mirage qu'essaye de vendre Apple (et d'autres) avec leurs boutiques : il suffit de vendre plus et moins cher. Sauf que bien souvent ça ne marche pas comme ça, puisque justement beaucoup d'applications n'intéresseront qu'une population réduite. Mais la "norme" devient de vendre à moins de $10. Au-delà, les gens disent que c'est beaucoup trop cher et que ça ne vaut pas le prix. Triste. :-/

Cordialement,

HAL1

avatar cecile_aelita | 

Ce que tu dis n’est pas complètement vrai.
Si la cible localisée est une niche alors c’est que généralement il s’agit de professionnels qui sont beaucoup moins frileux à dépenser plus pour une app (qui leur fera gagner plus)
La catégorie qui est la moins à même de sortir plus de 10€ (comme tu dis) ce sont les particulier qui eux sont beaucoup plus nombreux.
Ce système a ses limites évidement mais on voit bien que le freetoplay (que je ne cherche pas à défendre loin de la!!!) génère beaucoup plus de cash que des jeux à 15-20€ (mais évidement ça touche une grande cible ça c’est sur)

avatar webHAL1 | 

@romainB84
« [...] on voit bien que le freetoplay (que je ne cherche pas à défendre loin de la!!!) génère beaucoup plus de cash que des jeux à 15-20€ [...] »

Et c'est justement une illustration de ce que je dis, non ? Les clients sont très réticents à payer un prix de départ de plus de $10. Par contre, si c'est "gratuit", ils téléchargent sans souci, même si ensuite il faut passer à la caisse régulièrement. Mais cela fonctionne avec des jeux vidéo. C'est beaucoup plus compliqué pour une autre application.

avatar marenostrum | 

leur Store pose des problèmes à ceux qui veulent vendre cher, parce que leur secteur le permet. l'App Store nivelle les prix par le bas. c'est le Carrefour des logiciels.

Apple lui-même ne vend pas ses iPhone au Carrefour. ils ont fait leurs propres boutique pour en justifier les prix.

avatar Eurylaime | 

Apple a pris une licence pour XAML ? ^^

avatar C1rc3@0rc | 

@Eurylaime

Ils sont foutu d'avoir pompé XUL surtout...

avatar Jazzride | 

Le rêve de Cook va enfin se réaliser

1 seul appareil, l'iphone en 10 dimensions et capacité mémoire, le iphoneS le Iphone X le méga giant Iphone, le méga giant XXL iphone, IOS en deux déclinaisons IOS et IOSX " avec frites et coca"? Et tout dans le claoud, très important le claoud, avec sériesZ en mode binge-watching.Mais pas grave, si tu te fais du gras, ta ouatche appellera ton médecin à ta place mais n'oublie pas de la recharger.

bienvenue dans le monde moderne
Ou pourquoi 1984 ne ressemblera pas à 1984, Think (tank) different

CONNEXION UTILISATEUR