Apps : le projet Marzipan toujours prévu pour 2018

Cool, Candy Crush sur mac…

Cool ! Y a de nombreuses applications que j'aimerais avoir sur le Mac

Quelqu’un peut-il m’eclairer sur le rôle des processeurs là-dessous ? J’ai toujours cru qu’un logiciel fait pour une architecture particulière ne pouvait pas être lancé sur une autre .

@Dxayn : Je veux bien tenter le coup. Je n'ai rien lu sur Marzipan en particulier, donc je réponds de manière très générale.

Si le code est compilé en langage machine, effectivement, il n'y a pas moyen de le faire tourner sur une autre machine à moins d'utiliser un émulateur. Difficile d'imaginer un émulateur sur les iBidules, donc s'il y en a un ce serait sur Mac. Et les émulateurs ont quand même fait pas mal de progrès (et de plus avec la puissance inutilisée dans les macs, il y a de quoi voir venir).

Mais ... Xcode, qui est l'interface de programmation permet aussi bien de créer un projet pour iOS que pour macOS. Donc rien n'empêcherait de compiler deux fois le programme et donc d'avoir les deux exécutables, un pour iOS (processeur ARM) et un pour macOS (processeur x86).

Une autre alternative serait de créer une application qui tourne dans une sorte de machine virtuelle, comme le code Java par exemple (pas les java-scritpt). Dans ce cas, le code généré est un pseudo-code et c'est la machine virtuelle qui l'interprète sur la machine hôte.

Je ne sais pas ce qui est retenu pour Marzipan comme approche, par contre la où macOS est "multifenêtre", iOS est (ou en tout cas, était) mono-fenêtre. Donc, a priori, j'ai tendance à penser que les applis portées seront "plus simplistes" que des applis macOS.

Evidemment, les développeurs qui opteront pour cette approche n'auront pas le choix et devront vendre leur appli via le store ...

Néanmoins, la où c'est une bonne nouvelle, c'est que ça va "redynamiser" le contenu sur Mac et lutter contre le problème des parts de marché (Apple stagne à 8% depuis au moins 2012 contre un peu plus de 90% pour Windows).

Déjà que les apps iPhone/iPad ne sont pas toujours adaptées aux deux formats (je pense notamment à Spotify sur iPad qui n'est qu'une version élargie de l'app iPhone), alors une app commune à un iPad ou iPhone à écran tactile et à un Mac avec trackpad, je ne vois pas comment l'utilisabilité peut être convenable sur les deux plates-formes, sauf pour les développeurs vraiment consciencieux.
Cela dit, ça pourra toujours servir pour un usage d'appoint, et combler le manque total d'une app sur macOS.

« Si le code est compilé en langage machine (...) Difficile d'imaginer un émulateur sur les iBidules, donc s'il y en a un ce serait sur Mac »
Tu dis donc que l’on pourrait émuler une app iOS sur Mac mais pas l’inverse ; c’est ça ?

« Mais ... Xcode » qui permet de créer 2 apps qui ne sont pas trop différentes (sauf interfaces) avec le même code (ou presque). Je pense avoir compris.

« avec la puissance inutilisée dans les macs, il y a de quoi voir venir » « Une autre alternative serait de créer une application qui tourne dans une sorte de machine virtuelle ». Il y a de quoi voir venir mais seulement sur les appareils « récents » , quid des appareils plus anciens ? Cette dernière solution que tu m’exposes, est-elle réellement viable sur l’ensemble des machines encore utilisées ?

J’espere avoir bien compris, en tout cas, merci

Et un Mac ARM ? (oui j'y crois !) Ca serait la solution au problème d'architecture CPU.

@Dxayn : on peut émuler ce qu'on veut sur ce qu'on veut, mais c'est plus logique que ce soit la "grosse" machine qui émule la "petite", pour des questions de ressources. Mais de toutes façons, c'est tellement simple de compiler pour deux cibles différentes (ou plus) que c'est la solution de loin la plus logique.

Comme l'écrit Pehache, c'est effectivement une question de ressources, tant CPU qu'autonomie mais aussi d'espace "disque" puisqu'un émulateur prend de la place et doit être intégré dans l'OS.

Un développeur peut toujours créer une version spécifique pour Mac si le besoin s'en fait sentir.

Ici, il s'agit juste de proposer un portage à moindre coûts pour tout le monde* et ces petits outils tourneront tant sur des iBidules plus anciens que sur des Macs mêmes anciens. Car la puissance et la résilience est à mon sens inégalable dans des petits volumes.

* : mais je pense que ceux qui y perdront ce sont les développeurs d'applications pour Mac qui vont voir une déferlante d'appli à des prix cassés surgir sur le marché.

Et ce projet sera grandement facilité avec ce qui a été introduit en juin 2015 : le « bitcode ».

Désormais, quand on crée une app pour iOS il est activé par défaut (on peut bien sûr le désactiver). Si on soumet une app comprenant ce bitcode à Apple, Apple peut en théorie « recompiler » l’app vers n’importe quelle architecture supportée. L’intérêt évoqué à l’époque était de pouvoir rendre compatible « nativement » une vieille app sur une nouvelle archi sans avoir à gérer une sorte de mode de compatibilité.

Reste à Apple à traduire le SDK iOS pour macOS, pas une mince affaire.

De toute façon quand on voit la qualité des apps iOS aujourd’hui (les jeux vidéos entre autre), Apple serait bien inspirée d’intégrer du hardware ARM au lieu des carte graphiques anémiques (surtout au regard des prix de vente pratiqués).
Au moins macOS profiterait de la logithèque iOS sans problèmes.
Les devs fuient de plus en plus macOS ...

Jouer à un jeu iOS, prévu pour une interface tactile (et parfois en utilisant le gyroscope etc...), sur un Mac qui en dépourvu, ça ma parait tout sauf pertinent.

@pehache :
De nombreux jeux iOS acceptent la connexion d’un pad en Bluetooth.