Un aperçu des apps iOS sur le DTK
Sur les Mac dotés de puces Apple Silicon, macOS Big Sur sera en mesure de faire fonctionner les applications iOS et iPadOS quasiment comme s'il s'agissait de logiciels macOS. De quoi enrichir à bon compte la logithèque de ces futures machines, qui pourront aussi exploiter des logiciels Mac Intel grâce à Rosetta 2. En bon bidouilleur qu'il est, Steve Troughton-Smith a pu faire fonctionner sur son DTK des apps iPhone et iPad, à partir des binaires provenant d'une tablette jailbreakée.
Steve explique qu'un certain nombre de comportements s'appliquent d'emblée aux applications iOS pour fonctionner « nativement » sur Big Sur. D'anciens frameworks qui manquaient à l'appel dans macOS ont été réintégrés, ce qui permet de redimensionner les fenêtres des apps.
Une application iPad pourra ainsi s'afficher sous son format portrait ou paysage. Les applications qui prennent en charge les différents formats Split View pourront être redimensionnées à la discrétion de l'utilisateur, mais gare à l'interface qui — à l'heure actuelle en tout cas — risque de faire déborder des éléments graphiques, comme c'est le cas d'Overcast ci-dessus. Les apps iPhone se présentent plein pot et Big Sur prend en charge les gestes multitouch.
@FloMo
AND*
@anonx
On s’en fout d’utiliser un sigle français ou anglais tant que les gens comprennent.
A partir du moment ou la protection de la langue se heurte à la compréhension c’est un combat perdu d’avance.
Non.
mais oui c'est perdu d'avance
mais Non quand même ;)
@anonx
LOL
Étonnant de bidouiller ouvertement ce nouvel OS 🤔
Il n’y a que les Mac Apple Silicon qui pourront faire tourner les app iOS? Je pensais que ça tournerait sur tous les Mac compatibles macOS 11.. :-/
@redchou
C’est le changement d’architecture du processeur qui permet cette fonctionnalité, pas le changement d’OS.
Donc effectivement, il faudra un Mac ARM. macOS Big Sur ne suffira pas.
@minipapy
On pourrait se dire... Un Rosetta2 inverse et hop...😬😎
@dorninem
Rosetta2 est une solution temporaire destinée à simplifier la transition du x86 vers ARM pour les utilisateurs. Elle n’a pas vocation à perdurer dans le temps, comme son prédécesseur.
Néanmoins, dans l’absolu, on peut déjà faire tourner une application iOS sur un Mac Intel... avec le simulateur iOS fourni avec XCode. 🙂
@minipapy
Enfin le simulateur il consomme pas mal de puissance, sachant que les puces Intel sont plutôt faiblarde comparé aux processeurs intégrés dans iOS je suis donc pas sur que dans ce sens ce soit le bon plan.
@fousfous
Je ne pense pas que la puces Intel soit la seule cause de lenteur mais bien plus les framework de l’os emulé utilisés par les applications, si ceux ci étaient en code archi proc natif le résultat serait sans doute différent. Et justement BigSur intègre des fw iOS dans MacOS.
Généralement une émulation archi CISC vers RISC c’est plus performant que dans l’autre sens. 🙃
@fousfous
C’était plus pour dire que, techniquement, des apps iOS tournent déjà sur Mac Intel. Mais effectivement, ce n’est pas franchement exploitable en dehors des phases de développement.
Par processeur iOS, j’imagine que tu parles des CPUs Ax ? x86 et les puces développées par Apple étant très différentes, il est difficile de les comparer sur le strict plan des performances. Mais oui, Apple semble confiante et l’approche prometteuse. J’ai hâte de voir ce que vont donner les premiers Macs sur CPUs ARM.
@minipapy
Oui et non. Les apps qui tournent sur le simulateur sont compilées pour l’architecture du Mac, donc Intel jusqu’à présent. Il n’y a pas du tout d’émulation ARM.
@Ali Baba
Effectivement, j’ai été un peu vite en besogne et fait un raccourci un peu trompeur entre iOS=ARM et macOS=x86.
D’ailleurs, Catalyst est un autre moyen de faire tourner une application iOS sur macOS... mais pas dans sa version ARM.
@dorninem
Le roseta 2 inverse ... c’est le projet catalyst 😉
@romainB84
Aucun lien entre un roseta ( même inverse ) et Catalyst.
Roseta : tu prends un binaire x86 et tu l’exécutes sur un Mac ARM. Ou l’inverse. Le développeur de l’application n’intervient pas.
Catalyst : le dev porte son application iOS sur un Mac Intel. Il doit modifier ces sources.
@hirtrey
BUT / RÔLE de :
Roseta : faire tourner une application x86/pour Proc Intel sur un processeur arm.
Roseta inverse : faire tourner une application iPad/pour proc arm sur processeur x86/Intel.
Projet catalyst : adapter une application iPad/pour proc arm sur un processeur x86/Intel.
Tu le vois mieux le lien dit comme ça 😉? Je te l’accorde, si j’avais pu faire un tableau ça aurait été encore plus lisible ! Mais on peut pas le faire sur macg 🥺... désolé !
@romainB84
Dis toi que des personnes qui ne sont pas dans l’informatique vont lire ton message et se dire que c’est la même chose suite à ton premier commentaire car il n’ont aucune notion.
Tu vois la différence entre bien expliquer et faire des raccourcis.
@hirtrey
Oui monsieur 👍
Désolé de vous avoir importuné !!
Mais, je ne vous envie pas lol, ça ne doit pas être simple de passer les portes tous les jours quand même 🤣
@romainB84
De mon point de vue ça n’a pas de rapport.
Rosetta : faire tourner une appli x86 sur un ARM
Rosetta « inverse » : faire tourner une appli ARM sur un x86
Catalyst : faire tourner une appli iPadOS sur macOS
En fait c’est uniquement Catalyst qui est important ici, puisque c’est lui qui permet d’exécuter une appli iOS sur un Mac.
Si les applis iOS vont pouvoir tourner uniquement sur les Mac ARM, c’est simplement parceque les applis iOS distribuées sur l’App Store sont compilées pour ARM, donc un Mac Intel ne saurait pas les exécuter.
Si le « Rosetta inverse » existait, à ce moment-là il serait possible d’utiliser des applis iOS ARM venant de l’App Store sur des Mac Intel.
Mais en fait, Catalyst n’a pas vraiment de rapport avec l’architecture et ne joue pas le rôle d’un Rosetta inverse.
Lorsqu’on utilise Catalyst aujourd’hui pour porter une appli iPad sur Mac, c’est effectivement une appli x86 qui sort (puisqu’elle doit tourner sur Intel), mais ça c’est indépendant de Catalyst, c’est Xcode qui sort un exécutable de la bonne architecture en fonction de la cible. Ça fait depuis le tout début qu’on est capable de sortir des applis iOS pour x86, il n’a pas fallu attendre Catalyst pour ça. Par contre, l’app store iOS ne sait distribuer que des applis ARM.
@romainB84
oui pour un utilisateur final, la différence est presque sémantique et ne devrait pas le concerner.
PAR CONTRE, pour un professionnel, un Oomu et aussi les gens qui veulent savoir ce qui se passe, c'est très important
c'est même fondamental : les approches sont différentes, ça un impact majeur sur la performance et le travail à fournir en amont.
Et ici on est un forum plutôt technique, de niche (on parle grosso-mode que d'UNE entreprise, alors qu'on pourrait parler de tous les legos, nestlés, softbank, toyota et louis vuiton de la planète)
de fait, niche + technique, on peut comprendre que l'exactitude ou en savoir plus sur le fond des choses intéressent, voir concernent, vos interlocuteurs.
Exemple, si vous aviez tenu devant moi, en milieu professionnel, un tel discours, je vous aurais mé-pri-sé. Mais je suis quelqu'un de foncièrement méprisant ET méprisable :)
Donc si des interlocuteurs vous rudoient il faut aussi comprendre que votre propre propos est aussi radical. Il n'est pas si anecdotique ou innocent que cela: vous dites quelque chose de profond, qui est "oh mais on s'en fout de cet aspect technique :)"
ce qui amène une contre réponse : "ben non on s'en fout po ! :( "
pas bien méchant tout ça. et c'est cool ! vive la technologie et les forums oranges.
Non cette phrase n’est pas correcte :
« Projet catalyst : adapter une application iPad/pour proc arm sur un processeur x86/Intel »
Catalyst n’est pas lié au type de proc, et reste d’ailleurs d’actualité pour porter des applications iPad OS ARM vers Mac ARM
Voilà pourquoi MacOs ressemble à iPadOS avec ses gros boutons : ce n’est pas pour faire des Mac tactiles (coucou ORLM !), mais pour harmoniser l’interface du Mac quand l’utilisateur utilisera des app venues de l’iPad.
Et l’arrivée des app iPad sur Mac sont une excellente nouvelle pour l’iPad : les développeurs pourront travailler sur une version unique en apportant les fonctionnalités qui manquaient aux app iPad.
Avec les puces Silicon, on peut imaginer utiliser Lumafusion sur l’iPad et faire un rendu sur le Mac pour gagner du temps.
@ludmer67
Oui on va avoir des apps iPad adapté uniquement pour être utilisé au stylet ou sur le bureau avec une souris...
Le rêve de la tablette qu'on utilise dans le canapé s'est bien fait détruire quand même.
@ludmer67
je n’enterrerais pas le mac tactile si vite :P
@raoolito
En 2010, lors de la présentation de Lion, Steve Jobs était clair : un ordinateur portable tactile est super pour des démonstrations, pas pour une utilisation au quotidien, d’où le trackpad Multi-Touch.
@ludmer67
Et en 2007 lors de la présentation de l'iPhone il a dit qu'il ne voulait pas de stylet. Et pourtant... 🤷♂️
@bl@ck warrior_69
Toujours pas de stylet sur l’iPhone, je vois pas le rapport
@bl@ck warrior_69
Je savais qu’elle arriverait : il n’y a pas de stylet sur l’iPhone. Apple n’a pas contredit ce que Jobs disait en présentant l’iPhone.
il n'y apas de stylet pour iphone par apple
Steve Jobs a été clair : "pas de stylet pour naviguer l'appareil comme sur les vieux pocket pc et palm YURRK"
ce qu'Apple a fait ,c 'est un "CRAYON" : pensé et vendu comme outil de DESSIN.
mais PAS comme alternative au doigt pour utiliser son iphone comme un antique Pocket PC sous windows CE (j'en ai utilisé, c'était YURRRK !)
voyez la différence ?
alors vous dites "boah, faribole de mauvaise foi, tu prends ton 'crayoneuh' et c'est un stylet !" sauf que non, en pratique iOS n'est vraiment pas pensé pour être manipulé entièrement avec un curseur représenté par la pointe d'un bâton
et très souvent sur ipad, y a une séparation stricte entre le crayon déclenche de "dessiner" et les doigts pour l'interface.
Bref, ios n'est toujours pas un os qui s'utilise avec un "stylet" (yuRRRk)
J'utilise tous les jours une surface pro et l'écran tactile est loin d'être inutile en configuration avec le clavier attaché. Je l'utilise régulièrement, même si moins souvent que le trackpad effectivement :
- scroller dans une fenêtre ou un pdf,
- appuyer sur des gros boutons (comme "envoyer" pour valider ce message),
- naviguer sur une carte google maps,
- pour utiliser la calculatrice !
- griffonner vite fait une note sur l'écran quand on est au téléphone,
Et pourtant dieu sait que W10 n'est pas l'idéal pour le tactile. Mais parfois, c'est bien pratique.
Mais ceci étant dit, je doute qu'un Mac tactile arrive. C'est le boulot des ipad de proposer cette expérience.
@ludmer67
il disait aussi qu’il fallait etre capable de se renier soit-meme si on estimait apres un certain temps qu’on etait dans la mauvaise direction :)
Mais quel intérêt de faire tourner une appli iOS sur Mac ? Les apps sont pensées différemment pour le desktop et le mobile, car ... ce sont des environnements très différents !
Je pense qu'à partir de maintenant, les devs devront créer des apps pensées à la fois pour l'iPad et pour le mac. Avec le risque d'être ni bien adapté à l'un ni à l'autre.
J'espère qu'uniquement ces nouvelles app seront autorisées sur le mac app store et pas les vieilles app iPad. Ça serait effectivement un non sens. Et les app iPhone, je n'en parle même pas.
j'utilise déjà une app sur trois plateformes, ou appareils, iMac, iPad et iPhone. l'interface seulement doit s'adapter, pas l'usage. ça reste le même.
@outmen
Comme c’est au concepteur de l’app de mettre la compatibilité, on peut imaginer que ces dev savent ce qu’ils font s’ils « cochent » la case, que l’app est, ou n’est pas, pertinente sur macOS.
Manque plus qu’un mac tactile 😜
Vous allez voir, tout les usages cool comme Google Maps hors ligne, Netflix seront impossible, tout ses grandes entreprises seront hostiles si l'adaption n'est pas forte d'emblée. Ils ne pourront plus tracker ou forcer à être en ligne, une terreur pour Google
@MugiwaraLuffy
ah oui aussi
meme si une app youtube sur mac je ne serais pas contre...
J’aime pas trop le système de apps éparpillées pour tout et rien. Un gros avantage du web est la présence de l’historique qui permet de tout retrouver par dates et mots clés. Sur iphone c’est casse pied et complètement hasardeux de retrouver un article, une vidéo ou n’importe quoi vu auparavant dans une app. À moins qu’Apple ajoute dans le futur un historique centralisé mais ça m’étonnerait.
hmm, c'est assez ambitieux en fait
Reste à voir jusqu'où les approches déclaratives et les interfaces qui s'adaptent permettent d'aller et si vraiment on peut réussir à maintenir une excellente (pas une "bonne", une _excellente_) convivialité dans chaque cas.
Je ne pense pas que ça soit possible
mais l'aventure est excitante
et j'aimerais avoir tort au final.
bref: intéressant.
« Un aperçu des apps iOS sur le DTK »
C'est quoi le DTK ?
https://www.macg.co/materiel/2020/06/arm-apple-doit-elle-vraiment-proposer-un-developer-kit-114719