« Marzipan » : Apple veut-elle fusionner iOS et macOS ?

Anthony Nelzin-Santos |

Apple avait gardé le meilleur pour la fin de son traditionnel keynote d’ouverture de la WWDC : le framework UIKit, qui permet de construire des applications iOS et tvOS, sera bientôt disponible sur macOS. Les développeurs iOS pourront plus facilement porter leurs applications vers macOS, comme le montre d’ailleurs Apple elle-même, qui a porté plusieurs de ses applications d’une plateforme à l’autre.

La firme de Cupertino espère ainsi redynamiser l’écosystème logiciel du Mac, en berne depuis le lancement de l’App Store… et du Mac App Store. Pour le moment toutefois, Apple se réserve encore la primeur d’UIKit sur Mac, et se donne jusqu’à 2019 pour l’améliorer, avant de le confier aux développeurs. Un délai qui ne fait qu’accroître les interrogations, auxquelles nous vous proposons d’apporter quelques (pistes de) réponses.

« UIKit sur Mac », c’est le projet Marzipan ?

Apple n’a pas prononcé le mot «  marzipan  » pendant la WWDC. Cela étant dit, il ne fait aucun doute que « UIKit sur Mac » concrétise du projet Marzipan décrit par la rumeur, d’autant que l’on trouve des références à Marzipan dans le code de macOS Mojave. Apple n’a probablement aucun intérêt à désigner ce système sous un nom de code ou une marque commerciale : les développeurs connaissent UIKit, et comprennent parfaitement l’appellation descriptive « UIKit sur Mac ».

Mais au fait, c’est quoi AppKit et UIKit ?

AppKit et UIKit sont des frameworks applicatifs, autrement dit des infrastructures permettant de concevoir des applications. Ces frameworks forment la couche la plus haute du système, qui gère la manière dont les applications réagissent aux demandes du système et de l’utilisateur, qui permet — pour résumer de manière très grossière — de créer une interface dynamique.

Il s’agit donc, du point de vue du développeur tiers, de la brique la plus visible du système. AppKit est le framework applicatif de macOS, dont les racines remontent à NeXTSTEP, alors que UIKit est le framework applicatif d’iOS et ses dérivés, mis au point pour l’iPhone. C’est la principale différence entre les deux plateformes, qui possèdent sinon des bases communes.

macOS et iOS ont vraiment les mêmes bases ?

Oui… et non. Si l’on regarde le schéma fonctionnel des deux systèmes de loin, on voit apparaître les mêmes couches :

  • la couche de base : le noyau XNU combinant des éléments de BSD et Mach, le framework I/O Kit de création de pilotes, la couche réseau, les pilotes de systèmes de fichiers ;
  • puis Core OS : qui possède de nombreux composants permettant d’accéder aux ressources matérielles et de communiquer avec le réseau et les périphériques ;
  • puis Core Services : qui regroupe des services fondamentaux pour la création d’applications comme Foundation et Core Foundation, les différents systèmes de sécurité, le carnet d’adresses et les services de recherche, ou encore WebKit ;
  • puis la couche Media : qui contient toutes les API liées au multimédia, comme AV Foundation et Core Audio pour l’audio, Core Image pour les images, Core Animation pour les animations 2D et 3D, Core Text pour l’affichage du texte, et bien d’autres composants ;
  • et enfin la couche applicative : AppKit sur macOS, UIKit sur iOS, avec tous les systèmes associés, comme Spotlight et le Centre de notifications, les fonctions d’accessibilité, ou encore AppleScript.

En y regardant d’un peu plus près, on voit toutefois apparaître des différences sensibles, macOS et iOS ayant « dérivé » au fil du temps. Le projet Marzipan n’est que l’un des projets d’un énorme chantier entamé depuis quelques années, qui consiste à rapprocher progressivement les deux plateformes, pour revenir à un véritable coreOS commun.

La présentation d’UIKit pour Mac intervient à un moment clef : il n’a jamais été aussi facile de prendre une brique d’un système et de l’insérer dans la maçonnerie d’une autre, mais ce n’est pas encore simple. Nous sommes au beau milieu d’une transformation majeure des plateformes d’Apple, permise par la réorganisation des équipes de développement dirigées par Craig Federighi.

Est-ce que UIKit va remplacer AppKit ?

Les ingénieurs d’Apple l’ont dit haut et fort pendant les sessions de la WWDC : AppKit reste le framework par défaut de macOS. UIKit est une brique supplémentaire à disposition des développeurs, comme Metal pour les jeux ou WebKit pour le web, en somme. Le projet Marzipan vise à permettre aux développeurs iOS de porter rapidement leurs applications vers macOS, explique Apple, pas à remplacer AppKit. Du moins… pas à court terme.

Car les chiffres sont ce qu’ils sont : le Mac App Store compte moins de 30 000 applications, alors que l’App Store en compte plus d’un million. Pire : certaines des applications les plus populaires ne sont même pas des applications « natives », c’est-à-dire des applications utilisant AppKit, mais des applications web encapsulées avec Electron. Quelques-uns des développeurs les plus talentueux utilisent AppKit, mais on pourrait presque les compter sur les doigts d’une main.

Des applications macOS qui utilisent aujourd’hui Electron pourraient demain disparaître au profit de l’application iOS équivalente utilisant UIKit. Des applications iOS sans équivalent pourraient demain débarquer sur Mac (pensez à Netflix, qui pourrait sortir du navigateur, ou à Twitter, qui pourrait revenir par la fenêtre). Aujourd’hui, Apple ne veut probablement pas remplacer AppKit ; demain, les développeurs le remplaceront peut-être de facto.

Est-ce que les développeurs peuvent utiliser UIKit sur Mac dès aujourd’hui ?

Les développeurs ne peuvent pas encore utiliser UIKit sur Mac. Apple a déjà beaucoup travaillé sur UIKit, qui prend désormais en charge le pointeur, le redimensionnement des fenêtres en temps réel, les barres de défilement, les fenêtres de préférences, le copier-coller, le glisser-déposer, et d’autres éléments spécifiques à macOS. Mais elle doit encore beaucoup travailler : on ne peut pas redimensionner en temps réel la fenêtre de News, des éléments d’interface d’iOS qui n’ont aucun sens sur macOS apparaissent dans Bourse ou Dictaphone, et l’application Maison peine à afficher trois ampoules sur un écran 27 pouces.

Apple se réserve donc UIKit sur Mac jusqu’à l’an prochain, le temps de le tester à grande échelle avec macOS Mojave, et d’ajuster sa roadmap en fonction des retours des utilisateurs. Quelques bidouilleurs ont toutefois trouvé comment faire sauter les restrictions empêchant d’exploiter UIKit, et les développeurs les plus aventureux peuvent se faire la main en suivant les instructions que l’on peut trouver ici ou . Ils devront toutefois accepter de « sacrifier » une machine, puisque UIKit exige l’accélération graphique, que les machines virtuelles ne prennent pas en charge.

Est-ce qu’un développeur macOS a intérêt à adopter UIKit ?

C’est une bonne question, que nous avons d’ailleurs posée à plusieurs développeurs. Ont-ils intérêt à abandonner une base de code qu’ils connaissent par cœur et bichonnent depuis des décennies parfois ? Probablement pas. AppKit est un framework robuste, solide, éprouvé, et continuera de l’être. UIKit est déjà très prometteur, mais il a clairement été conçu pour porter des applications iOS, pas pour créer des applications macOS. Dans quelques années et après quelques révisions, toutefois…

Est-ce qu’un développeur macOS et iOS a intérêt à laisser tomber AppKit ?

C’est une autre bonne question, que nous avons aussi posée à plusieurs développeurs. Une société comme l’Omni Group s’est fait une spécialité de concevoir des applications tirant pleinement partie des capacités de l’iPhone et pleinement partie des capacités du Mac. OmniFocus pour iPad n’est pas plus ou moins pratique ou flexible qu’OmniFocus pour macOS, il est… différent. Omni préférera peut-être continuer à développer OmniFocus pour macOS, mais une société moins investie dans macOS, ou un développeur individuel, préféreront sans doute simplifier leur vie et remplacer leur application Mac par une application iPad.

À quoi bon acheter une app macOS en 2018 ?

À résoudre un problème qui se pose en 2018, pardi ! Si vous achetez des applications pour la beauté du geste, vous devriez probablement mettre le holà jusqu’à l’an prochain, ce qui ne devrait pas être d’une difficulté insurmontable. Mais si vous avez vraiment besoin d’une application, ne vous laissez pas distraire par l’existence du projet Marzipan. Apple n’abandonne pas AppKit, vos applications continueront à tourner pendant de nombreuses années, et ne seront peut-être jamais remplacées par des applications UIKit.

Cette question doit plutôt être renversée et adressée aux développeurs : faut-il se lancer, en 2018, dans la création d’une application AppKit ? Un développeur iOS sera probablement tenté de laisser passer quelques mois et attendre UIKit, un développeur macOS expérimenté préférera peut-être coder maintenant plutôt qu’apprendre UIKit pour plus tard. La situation ne se décantera pas avant l’année prochaine et l’annonce détaillée des capacités et des limites d’UIKit sur Mac.

Est-ce que UIKit sur Mac préfigure l’adoption des processeurs ARM ?

Beaucoup de commentateurs lient directement le projet Marzipan et les rumeurs autour de l’abandon des processeurs Intel au profit de processeurs ARM. Ces axes de développement ne sont pas complètement indépendants, mais l’un n’entraîne pas automatiquement l’autre. Disons-le clairement, pour lever les doutes qui pourraient subsister : un Mac à processeur ARM n’est pas nécessairement un Mac sous iOS, un Mac à processeur ARM n’est pas nécessairement un Mac avec un écran tactile, un Mac à processeur ARM n’est rien d’autre… qu’un Mac à processeur ARM.

Est-ce que ce n’est pas une fusion de facto d’iOS et de macOS ?

« Non », dit Apple. Partons du principe que les déclarations d’Apple sont cohérentes et sincères : on peut tout à fait imaginer que les plateformes se rapprochent sans fusionner. Dans quelques années, l’App Store sera peut-être la boutique commune à tous les appareils frappés d’une pomme, et l’on pourra peut-être utiliser l’iPad avec une souris. Une couche supplémentaire des systèmes sera partagée, la couche applicative, mais les systèmes eux-mêmes resteront différents.

Car Apple a toujours été très claire : différents usages appellent différents matériels utilisant différentes interfaces. L’unification passe par les services — tous les appareils communiquent de manière transparente, partagent les mêmes fichiers et les mêmes données, s’enrichissent les uns les autres plutôt qu’ils ne s’opposent.

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. Et vous savez quoi ? Apple sera très heureuse de vous vendre un iPhone pour tel usage et un Mac pour tel autre, plutôt qu’un tout-en-un prétendument adapté à tous les usages.

avatar Karamazow | 

Merci pour la qualité de cet article.

avatar Olivier Berard | 

Article de ouf comme d’hab 👌🏼 @macg. Vivement l’année prochaine.

avatar sambucus | 

Merci, cet article est particulièrement intéressant. La mise en complémentarité au lieu de la mise en opposition est un élément central qui fait la force d'Apple.

avatar bl@ck warrior_69 | 

J'ai une autre question : quelle est la différence avec UXKit, qui avait semble t il servi a créer l'app Photos sur Mac ?

avatar reborn | 

@bl@ck warrior_69

Peu-être le nom de la version en développement UIkit pour mac à l’époque chez Apple en interne

avatar C1rc3@0rc | 

@bl@ck warrior_69
«J'ai une autre question : quelle est la différence avec UXKit, qui avait semble t il servi a créer l'app Photos sur Mac ?»

Excellente remarque qui amene 3 elements de reponse et une question:
- Federighi a bien dit que UIKit sur Mac etait un projet de longue date (loin d'etre fini).
- Durant la conference et apres il n'a jamais ete question de Marzipan!
- Le "back to Mac" a deja ete evoqué lors des 3 precedentes WWDC et Keynote et de plus en plus...
- quel est le marché d'Apple et de ses développeurs ?

On constate que MacOS a ete delaissé depuis 2011 jusqu'a peu et que les evolutions se sont faites sur iOS pour ensuite etre "portées" sur MacOS.

Le plus gros morceau - avant UIKit - c'est la berezina APFS. Le "nouveau" systeme de gestion de fichier est surtout une unification des divers développements specifiques a iOS nécessaires pour optimiser la gestion de fichier dans un environnement de smartphone. Si a la base MacOS et iOS reposaient sur HFS+, MacOS a de son coté adopté plusieurs technologies pour compenser les manques de HFS+, sans modifier la couche HFS+. iOS est allé plus loin du aux necessités d'exploiter au mieux le SSD integré et d'optimiser des aspects comme les activations/mise en veille répétées ou encore le fait que les fichiers d'applications restent tout le temps ouverts...
On voit que tout cela a ete plutot bien integré sur iOS mais que c'est tres difficile sur MacOS. Ce n'est pas un hasard...

Pourquoi UIKit n'arrivera qu'en 2019, alors qu'UXKit est a l'oeuvre comme tu dis au moins depuis Photos le remplaçant d'iPhoto?
Une hypothese raisonnable c'est de penser qu'Apple avait voulu qu'UXKit devienne le remplaçant d'AppKit, mais que cette idee s'est confrontée a la realité des differences entre l'interface de MacOS et celle d'iOS.
Le projet a ete revu a la baisse pour faire d'UIKit pour MacOS plus un sous ensemble d'AppKit destiné a faciliter le portage des application iOS sur MacOS, mais pas d'aller au-dela.

Pour résumer le problème: l'ergonomie et les fonctionnalités de l'interface tactile d'iOS sont très différentes de celles possibles avec l'interface souris+fenetres de MacOS. Mais l'usage des plateforme est aussi très différent par nature.

iOS est par principe un OS mono-activités (attention pas mono tache, c'est bien un Unix donc multitaches).
La reussite d'iOS c'est justement cette capacité a restreindre l'usage d'une seule application active a un instant donné. On a bien vu des choses comme le "split screen" apparaitre, mais on est toujours pas dans un environnement multifenetrées avec 3 applications qui sont actives en meme temps.
Cela pour une bonne raison: la taille de l'ecran, le fait qu'il soit tactile et l'usage en mobilité.

A l'inverse MacOS repose sur le fait que plusieurs applications sont actives en meme temps et que leurs informations sont affichées dans plusieurs fenetres sur un grand ecran.

On peut résumer les choses:
- MacOS c'est un atelier avec tous les outils de production disponibles en permanence
- iOS c'est une bibliotheque, une TV, une console de jeux, un telephone... chacun disponible a son tour.

On peut aussi evoquer la precision du pilotage de l'interface avec un pointeur manipulé par une souris ou un trackpad et un clavier physique toujours disponible, a mettre en opposition a l'approximation du tactile et masquage d'une partie du petit ecran tactile.

Bref l'idée c'est pas de développer des applications qui fonctionneront indifféremment sur MacOS et iOS (ce qui etait l'idee et l'echec de Microsoft depuis Windoows 8), mais uniquement de faciliter le "portage" d'application iOS sur MacOS.

Il y a un point intéressant dans l'article, c'est la comparaison entre les 30 000 applications du MacApp Store face au million de l' iOS app store.
Si pour le Mac on voit de plus en plus d'applications primaires, gadget, monofenetres,... du style liste de course ou horloges que réalisent des débutants et des "programmeurs" iOS, la base de MacOS ce sont des applications de productivités riches avec des interfaces complexes (mais pas forcement compliquées).

iOS est une plateforme de consommation alors que MacOS c'est un univers de production de contenus.

Si on doit faire une application d'interface de service Web (genre messagerie) qui releve de la Web App, sur iOS on va utiliser un generateur d'application et sur MacOS un immondice comme Electron.

Par contre si on doit développer un outil de production original, il va falloir passer par AppKit et prendre le temps de la conception et realisation.

L'article pose l'hypothese du remplacement du penible Electron par des applications natives UIkit.
C'est une bonne probabilité, mais ça va dependre de la capacité d'Apple a empecher les generateurs d'applications sur iOS.
Si un webmaster avec une formation de graphiste va pouvoir faire une application iOS grace a un clicodrome assemblant du javascript, il n'y aura pas d'applications natives a porter sur MacOS.
La majorité des applications iOS ce sont des interfaces de service Web... ou des jeux. Les jeux sont majoritairement realisables avec des generateurs comme Unity.
Donc si Apple est coherent, on va voir une interdiction progressive des generateurs d'application et evacuation de choses comme Electron...

Maintenant la grosse interrogation c'est comment va faire Apple - si la volonté est la - pour motiver les développeurs a creer des applications pour le Mac, et pas juste donner des outils simples pour que les developpeurs iOS portent leurs applications conçues sur iOS sur le Mac.

Le 1er probleme c'est la rentabilité.
- iOS c'est 1.3 milliards de machines actives. MacOS quelques millions. Par an Apple vend 15 a 18 millions de Mac, alors qu'elle vend 260 millions d'iPhone et iPad.
- une app iOS se vend de 1 a 10 euros en general, avec un pic de vente sur la premiere semaine
- une app iOS type se developpe en quelques heures a quelques semaines, une application MacOS c'est plutot des mois.
- souvent une app iOS est "jetable", alors qu'une application MacOS implique une vie en annees avec un support attendu.

Developper une application pour Mac ça veut donc dire investir du temps pour un marché au minimum 10 fois plus petit qu'iOS, et avec une responsabilité de suivi qui peut ne pas exister sur iOS.
Pour que l'application MacOS soit rentable elle est forcement plus chere que l'application iOS (a l'achat ou reparti dans le temps).

Apple doit donc pérenniser le Mac, ramener des clients a forte valeurs (qui sont capables de payer cher une application sur le long terme), soutenir l'ecosysteme applicatif et faciliter la vie des developpeurs.

Cela passe d'abord par la production de Mac adaptés sur le long terme aux besoins de ces clientèles - majoritairement des professionnels productifs et créatifs - et a des tarifs concurrentiels.

L'autre element c'est la stabilité et le support la aussi a long terme.
Les API doivent devenir stables et pas changer tous les 4 matins ou necessiter qu'Apple bidouille les app pour assurer la compatibilité des principales parce que l'API a ete modifié a la hussarde.

Le support ça passe par la facilité de suivi entre le developpeur et le client, mais aussi par l'interaction avec une societe de services qui va pouvoir apporter une competence a l'utilisateur et interagir avec le developpeur.

L'autre grosse evolution necessaire c'est l'integration de l'opensource et l'opendata.
Aujourd'hui l'environnement Apple pose des probleme pour integrer du logiciel sous licences opensource, ce qui pose un tres gros probleme dans les secteurs professionels corporate, mais aussi dans le GP.

Finalement, reste le dernier probleme, celui de la distribution.
Le MacApp Store est une coquille de noix dans un ocean, il est bourré de lacunes, rend impossible le ciblage et suivi de la clientele,...
On voit qu'Apple a pris au moins conscience d'une partie du probleme et le fait enfin evoluer. Mais il y a encore beaucoup de boulot...

Bref, j'ai tendance a voir UIKit comme un recyclage d'UXKit, plus raisonnable et restreint dans ses pretentions. Mais il s'inscrit dans une necessaire reconception de l'ecosysteme d'Apple et surtout une reprise en compte du Mac.
Si Apple ne fait pas ce travail jusqu'au bout, la prochaine etape c'est d'ouvir le developpeement d'iOS aux plateformes Linux et Windows, ce qui signera alors la fin du Mac et de MacOS... ce qui pour Apple ne serait pas une mauvaise chose, car alors ils n'auraient qu'a se concentrer sur les iDevice a 100%.
Dans tous les cas, je ne crois pas du tout a une fusion de MacOS et iOS.

avatar Yacc | 

@C1rc3@0rc

« c'est la berezina APFS. »

Dans tes rêves sans doute 🙄🙄🙄

avatar reborn | 

@Yacc

À propos d’APFS, macOS est un environnement bien plus ouvert et moins controlé par Apple que iOS. N’importe qui de bonne foi aurait deviné pourquoi Apple l’a d’abord finalisé sur iOS avant de terminer le travail sous macOS.

Federighi a même expliquer qu’ils avaient en scred, testé APFS lors de la mise à jour iOS 10.2.1, puis ramené le tout en HFS+ et enfin envoyé les données de ces tests à Apple.

Oui c’est compliqué, car Apple se traine bien plus de legacy code sous macOS qu’iOS. 🤷‍♂️

C’est pas le résultat final qui le derange, c’est comment Apple y parvient. C’est ça qui le derange. Nous en tant qu’utilisateurs final cela ne nous regarde pas ces circonstances de développement 🤷‍♂️

avatar Yacc | 

@reborn

Les fixettes de Circé sont si nombreuses 🤤

avatar Yacc | 

@reborn

APFS connaît quelques soucis de jeunesse, mais pas plus que d’autres FS basées sur le concept de snapshot tel Btrfs ou ZFS.

APFS est sans doute aujourd’hui le FS snapshot déployé sur la plus large base installé est prétendre que c’est un échec majeur pour quelques problèmes marginaux ne fait qu’illustrer une nouvelle fois l’imbuvable posture de Circé 🤢

avatar Yacc | 

@C1rc3@0rc

Ce mélange de semi-vérités et de fantasmes rances 😳😳😳

Comment donner une impression de sérieux à de la mauvaise science fiction 🤢

avatar reborn | 

@C1rc3@0rc

J’ai pas tout lu 🤷‍♂️, t’y as passé la soirée ?

Durant la conference et apres il n'a jamais ete question de Marzipan!

Mince quand Apple a présenté l’iPhone en 2007 il n’a jamais était question de Purple et Purple 2 ! 😱😱😱

Tu crois qu’ils vont utilisé des noms de code de projets internes publiquement ?

tu prend les gens pour des cons..

Tout le reste comme d’habitude, n’est que suppositions basé sur les fruits de ton imagination.

avatar Yacc | 

@reborn

« Là tu prend les gens pour des cons.. « 

Pas juste là 😟

avatar reborn | 

Comment ça ? Genre ici aussi du coup ? 🤔🤔

https://www.igen.fr/ios/2018/06/ios-12-macos-mojave-airdrop-partage-les-...

Dorénavant ça sera M. FN, FN pour Fake News 😬

avatar Yacc | 

@reborn

Et comme d’habitude pas l’ombre du commencement de reconnaissance de son erreur 🤢

avatar C1rc3@0rc | 

«J’ai pas tout lu 🤷‍♂️, t’y as passé la soirée ?»
Dommage que tu n'ais pas tout lu ça m'a pris un quart d'heure a ecrire et parce que la remarque de @bl@ck warrior_69 etait vraiment intéressante et constructive et appelait un développement englobant l'ecosysteme Apple.

«Tu crois qu’ils vont utilisé des noms de code de projets internes publiquement ?»

Comme par exemple Snow Leopard, Yosemite,... Siera, HS, Mojave ?

Sinon, on etait sur une conférence développeurs, certes mais qui touchait un public plus large. La presse, blog, etc se sont entichés du "fameux projet Marzipan" qui sortait comme le dernier marronnier a la mode...
Tu m'accorderas que ça fait tres viral comme marketing et qu'Apple n'a jamais lésiné a utiliser des noms imagés pour beaucoup de tech - comme par exemple Carbon, Rosetta, Airplay...
Alors que le «fameux projet Marzipan» soit zappé pour se reduire a UIKit, successeur reduit de UXKit deja evoqué pour Photo, et que derrière ce terme pâtissier (très au goût en face) il n'y ait que UIkit...

«Là tu prend les gens pour des cons..»
Desolé si tu as ce sentiment, ce n'est pas le cas et - malgré la majorité de tes commentaires de type fanboy- je ne t'ai jamais insulté et j'ai même une considération pour ce que tu écris qui n'est pas systématiquement faux et ne constitue normalement pas des attaques de "bastoneux" primaires.

«Comment ça ? Genre ici aussi du coup ? 🤔🤔
/ios/2018/06/ios-12-macos-mojave-airdrop-partage-les-...Dorénavant ça sera M. FN, FN pour Fake News 😬»

Tu utilises dans ton commentaire l'argumentaire commercial d'Apple, tout en sachant tres bien que Airdrop a deja ete victime de failles et que le Wifi comme le Bluetooth sont des protocoles qui ne sont pas securisables, que ce soit entre machines ou via un routeur...
De plus tu réduis le champs a la dimension P2P et locale, qui ne constitue pas en soit une securité.

«M. FN»... vraiment? Je ne pensais pas que tu étais capable de tomber au niveau de l'insulte, surtout aussi bête.
J’espère que cette idée déplorable n'est que le résultat d'un état émotionnel passager et éphémère. Laisses ce type de comportement aux bastoneux sans cervelle.

avatar reborn | 

@C1rc3@0rc

Le problème avec toi c’est que si Apple n’agis pas comme tu l’entend c’est qu’il y a forcement un problème et que tu es donc dans le vrai.

Tu pense avoir raison en permanence, rien que ça c’est louche.

Désolé mais je n’accorde que peu de crédibilité aux gens comme toi.

Avec ton talent tu devrais pas être ici, tu ferais un excellent capitaine d’industrie. Tu sais tout sur tout, tu as la vision.

Qui sait, tu pourrais te retrouver à la tête d’Apple pour sauver cette société 😂

Émotionnellement je vais très bien, on ne peut pas en dire autant de ceux qui essaye d’avoir toujours raison.

avatar C1rc3@0rc | 

@reborn
«Tu crois qu’ils vont utilisé des noms de code de projets internes publiquement ?»

Comme par exemple Snow Leopard, Yosemite,... Siera, HS, Mojave ?

«Émotionnellement je vais très bien, on ne peut pas en dire autant de ceux qui essaye d’avoir toujours raison.»

Donc ta tentative d'ironie hors sujet - et surtout propos - et emplie de mepris sur la personne, cela pour ne pas reconnaître ton erreur fait de toi une personne qui n'essaye pas d'avoir toujours raison...
Comme ta derive sur le sarcasme amere posant un jugement de valeur aussi arbitraire qu'enonçant une generalisation des plus suspectes et abusives («aux gens comme toi»)...

Entendu: tu es une personne qui va bien émotionnellement. Plus de discussion donc.

avatar reborn | 

@C1rc3@0rc

Selon toi Apple DOIT obligatoirement utilisé ses noms de code interne publiquement. Sinon il y a anguille sous roche.

Ok 👍🏻😂🙄

Ce n’est ni une obligation, ni systématique, ni révélateur de quoi que ce soit.

Arrête avec tes délires 🤷‍♂️

avatar Un Type Vrai | 

Pour info, Snow Leopard, Yosemite,... Siera, HS, Mojave sont des noms commerciaux.
Ils font même partie du discours marketing tellement ils sont pensé pour le grand public et non comme nom de code.
Le nom de code, c'est Mac OS X.1, X.2, X.3 ...
Voilà la vérité.

avatar bl@ck warrior_69 | 

En fait même pas du tout, le nom de code d'un OS n'est utilisé que pour le développement. Pour Mojave, c'est Liberty, pour High Sierra, c'était Lobo, pour Sierra, Fuji, pour El Capitan, c'était Gala, et avant ça, Syrah...

avatar Yacc | 

@Un Type Vrai

« Voilà la vérité. »

Le nom de code d’un projet est à usage interne.

Tu confonds n° de version et nom de code.

avatar reborn | 

@Un Type Vrai

C’est subtil, je crois que macOS 10.0 ou 10.1 a vu son nom de code utilisé en nom commercial. Mais c’est a peu près tout et c’était en 2000- 2001..

Je pense pas que c’est arrivé par la suite..

Exemple l’iPhone 7 ne s’est pas appelé Dos Palos par exemple 🙄
https://www.igen.fr/iphone/2016/07/des-noms-de-code-pour-deux-iphone-7-9...

avatar Yacc | 
Modéré FI
avatar Yacc | 
Modéré FI

Pages

CONNEXION UTILISATEUR