macOS Monterey n’aime déjà plus les anciennes versions de Xcode
Jusqu’à la bêta 7 de macOS Monterey, il était possible de lancer d’anciennes versions de Xcode. Mais depuis le 21 septembre, c’est officiellement terminé, et c’est un micro-drame au sein de la communauté des développeurs.
Beaucoup de concepteurs d’apps attendent en effet le tout dernier moment avant de passer à la dernière version de Xcode et du SDK iOS. Les versions bêtas s’enchaînent généralement tout au long de l’été. À l’automne, la version stable est disponible pour tous et c’est habituellement seulement au printemps suivant que le nouveau SDK devient indispensable pour pouvoir publier sur l’App Store.
Pendant ces six mois de trêve hivernale, les développeurs peuvent repousser sereinement le problème en travaillant avec une ancienne version de Xcode au sein d’un macOS de dernière génération. Alors forcément, quand Apple annonce qu’il faudra passer par Xcode 13 sous macOS Monterey dès le départ, c’est la panique.
Cette situation est problématique dans deux scénarios :
- un nouveau développeur dans une équipe aura probablement déjà son matériel équipé du dernier macOS ;
- un développeur qui vient d’acheter un nouveau Mac disposera automatiquement de la dernière version du système.
Pour le premier scénario, Apple propose une solution qui nécessite tout de même d’avoir un disque dur de capacité suffisante : il s’agit de créer une partition supplémentaire et d’y installer Big Sur.
Mais quelle est la solution dans le cas d’un nouveau matériel qui ne sera probablement pas reconnu par Big Sur ? Il faut lancer Xcode en ligne de commande. Dans un terminal, exécuter /Applications/Xcode-12.5.1.app/Contents/MacOS/Xcode devrait faire l’affaire. Cette solution fonctionne plus ou moins. Dans mon cas, le simulateur iOS n’a pas réussi à travailler en binôme avec Xcode.
Finalement, la meilleure solution est probablement de se retrousser les manches et rattraper sa dette technique sans attendre le dernier moment.
C'est habituel comme comportement ? Parce que lier l'utilisation d'un IDE à une version particulière d'un OS c'est un concept assez tordu.
SURPRISE..... en sus sur des Mac de + de 5 ans : plus de màj système....... macOS Monterey indisponible... conséquence...... Mon MacBook Pro 2014 - 16 Go - 512 Gb - 2 Go mémoire vidéo dédié nvidia 750, payé 2500 euros en 2015......... autrement dit une machine encore très puissante, trop même pour du dev....... serait donc bonne pour la benne selon Apple. Certains ici vous dirons qu'Apple (une boite qui pèse le PIB de France en bourse) ne peut pas éternellement maintenir son OS sur 3 config sorties/an, là où la concurrence :
Mon HP Probook... payé 430 euros en 2011.... lui peut toujours lancer la dernière version de Visual Studio sous Windows 10, et plutôt très bien avec le SSD à 50 euros que je lui ai installé....
Bref, cette boite de merde, qui se pare de tout de vert quand il s'agit de nous parler de recyclage de ces machine de merde, n'est la que pour prélever une taxe sur l'informatique. Elle a elle même popularisé le tout collé / soudé / OS verrouiller / non upgradable / batterie niqué en 8 mois / cables Lightning qui se déchire (plastique de mauvaise qualité : le même depuis 15 ans qui lui a valu une class action sur les MagSafe de l'époque) / obsolence programmé en mode on diminue les perf sur les iPhone / taxe de 30% sur les app.............. bref Apple ne va pas pouvoir se foutre de ces clients éternellement.... et pourtant on a bel et bien l'impression qu'elle tient le consommateur par les couilles juste avec l'interface édulcoré de son système....
@nicopulse
Je partage.
D'autant plus que ma machine principale (la seule), un Mac Book Pro de 2010, ne peut grosso modo plus accéder à la majorité des sites internet depuis le 1er octobre 2021, pour une bête question de certificat expiré sur les anciens OS.
MacGé n'en a pas parlé mais c'est un phénomène mondial. Je n'ai pas de solution et pas les moyens pour un nouveau MBP "jetable". ☹️
@vince29
C’est habituel de la part d’Apple en tout cas, si je ne dis pas de bêtises lorsqu’une version majeure de Xcode sort, elle demande au minimum le dernier macOS au moment de la sortie (Xcode 12 demandait Catalina ou plus, Xcode 13 sorti ce mois-ci demande Big Sur ou plus…), et cette version majeure de Xcode devient indispensable 6 mois après sa sortie puisqu’Apple n’accepte plus que les applis compilées avec le dernier SDK au printemps, et ce dernier SDK n’est embarqué que dans le dernier Xcode.
En gros, en mars / avril prochain, il faudra obligatoirement utiliser Xcode 13, ce qui impliquera d’être au moins sous Big Sur. C’est très précipité à mon avis, surtout qu’Apple met pas trop de cœur à l’ouvrage pour supporter des vieilles générations de Mac sur les nouveaux macOS.
Par contre quand on est sur Monterey il semble qu’il ne faille pas utiliser la version finale de Xcode 13 mais la bêta 5. Enfin c’est pas hyper clair, c’est indiqué « Xcode 13 includes everything you need to create and submit apps to the App Store for all Apple platforms. It Includes the SDKs for iOS 15, iPadOS 15, watchOS 8, tvOS 15, and macOS Big Sur. To continue developing apps for macOS Monterey, use Xcode 13 beta 5. »
Xcode 13 se lancera sur Monterey, mais le SDK s'arrête à Big Sur : il ne sera juste pas possible d'exploiter les nouveautés de Monterey dans les apps développées avec.
@Siilver777
Merci ! Assez bizarre d’avoir viré le SDK de Monterey dans la version finale
Le truc vraiment idiot, c'est d'inclure les SDK avec l'application Xcode, plutôt que de permettre d'installer ou non les SDK dont on a besoin, comme autrefois... Parce que bon, déjà tout le monde n'a pas besoin de se colletiner les SDKs de chaque plateforme, et selon les projets sur lesquels on bosse on peut avoir besoin d'un SDK ancien ou au contraire pour un OS en beta. Et vu la place que bouffents ces SDK…
@jerome74
C’est pas faux !
@jerome74
Je suis assez d’accord. A priori, c’est un soucis de conception côté Xcode.
Mais c’est vrai que si Apple pouvait sortir les SDK de Xcode, ce serait une révolution bienvenue !
Une révolution? Plutôt un sain retour en arrière !
"Finalement, la meilleure solution est probablement de se retrousser les manches et rattraper sa dette technique sans attendre le dernier moment."
Je sais que c'est pas forcément évident pour tout le monde et selon le projet, mais c'est le meilleur conseil que vous pourrez entendre, merci 🙏
> un nouveau développeur dans une équipe aura probablement déjà son matériel équipé du dernier macOS
À ce moment là Monterey ne sera plus en beta !
> Alors forcément, quand Apple annonce qu’il faudra passer par Xcode 13 sous macOS Monterey dès le départ, c’est la panique.
Ah bon ?
La solution est AMHA très simple : Tant que Monterey est en beta, continuer ses développements sous BigSur - voire Catalina.
Et rien n'empêche d'avoir une machine ou une partition de test avec Monterey beta, et donc oui avec le nouveau Xcode beta sur cette partition s'il faut en passer par là.
Dans ma boîte les devs sont faits sous BigSur ou Catalina, et les machines de build tournent sous Catalina. Et bien nos logiciels sont 100% compatibles avec Monterey- et bien sûr BigSur. (On le vérifie régulièrement.) Etonnant, non ?
Sauf bien sûr si vous voulez sortir immédiatement un truc qui ne tourne que sous Monterey ou avec des fonctions qui nécessitent absolument Monterey. Mais je doute que cela concerne la majorité des développeurs.
Le problème n'est pas là.
Imaginons que votre app macOS fonctionne nickel quand elle est compilée avec le SDK Big Sur, mais qu'elle plante avec le SDK Monterey. Utiliser le SDK Big Sur permet de continuer de publier l'app.
Mais si macOS Monterey impose d'utiliser le SDK Monterey, vous êtes bloqué : vous ne pourrez pas utiliser le SDK Big Sur sur Monterey.
@ Florent Morin
> Imaginons que votre app macOS fonctionne nickel quand elle est compilée avec le SDK Big Sur, mais qu'elle plante avec le SDK Monterey
Alors il y a un bogue à corriger ou une évolution dans le SDK à prendre en compte me semble-t-il.
Plan B, garder un environnement de développement avec BigSur en attendant de pouvoir corriger le problème de crash.
(Je n'ai jamais vu de crash qui ne soit pas dû à une erreur de dev au final autre que des problèmes liés à l'OS lui même et qui ont été "corrigé" par une mise à jour de macOS.)
@marc_os
Côté iOS, on a eu des trucs bizarres.
Déjà, si on n’a pas géré l’apparence des barres (navigation, onglets) via la méthode introduite avec iOS 13, la personnalisation est cassée.
Et, dans les listes, un espace supplémentaire a été ajouté entre sections. Ça peut donc faire bizarre.
Et je parle même pas du code qui utilise des hacks d’affichage. 😅
En tout cas, tout ça s’anticipe.
> Et je parle même pas du code qui utilise des hacks d’affichage
Quand on joue avec le feu, parfois on se brûle ! 😉
"Finalement, la meilleure solution est probablement de se retrousser les manches et rattraper sa dette technique sans attendre le dernier moment."
Je traduis pour les personnes qui ont tendance à oublier que c'est les clients qui payent leur salaire: tout le monde ne vit pas dans le merveilleux monde des bisounours du champ de distorsion de réalité, une chaine de production cela ne s'arrête pas comme cela juste parce que les développeurs de Saint-Apple n'ont pas envie de se sortir le doigt du fondement pour offrir un minimum de compatibilité. Certains logiciels nécessitent quelques années de développement pour sortir une nouvelle version majeure, pendant ce temps l'ancienne version reste en mode maintenance et doit couvrir une large gamme de systèmes d'exploitation pour continuer de fonctionner. Car non l'argent ne pousse pas sur les arbres et certaines entreprises n'en ont que faire de passer instantanément au dernier OS juste parce qu'il y a une super nouvelle liste d'emojis. Avec cette politique stupide Apple est en train de massacrer le peu de Macs qui restent encore dans l'univers professionnel... hors utilisateur d'Adobe et MS. C'est un choix, et il est à courte vue...
À ce moment-là, le problème ne vient pas des développeurs qui voudraient anticiper les contraintes imposées par Apple, mais bien d'Apple en elle-même.
Clairement, c'est rendre notre travail impossible.
@trouaz
Je ne connais pas le marché macOS.
Sur iOS, qui est une version simplifiée, j’ai tendance à créer une branche qui va intégrer dès l’été les nouveautés du nouvel iOS.
Ensuite, des rebases réguliers de la branche de travail permettent d’intégrer les nouvelles fonctionnalités en conservant la compatibilité avec le nouvel iOS.
Après, ce sont des apps qui ont 20-30 écrans maximum. Et 40-50 endpoints côté API. On n’est pas sur des gros volumes de code.
Ce sont des millions de lignes de code, des dizaines de milliers de points d'entrées, l'intégration de composants tiers évoluant chacun à leur gré permettant de piloter des matériels de tierce partie. Des dizaines de binaires et d'applications permettant de mettre tout cela en ordre sous la forme d'une interface composé de centaines d'écrans de configuration. Et une envie de plus en plus vive de laisser tomber le Mac à cause de ses contraintes idiotes.
@trouaz
Tout dépend de l’impact sur le projet.
Sur iOS, côté data, l’impact est globalement de zéro. Côté UI, sauf à avoir du retard dans les bonnes pratiques, il y a un seul composant impacté. Et donc ça se corrige en quelques minutes.
Là où j’ai pris cher :
- du code qui a un style obsolète depuis 3 ans
- des composants externes venant de projets open-source abandonnés depuis des années
- des hacks côté UI via l’utilisation de mécanismes de reverse engineering.
Je ne connais pas du tout l’impact des MAJ sur macOS, mais côté iOS ça reste quelques jours de mise à jour du code chaque année. Avec une capacité d’anticipation sur 2-3 ans au moins.
Et c’est vrai que les tests UI automatisés permettent de trouver plus facilement ce qui est cassé. Mais c’est un investissement.
Après, si ça ne convient pas, il ne faut en effet pas persister sur la plateforme Apple. Les règles du constructeur sont en effet contraignantes.
C'est vraiment une mauvaise nouvelle.
On a toujours besoin de pouvoir relancer un vieux Xcode pour s'occuper d'une vieille appli qui n'a pas bougé depuis longtemps.
Pour migrer vers Xcode 13, il faut parfois passer par Xcode 10, puis 11 pour faire certaines conversions SWIFT.
En entreprise, on ne peut pas jeter aux orties tout ce qui n'est plus à la pointe de la techno.
Jusqu'à maintenant (BigSur), on pouvait utiliser de vieilles version de Xcode (jusqu'à Xcode 10 pour ma part), et ça m'a rendu bien des services !
Avoir une deuxième partition, ou une deuxième machine qui reste sur un vieil OS n'est pas une solution plus élégante.
Je ne vois aucune raison de cette rupture de compatibilité (surtout vu le peu de nouveautés de Monterey) !
@ rbart
> On a toujours besoin de pouvoir relancer un vieux Xcode pour s'occuper d'une vieille appli qui n'a pas bougé depuis longtemps.
Même sous Catalina on ne peut pas installer n'importe quelle vieille version de Xcode.
Si on a besoin d'un vieil environnement, le garder, OS compris.
C’est franchement absurde, surtout qu’on peut pas dire que Xcode 13 soit la meilleure release de ces dernières années.
Je peux comprendre qu’Apple force les développeurs à soumettre des applis compilées avec le dernier SDK après 6 mois de dispo, mais lier les versions de Xcode et de macOS comme ils le font est vraiment débile.
Déjà qu’ils devraient avoir pas mal honte du running gag qu’est devenu leur IDE, dont la principale nouveauté à chaque release majeure est « on a enfin corrigé les problèmes d’auto complétion » pour se rendre compte au final que non…
Il faut quand même être nul si dans une équipe pro on n’est pas capable de s’assurer des compatibilités avant une mise à jour.
Je bosse dans une grande boîte de plus de 1000 employés, et que ce soit Apple ou Microsoft, les problèmes de compatibilités sont légions. Avant une mise à jour, il y a des tests.
J’appelle ceci un manque de professionnalisme de lama prêt de ces développeurs.
Néanmoins, les autres soucis de mise à jour d’os et compatibilités d’OS sur Mac est un vrai soucis que j’associe clairement a de l’obsolescence programmée légale. C’est ma vision.