macOS sera-t-il toujours compatible avec les processeurs Intel en 2025 ?

Christophe Laporte |

Tout laisse à penser qu’Apple lancera officiellement demain la grande transition vers une architecture ARM pour ses ordinateurs. Dans un premier temps, cela devrait être aux développeurs de jouer avant la commercialisation des premiers Mac ARM dans quelques mois.

Une telle transition est forcément délicate pour le constructeur. Une fois l’annonce faite, certains auront tendance à reporter leurs achats jusqu’à la sortie des premiers Mac ARM. À l’inverse, d’autres pour des raisons pratiques pourront avoir l’idée d’acheter un Mac plus tôt que prévu de manière à ne pas avoir à payer les pots cassés d’une énième migration. Reste que pour Apple, la situation est sans doute moins délicate que lors du passage à Intel. En effet, le Mac pèse aujourd’hui beaucoup moins lourd dans le chiffre d’affaires d’Apple qu’en 2005.

Si l’on regarde le calendrier de l’époque, la transition avait été menée à toute vitesse en regard de l’énorme chantier que cela représentait alors :

  • Juin 2005 : Apple annonce son intention de migrer vers les processeurs X86;
  • Janvier 2006 : Apple commercialise les premiers MacBook Pro 15” et iMac avec des processeurs Core Duo;
  • Février 2006 : le Mac mini fait lui aussi le grand saut;
  • Avril 2006 : le MacBook Pro 17” avec processeur Intel remplace le PowerBook 17”;
  • Mai 2006 : le MacBook 13” constitue le nouvel entrée de gamme pour les ordinateurs portables;
  • Août 2006 : l'ensemble de la gamme est passée sur architecture Intel avec l’arrivée des nouveaux Mac Pro et Xserve;
  • Octobre 2007 : sortie de Leopard qui sera la dernière version de Mac OS X à prendre en charge le PowerPC;
  • Août 2009 : sortie de Snow Leopard qui fonctionne uniquement sur architecture x86.

Comparaison n’est pas raison, mais Apple a bouclé l’ère PowerPC en tout juste quatre ans. Si la firme de Cupertino se montrait aussi dynamique dans sa nouvelle transition, cela signifierait que l’ensemble de la gamme serait passée sur ARM d’ici 2022 et que la dernière version de macOS à gérer les architectures X86 verrait le jour à l'horizon 2023/2024.

Les choses ont changé entre temps. Apple renouvèle moins fréquemment ses ordinateurs que par le passé. Et la durée de vie de ces derniers a fortement augmenté. Ainsi, macOS Catalina est parfaitement compatible avec des ordinateurs commercialisés en 2012.

L'autre grosse différence par rapport au passage à Intel, c’est la cadence de sortie des nouvelles versions de macOS. Depuis 2007, Apple propose une mise à jour majeure de macOS chaque année. Auparavant, on était davantage sur des cycles de 18/24 mois.

Idéalement, pour rassurer ses utilisateurs, il serait bien qu’Apple s’engage publiquement à supporter macOS sur x86 jusqu’à une date assez lointaine. Si elle ne le fait pas, les sempiternels arguments d'obsolescence programmée lui pendront au nez. Surtout que le contexte est peut-être moins porteur que lors du passage à Intel. A tort ou à raison, certains craignent que cette transition soit un pas en arrière notamment à cause d’une moins bonne prise en charge de Windows. Mais attendons de voir ce que nous réserve Apple pour avoir une idée sur tout cela !

avatar bhelden | 

Un Mac ARM signifie que toutes les applications iOS seront compatibles (d’une façon limitée au départ) avec macOS ? C’est ça le plus gros avantage en fait pour les développeurs et les users ?

avatar Tao | 

@bhelden

Non, les iPhone ont pas mal de particularités que le Mac n’a pas. Je pense à l’écran tactile, aux nombreux capteurs, etc. Les apps nécessiteront une adaptation pour un Mac. Mais c’est sûr que ça facilitera la transition cela dit

avatar bhelden | 

@Tao

Oui, c’est en cela que je précise « limitée au départ ».

avatar Rez2a | 

@bhelden

Non ça n’a pas de rapport. Les applications iOS peuvent être compilées pour Intel depuis le début, mais il a fallu attendre Catalyst pour qu’on puisse les porter sur macOS.

avatar bhelden | 

@Rez2a

Ok justement je me demandais si le mix Catalyst + puce ARM = iOSisation du Mac

Dans ce genre là...

Je m’exprime pas clairement mais pas grave.

avatar Rez2a | 

@bhelden

Disons que si Apple n’avait pas fait Catalyst, une appli iOS n’aurait pas pu être portée sur un Mac ARM. Je ne sais pas si c’est plus clair comme ça 😁

Il faut juste comprendre que les applis iOS peuvent être compilées pour Intel et ARM depuis le début, il a quand même fallu attendre qu’Apple sorte Catalyst avant de voir des portages.

Pourquoi elles pouvaient être compilées pour Intel depuis si longtemps ? Parceque les développeurs testent généralement leurs applis sur leur Mac (dans un simulateur d’iPhone) avant de les installer sur un vrai appareil ARM.

avatar Florent Morin | 

@Rez2a

Exactement. SwiftUI le permet aussi, mais ce n’était pas prévu si tôt.

À la base, c’était prêt pour la Watch uniquement. Puis ils ont testé sur les autres plateformes ce qui leur a permis de le sortir des 2019. Une sorte de coup de chance.

Catalyst a pris du retard. SwiftUI a pris de l’avance. Et voilà !

Il y a un véritable intérêt pour Apple à assurer une compatibilité maximale sur l’ensemble des plateformes cette année.
Indirectement, ça peut faciliter l’adoption du Mac ARM en gardant une compatibilité maximale avec les OS précédents.
Si les éditeurs peuvent vendre leurs logiciels sur les mêmes Mac que macOS Catalina, ils n’auront pas de scrupules à forcer la mise à jour. Et donc à adopter les nouvelles APIs. Et ainsi apporter la compatibilité Mac ARM.

avatar MarcMame | 

@bhelden

"Un Mac ARM signifie que toutes les applications iOS seront compatibles (d’une façon limitée au départ) avec macOS ? C’est ça le plus gros avantage en fait pour les développeurs et les users ?"

Si je voulais des app iOS sur un Mac, j’achèterai un iPad.

avatar Meaz | 

@MarcMame

+1

avatar bhelden | 

@MarcMame

Ça répond pas du tout à ma question mais merci de ta participation.

avatar Florent Morin | 

@bhelden

Théoriquement, toutes les apps utilisant du « bitcode » seront compatibles.

Plus d’infos :
https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

Le code d’une app peut déjà être très largement mutualisé entre iOS, iPadOS, watchOS et macOS.

Grosso-modo, les seules parties différentes aujourd’hui sont les spécificités de chaque plateforme : l’interface graphique et les composants systèmes.

Concernant l’interface graphique, Catalyst apporte la compatibilité iOS sur macOS. Et SwiftUI fait carrément code commun. Pour les jeux vidéos, Metal fait le job.

Pour la partie composants systèmes, une petite partie est commune.

Mais, si le code est commun, il faut encore concevoir 2 projets différents.

Avec une architecture ARM côté Mac, on pourrait potentiellement avoir des apps universelles. Et même des apps universelles compatibles ARM et x86. En une seule app.

Ce serait une révolution au-delà de l’écosystème Apple. C’est un idéal pour les développeurs qui était encore du domaine de la recherche fondamentale il y a moins de 20 ans.

avatar bhelden | 

@FloMo

Ah c’est bien ce qu’il me semblait ; que les puces ARM permettraient cette universalisation des apps (et donc possiblement que les apps iOS soient portées sur Mac avec des fonctionnalités supplémentaires appliquées style trackpad souris clique... + ajustement de la présentation... etc).

avatar Florent Morin | 

@bhelden

C’est déjà le cas aujourd’hui grâce à Catalyst. Mais ça permet d’aller plus loin.

avatar pocketjpaul | 

@FloMo

Un idéal déjà atteint depuis des décennies par la CLR de .Net et la JVM de Java qui sont toujours en pleine forme.

Ce qui serait révolutionnaire ce serait une couche UI vraiment multiplateforme. Mais sont ils prêts à nous laisser faire des jolies applis sur Android et Windows aussi ? Pour l’instant c’est Microsoft qui s’est lancé seul dans la course d’une seule codebase pour toutes les plateformes possibles. Et ils vont vite.

avatar Florent Morin | 

@pocketjpaul

la CLR de .Net et la JVM de Java utilisent du bytecode. Il est interprété à la volée.

LLVM s’appuie sur du bitcode, qui est bas niveau. Le niveau d’optimisation est supérieur.

C’est d’ailleurs pour ça que Google veut adopter LLVM en remplaçant de la JVM dans le futur Android. Et Kotlin Native est la version LLVM de Kotlin.

avatar byte_order | 

@FloMo
> Ce serait une révolution au-delà de l’écosystème Apple.

Je vois mal comment, vu que tout cela dépend d'API qui ne sont disponible que sur les plateforme d'Apple.

avatar Florent Morin | 

@byte_order

L’exemple parfait est Swift, qui est open-source, et peut être compilé sur PC (bientôt Windows), Raspberry Pi, etc. On peut avoir un code serveur optimisé pour chaque plateforme.

Hors serveur, c’est limité à de la ligne de commande. C’est un usage marginal aujourd’hui.

Mais une compatibilité WASM est déjà en place. Elle vient d’intégrer le projet Swift.

À terme, on peut imaginer par exemple un seul code de chiffrement de bout en bout en Swift pour macOS, iOS, JavaScript (via WASM), Windows, Android, Linux. Et compatible ARM ou x86 indifféremment. Tout en profitant du meilleur niveau possible d’optimisation matérielle.

En allant (beaucoup) plus loin, un code SwiftUI pourrait potentiellement s’adapter à Windows, Linux et le web.
En respect des guidelines de chaque plateforme. Et en s’adaptant aux niveaux API non graphiques.

C’est un travail d’une décennie. Mais quand Apple s’est intéressé à LLVM, l’approche machine virtuelle de bas niveau était de la science fondamentale, un doux rêve d’idéalistes. Aujourd’hui, et grâce au travail de tous (Apple, Google, universités), on y est.

Ça laisse de bonnes perspectives pour l’avenir. 😁

avatar Mrleblanc101 | 

@bhelden

Bien sur que non. Les apps iOS sont pensée pour le tactile et beaucoup ne supporte même pas le redimensionnement sur iPad alors elle serait complètement inutilisable sur Mac. Seul les app catalyst font du sens sur Mac si Apple continue d'améliorer le moteur

avatar switch | 

"Idéalement, pour rassurer ses utilisateurs, il serait bien qu’Apple s’engage publiquement à supporter macOS sur x86 jusqu’à une date assez lointaine."
- Peut-être aurons nous une réponse lors de la WWDC, mais ne rêvons pas trop de voir Apple s'engager sur ce point.

avatar JOHN³ | 

@switch

La conscience écolo a bien évolué depuis 15 ans, et Apple aussi sur ce point.

avatar MarcMame | 

@JOHN³

"La conscience écolo a bien évolué depuis 15 ans, et Apple aussi sur ce point."

L’écologie est une conséquence de l’obsolescence, pas sa raison d’être.

avatar JOHN³ | 

@MarcMame

J’aurais plus dit la surconsommation de masse. Mais si tu le dis...

avatar pagaupa | 

@JOHN³

« La conscience écolo a bien évolué depuis 15 ans, et Apple aussi sur ce point. »
😂😂😂😂😂😂

avatar armandgz123 | 

@JOHN³

😂😂😂😂 en lançant et en favorisant les AirPods ? Entre autres

avatar JOHN³ | 

@armandgz123

On parle de quoi exactement ? De la durée de vie des ordinateurs

Les AirPods sont en effet une catastrophe écologique; tu ne m’apprends rien

Pages

CONNEXION UTILISATEUR