Ce que la création d’apps Swift Playgrounds nous apprend du futur de Xcode
Il y a quelques semaines sortait la version bêta de Xcode 13.2. Avec elle arrivait un aperçu de ce que pourra réaliser le très attendu Swift Playgrounds 4 dont la principale nouveauté est la conception d’apps destinées à l’App Store. En explorant ce nouveau format de projet Xcode, nous avons un aperçu de ce que pourrait être le futur de l’outil phare des développeurs Apple.
Initialement, Swift Playgrounds était un outil pour découvrir le développement de manière ludique. Puis, d’année en année, l’outil s’est enrichi en intégrant la possibilité de faire appel à des frameworks externes notamment. En parallèle, Xcode s’est allégé. Depuis la version 9, le fichier de projet s’appuie sur la structure des répertoires pour organiser le code source. Depuis Xcode 11, Swift Package Manager fait partie intégrante de l’outil.
Aujourd’hui, il est tout à fait possible de gérer ses dépendances internes et externes via Swift Package Manager qui s’avère léger et performant. Le tout fonctionne de mieux en mieux avec git, le gestionnaire de versions de code source le plus utilisé. À l'heure actuelle, le seul poids du développeur Apple reste donc le fameux fichier xcodeproj qui gère toute l’organisation des projets iOS / macOS.
Et c’est donc là que les choses deviennent intéressantes. Un projet d’app Playgrounds n’est qu’un répertoire utilisant l’extension swiftpm (Pour « Swift Package Manager ») et contenant un fichier Package.swift décrivant le package ainsi que le code source de l’app et les ressources associées. En gros, ce n’est qu’un package Swift.
Ce qui est encore plus intéressant est d’explorer le format du fichier Package.swift. Il fait appel à un framework interne, AppleProductTypes, qui va étendre les propriétés du package Swift. Il va ainsi lui apporter un nouveau type de produit issu de la compilation : iOSApplication. Et à l’intérieur se trouve toute la configuration du projet à compiler. C’est une version allégée des propriétés d’un fichier xcodeproj.
Il suffirait probablement d’augmenter les capacités de ce framework pour pouvoir concevoir une application iOS telle que celles réalisées aujourd’hui. Cela s’applique également aux applications macOS, watchOS et tvOS qui pourraient s’appuyer sur un modèle identique à celui de iOSApplication. Swift Package Manager supporte également les codes sources en Objective-C, Objective-C++, C et C++ : même des projets un peu particuliers pourraient donc totalement fonctionner sur ce modèle.
Cela signifie-t-il que Swift Playgrounds et Xcode fusionneront à terme en un seul et même outil décliné sur iPad et Mac ? L’avenir nous le dira. En tout cas, les évolutions actuelles sont très prometteuses.
Trop hâte de tester tout ça !
Une date a t’elle été annoncée pour Swift playground 4 sur iPad ?
@Hatoine
Selon Apple, fin 2021.
https://www.apple.com/fr/ipados/ipados-15/
Apple est encore dans les temps mais il ne faudrait pas trop tarder ... ⏳
Hâte de pouvoir le tester en stream sur Twitch ( https://www.twitch.tv/formamac ) 😉
@FloMo
Merci
Que Xcode débarque enfin sur iPad ce serait génial !
Mais pourquoi fusionner au lieu de laisser Swift Playgrounds en app indépendante qui conserve son excellent travail de pédagogie et d’entraînement d’un côté, et Xcode historique de l’autre ?
« Cela signifie-t-il que Swift Playgrounds et Xcode fusionneront à terme en un seul et même outil décliné sur iPad et Mac ? »
@Lu Canneberges
Parce que XCode est un peu ce qu’était iTunes avant de disparaitre: une machine à gaz 😅
@Nico_Belgium
"une machine à gaz"
tant que ce n’est pas une usine à gaz 😁😉
@YetOneOtherGit
Merci pour la correction 😂 ça m’apprendra à me relire
@Nico_Belgium
"Merci pour la correction 😂"
C’était plus un clin d’œil qu’une « correction » 😉
@ Nico_Belgium
Xcode « une usine à gaz » ?
Ah bon.
Xcode a des défauts, certes, comme l'architecture des projets en groupes/fichiers à mon avis avec des options par défaut pas toujours très claires, mais je ne dirais pas cela.
Ceci dit c'est sûr que la plétore d'options dans les settings peut faire peur. Et pour certaines d'entre elles il vaut mieux savoir ce que l'on fait, et ne pas toucher à ce qu'on ne connait pas. Mais je préfère une inteface exhaustive qui permet de tout régler à un truc trop simplifié entraînant des limitations.
De plus le fichier .xcodeproj étant un simple fichier texte en XML, les plus téméraires peuvent aussi le trifouiller directement avec un bête éditeur de texte, ou via Xcode directement via la vue qui va bien.
Mais bon, les goûts et les couleurs...
@marc_os
Je trouve (avis personnel :) ) que XCode n’est pas très loin de ce qu’était iTunes avant de disparaître.
Un outil qui regroupe tellement d’outils qu’il en est buggé et parfois complètement ingérable.
Interface builder et les outils de performance par exemple pourraient très bien être des outils « à part » 🤷♂️
Perso je constate que l’outil est quand même méchamment buggé (Xcode 13 par exemple ça a été une catastrophe - partiellement corrige avec la version 13.1 ) et je peux pas m’empêcher de faire le lien de cause à effet entre un outil « trop » complet et les bugs qui y sont lié
Mais encore une fois: avis personnel ^_^
@Nico_Belgium
"Mais encore une fois: avis personnel ^_^"
Qui est assez largement partagé il me semble.
Et j’ai rarement rencontré quelqu’un me disant que c’était là le meilleur IDE qu’il est utilisé dans sa vie.
Un pis-aller plus qu’un chef-d’œuvre de dev XP aujourd’hui il me semble.
@ Nico_Belgium
> Interface builder et les outils de performance par exemple pourraient très bien être des outils « à part »
Justement, Interface builder était à l'origine un outil à part, et il fallait jongler entre IB et Xcode. Avec son intégration à Xcode, la création des UI et des contrôleurs associés a été simplifiée.
Il existe un outil de mesure des performance (et pas que) à part, ça savoir l'app Instruments qui permet d'analyser du code (app, démons, etco en cours fonctionnement en profondeur.
@marc_os
Avec SwiftUI qui est également déjà intégré à Xcode et le fait que tout le monde n’utilise pas IB (perso je l’ai tout à fait exclu et je programme mes interfaces 100% en code), est ce que ça a bien du sens de le garder ?
C’est un simple exemple mais c’est pour démontrer que tout ce qui est intégré n’est pas forcément utile à tout le monde mais pourtant l’alourdis ce dernier « pour tout le monde »
Instruments est effectivement à part..mais sans vraiment l’être car encore une fois c’est « dans » Xcode 🤷♂️, un peu comme les simulateurs dont la gestion est un fouillis sans nom qui est également intégré à Xcode
@ Nico_Belgium
> est ce que ça a bien du sens de le garder ?
Ce n'est pas parce que vous ne l'utilisez pas que personne ne l'utilise !
Figurez-vous que nombre de logiciels existent depuis des années, et rien que pour leur maintenance IB est absolument nécessaire.
Pour vous, il suffit de l'ignorer.
C’est un simple exemple qui démontre que le petit cas particulier de chacun ne doit jamais être considéré comme un cas général. 😇
Si quelque chose ne vous intéresse pas, ignorez le, il n'y a rien de plus simple. Je ne vois pas en quoi la présence de IB que vous n'utilisez pas alourdirait Xcode.
> [Instrument] est « dans » Xcode
Je ne vois pas le problème du fait qu'une application dédiée au développement avec Xcode se trouve à l'intérieur du bundle Xcode. L'aide en ligne vous indique comment l'ouvrir depuis Xcode, puis si vous voulez vous pouvez "clouer" son icône dans le Dock pour la lancer directement.
@marc_os
Ah mais je sais bien que beaucoup de gens l’utilisent. Et j’ai pas de soucis avec ça.
Mais pourquoi moi je dois le garder, le télécharger a chaque update, et le laisser alourdir inutilement le tool ?
C’est ça mon point « usine à gaz » : à force sous couvert de facilité de vouloir « tout » mettre dans Xcode, on rend l’outil:
- lourd en terme de poids alors que tout le monde n’a pas toujours besoin de tout ce qui y est intégré
- lourd en terme d’optimisation parce qu’au plus il y a d’outils à gérer au moins le logiciel dans son ensemble sera performant
C’est exactement pour ça que j’ai fait le rapprochement avec iTunes. Parce qu’il avait exactement le meme problème. Qu’on veille gérer uniquement sa musique ou qu’on aie un iPhone pour tout gérer, on devait télécharger et utiliser le meme outil. Et c’est pour ça qu’Apple a fini par le splitter.
Et donc je serai pour splitter Xcode en plusieurs applications séparées ce qui permettrait à tout le monde d’utiliser uniquement les outils dont ils ont besoin 🤷♂️
@ Nico_Belgium
Il me semble que certains outils connexes comme Instruments ne sont pas installés lors de la première installation de Xcode et qu'il faut les installer dans un second temps.
Quant à IB, comme je l'ai déjà dit, son intégration dans Xcode a beaucoup simplifié son utilisation.
Ceci dit, je suis d'accord que certains composant installés par défaut pourraient ne pas l'être, comme les simulateurs quand on ne fait pas de dev pour iPhone, ni pour iPad, AW ou ATV.
@marc_os
"Xcode « une usine à gaz » ?"
Sans doute pas pour un docteur en physique doublé d’un ingénieur pour qui la compréhension de l’œuvre de Marx est triviale et facile 😈
Mais pour le commun des esprits faibles nous arrivons à une solution voulant tout faire assez boursouflée et peut-être assez datée par rapport à d’autres IDE.
@ YetOneOtherShit
> Sans doute pas pour un docteur en physique doublé d’un ingénieur pour qui la compréhension de l’œuvre de Marx est triviale et facile 😈
Tu devrais voir un psy pour gérer ton complexe d'infériorité qui te pousse systématiquement à dénigrer certains interlocuteurs, démontrant ainsi que tu n'as pas les compétences pour opposer une argumentation valable. Ce qu'il me semble, c'est que tu ne supportes pas d'avoir été démasqué en quelque sorte et donc à chaque fois que tu vois l'un de mes commentaires, tu t'acharnes as essayer de me dénigrer. En vérité, je te plains. Ou pas. Je te méprise.
PS: J'ai aussi un DEA, condition nécessaire avant tout doctorat. 😬
Et toi, c'est quoi tes compétences ? Trolleur es Internet ?
Pour info, ça fait plus de 10 ans que je traine sur macg, et il aura fallu un énergumène de ton genre pour m'énerver et me faire parler de mes diplômes - mea culpa - ce que je ne fais normalement jamais, jugeant les gens uniquement sur leurs compétences réelles, acquises de quelque manière que soit, qu'ils soient officiellement diplômés ou non.
@marc_os
"Tu devrais voir un psy pour gérer ton complexe d'infériorité qui te pousse systématiquement à dénigrer certains interlocuteurs, démontrant ainsi que tu n'as pas les compétences pour opposer une argumentation valable. "
Tu es aussi visiblement spécialiste en psychologie avec un niveau de maîtrise digne de celui que tu as pour les théories marxistes 👏👏👏
@marc_os
"d'infériorité qui te pousse systématiquement à dénigrer certains interlocuteurs"
Je ne dénigre nullement l’interlocuteur mais le message qu’il cherche à propager.
Dans ton cas une vision simpliste de la pensée marxiste.
Et je me moque gentiment de toi car tu as quand même osé nous retourner à Bigbidou et moi « C’est facile pour un ingénieur en physique » malgré les nombreux éclairages courtois que nous t’avions donner sur l’ineptie de ta posture d’un marxisme de rider digest 😎
@ YetOneOtherShit
> Je ne dénigre nullement l’interlocuteur mais le message qu’il cherche à propager.
Et ça c'est quoi ?
« Immonde suppôt du capitalisme s’accordant des plaisirs bourgeois »
Allez va petit, va cracher ton fiel ailleurs. T'as vraiment rien de mieux à faire ?
Ceci dit, il serait temps que j'arrête de réagir à tes provocations de gamin.
@marc_os
"Et ça c'est quoi ?
« Immonde suppôt du capitalisme s’accordant des plaisirs bourgeois »"
U trait d’esprit et d’humour rien de plus caricaturant tes postures de Che Guevara aux petits pieds si prompts à pourfendre le capitalisme avec des propos péremptoires aussi ridicules que la caricature que tu prends ici comme une attaque directe.
Un vrai marxiste peut parfaitement aimer le bon vin, les alcool et les cigare. Tout en comprenant vraiment les fondements de la pensée de Marx et aussi les finesses du capitalisme 🤓
@marc_os
"T'as vraiment rien de mieux à faire ?"
Faire preuve d’un peut d’esprit dans le pamphlet est une tradition bien établi et quand c’est mis au service d’une cause aussi importante que la lutte contre paupérisation de la pensée de Marx c’est œuvre de salut public 🧐🤓
@marc_os
"Ceci dit, il serait temps que j'arrête de réagir à tes provocations de gamin."
Nous sommes assez loin de la réthorique de préaux il me semble par contre c’est impressionnant de voir comment tu te drape dans ta dignité bafouée sans l’ombre d’une capacité à l’ironie ou a l’autodérision.
Le faux esprit de sérieux avec lesquels tu as défendu ta vision primaire de la pensée marxiste jusqu’en arriver à utiliser un ridicule argument d’autorité en est la parfaite illustration: il t’est insupportable que l’on te montre, référence à l’appuis, que tu comprends la pensée de Marx comme un Taliban comprend le Coran 😎
@marc_os
"Allez va petit, va cracher ton fiel ailleurs."
Nul fiel ce serait trop personnel, juste une légitime défense contre la paupérisation de la pensée t’amenant à oser défendre: “Marx c’est simple”
@marc_os
"jugeant les gens uniquement sur leurs compétences réelles, acquises de quelque manière que soit, qu'ils soient officiellement diplômés ou non."
Évidemment et strictement rien à voir avec le pb : ton entêtement à faire croire que la pensée de Marx et triviale et se résume aux caricatures que tu en fais.
Tes diplômes m’importent peu, comme qui tu es m’importe peu : seul compte ce que tu produit publiquement 😎
Faut peut-être un équivalent aux .xcconf pour gérer plus finement les build!
J’espère aussi que Apple corrige les milliards de bugs de xcode (surtout la v13) car là c’est plus supportable !!
@RedMak
Les plugins arrivent pour ça dans Swift Package Manager.
@FloMo
Ah merci j’ai pas vue ce « proposal » 👍
« Il suffirait probablement d’augmenter les capacités de ce framework pour pouvoir concevoir une application iOS telle que celles réalisées aujourd’hui. »
Bah oui, il suffirait juste de régler ce micro détail 🙂
je ne comprends pas bien cette phrase :
« À l'heure actuelle, le seul poids [ ?? ] du développeur Apple reste donc le fameux fichier xcodeproj »
Je suppose que vous voulez dire que "tout" repose sur ce fichier.
Ce qui est normal à mon sens car son objet est justement de décrire un projet dans sa totalité. (Notez qu'un projet peut contenir des sous-projets, et que le "projet" principal peut être un "workspace" constitué de sous-projets.)
Si j'ai bien compris, le fichier Package.swift va en fait contenir une partie des spécifications qui étaient dans le fichier .xcodeproj*.
Me trompe-je ?
(*) Fichier XML par ailleurs qu'on peut, avec quelques précautions, éditer manuellement, en particulier quand on veut tracker les évolutions de projets au cours du temps. Du coup dans Package.swift on passe d'une description en XML à une description en swift... (Les modes passent.)
C'est ça qui est dommage chez macg : Deux jours après la publication d'un article, même s'ils apparaissent toujours sur la page d'accueil on dirait que ceux-ci sont considérés comme obsolètes. D'ailleurs, il n'y a qu'à voir le système de navigation dans le site qui ne permet pas d'afficher sous forme de liste concise les articles qui ne sont plus sur la page d'accueil. Pour avoir ce genre de liste, on est obligé de faire une recherche, de filtrer, on ne peut pas simplement tout afficher, ou alors uniquement avec des articles complets, ce qui rend la navigation lourdingue. Ça me fait l'effet d'un site de news "jetables" après lecture.