La page d’installation macOS de Swift.org classe les chaînes « release/6.4.x » dans la zone des instantanés de développement et précise que ces instantanés ne sont pas des versions officielles. Pour créer un Swift Package avec Swift 6.4, vérifiez d’abord la chaîne d’outils réellement active, puis générez un petit projet avec Swift Package Manager et validez-le par une compilation et un test. Si Swift 6.4 est proposé sous forme de préversion, gardez-le dans un projet d’essai séparé tant que le cours ne le demande pas explicitement. Cette distinction est confirmée sur la page d’installation Swift pour macOS.
Ce guide s’adresse aux personnes qui découvrent Swift et doivent produire un premier projet que l’on peut compiler ou tester.
Il convient aussi aux étudiants sur Windows ou sur un ordinateur scolaire qui cherchent à savoir quand un Mac distant devient nécessaire.
Si un cours impose une version précise, la priorité est de conserver son environnement de référence.
Dernière vérification : 5 octobre 2026. Le statut de la chaîne d’outils et les étapes du tutoriel ont été contrôlés à partir des pages Swift.org et Apple citées dans cet article.
[ SECTION_01 ] Avant de commencer, identifiez le type de travail demandé
Un Swift Package est un projet Swift organisé selon des règles que l’outil peut lire, compiler et tester. Il peut servir de bibliothèque réutilisable, de programme en ligne de commande ou de composant intégré à d’autres projets. Le package n’est pas, à lui seul, un projet d’application iOS complet : il ne remplace ni l’interface d’une application, ni la configuration nécessaire pour la signer et l’exécuter sur un appareil.
La distinction évite une confusion fréquente. Un cours qui demande de calculer une valeur, d’écrire une fonction réutilisable ou de suivre des tests peut convenir à un package. Un exercice qui exige des vues SwiftUI, un simulateur iOS ou la configuration d’une application demande plutôt un projet Xcode. Les deux formats utilisent Swift, mais ne permettent pas les mêmes vérifications.
Comment savoir quel modèle choisir pour l’exercice ? Repérez d’abord le résultat attendu dans la consigne. Si le travail doit fournir des fonctions que d’autres fichiers peuvent appeler, choisissez une bibliothèque. Si l’exercice doit afficher un résultat dans le terminal, choisissez un programme exécutable. Si la consigne parle d’écrans, d’une application ou d’un simulateur, vérifiez si un projet Xcode est explicitement requis.
La documentation officielle décrit le package comme un ensemble comprenant notamment un manifeste, du code source et, éventuellement, des tests. Le manifeste Package.swift joue le rôle de fiche descriptive : il indique à Swift Package Manager comment le projet est organisé. Au début, il suffit de comprendre son rôle ; il n’est pas nécessaire d’y ajouter des dépendances ou de modifier des réglages complexes. La présentation officielle de la structure des packages Swift détaille ces éléments.
Le système d’exploitation utilisé pour apprendre n’est pas automatiquement celui qu’il faut utiliser pour chaque exercice. Python ou les bases de Swift peuvent parfois s’apprendre avec les outils déjà disponibles. En revanche, une consigne exigeant macOS, Xcode ou un simulateur Apple impose de vérifier si l’ordinateur actuel peut répondre à cette exigence. Il vaut mieux identifier cette contrainte avant de suivre des instructions qui supposent un environnement différent.
[ SECTION_02 ] Vérifiez d’abord la chaîne d’outils active
Une chaîne d’outils Swift rassemble les programmes qui comprennent et traitent le code Swift. Swift Package Manager, souvent abrégé en SPM, s’occupe de décrire le package, de préparer sa compilation et de lancer ses tests. Pour une analogie simple, Swift est la langue du projet, la chaîne d’outils est l’ensemble des outils qui la traitent, et le gestionnaire de packages organise le chantier.
Sur Mac, l’une des premières vérifications consiste à interroger le terminal avec swift --version. Cette commande affiche la version que le terminal trouve en premier dans son environnement. Le guide Swift.org pour créer un projet en ligne de commande s’appuie sur cette vérification pour commencer un projet. La réponse correspond à l’outil réellement appelé ; elle ne prouve pas, à elle seule, que cette version est celle demandée par un cours.
Avant de lancer la commande, ouvrez un terminal dans l’environnement où le projet sera créé. Une session sur le Mac local et une session sur un Mac distant peuvent utiliser des chaînes différentes. Si le terminal affiche une version inattendue, notez le résultat et vérifiez comment Swift a été installé et sélectionné dans cette session. Évitez d’installer plusieurs versions au hasard : cela peut rendre moins évident le choix de l’outil utilisé par chaque fenêtre de terminal.
Sur un Mac équipé de Xcode, les outils en ligne de commande peuvent être installés ou gérés séparément de l’interface graphique d’Xcode. Apple explique leur rôle dans la documentation sur l’installation des outils en ligne de commande de Xcode. La référence Apple aux outils de ligne de commande associés à Xcode aide à comprendre les outils disponibles. La présence d’un outil en ligne de commande ne signifie pas nécessairement que toutes les fonctions d’un projet d’application avec interface graphique sont présentes.
À retenir. Si le cours impose une chaîne d’outils, utilisez-la comme référence pour le travail à rendre. Une préversion peut être utile pour un essai distinct, mais elle ne doit pas remplacer silencieusement l’environnement stable du cours.
Le statut de Swift 6.4 mérite cette précaution. La page macOS de Swift.org classe les instantanés dans une zone de développement et avertit qu’ils ne sont pas des versions officielles. Le texte de la page peut évoluer ; avant de suivre un cours ou de préparer une remise, vérifiez donc son état actuel. Ne déduisez pas de la seule mention « 6.4 » qu’un enseignant a validé cette chaîne ou que tous les outils du cours sont compatibles.
Sur un ordinateur scolaire, un compte limité peut aussi empêcher l’installation ou la modification de certains outils. Il faut alors respecter les règles de l’établissement, demander l’environnement autorisé ou utiliser une machine déjà configurée. Contourner une restriction de gestion de l’appareil n’est ni une étape de ce tutoriel ni une bonne façon de diagnostiquer un problème de cours.
[ SECTION_03 ] Première étape : créez un package adapté à l’exercice
Avant de générer le projet, décidez si l’exercice porte sur une bibliothèque ou sur un programme qui s’exécute dans le terminal. Les commandes d’initialisation de Swift Package Manager créent une structure de départ correspondant au type demandé. Le guide officiel pour les projets en ligne de commande décrit le modèle exécutable ; celui consacré à la création d’une bibliothèque Swift avec Swift Package Manager présente le modèle de bibliothèque.
Dans le terminal, créez un dossier au nom simple, entrez dans ce dossier, puis utilisez le modèle qui correspond à l’exercice. Avec le modèle exécutable, la commande est :
swift package init --type executable
Pour une bibliothèque, utilisez plutôt :
swift package init --type library
Les commandes et le rôle des modèles sont décrits dans les guides Swift.org consacrés au projet en ligne de commande et à la bibliothèque. Les exécuter dans un dossier d’exercice distinct permet d’éviter de mélanger les fichiers générés avec un autre projet.
La commande ne transforme pas un projet en application iOS. Elle prépare un package de type bibliothèque ou exécutable. Dans les deux cas, le dossier contient un manifeste Package.swift, qui décrit le package, ainsi que des répertoires destinés au code source et, selon le modèle, aux tests. Le modèle exécutable fournit le point de départ du programme ; le modèle bibliothèque organise le code destiné à être réutilisé et testé.
Comment Swift Package Manager génère-t-il le projet ? Il lit la commande d’initialisation et crée les fichiers de départ adaptés au modèle choisi. Il ne devine pas le devoir à réaliser : le nom du dossier et le type de package servent de base à la structure. Après l’initialisation, observez les fichiers avant de les modifier. Cette inspection permet de repérer où écrire le code et où se trouvent les tests sans toucher au manifeste.
Si la commande renvoie une erreur, vérifiez d’abord que le terminal est bien positionné dans le dossier prévu et que l’outil swift est disponible. Un message d’initialisation ne signifie pas forcément que le code de l’exercice a été compilé : la création des fichiers et la validation du programme sont des opérations distinctes.
[ SECTION_04 ] Deuxième étape : modifiez le fichier source, pas le manifeste
Pour le premier exercice, choisissez un résultat facile à observer. Un programme exécutable peut afficher un message ou calculer une valeur à partir de données simples. Dans une bibliothèque, une fonction courte peut produire un résultat que les tests vérifieront. Le but n’est pas d’ajouter des fonctions sophistiquées, mais de faire un changement identifiable puis de vérifier son effet.
Ouvrez le fichier source créé par le modèle et ne modifiez que la partie nécessaire. L’emplacement exact varie selon le type de package et les fichiers générés ; suivez donc le chemin visible dans le dossier, plutôt que de supposer que tous les projets ont la même organisation. Si l’éditeur propose plusieurs fichiers Swift, vérifiez le nom du répertoire Sources et celui du package afin de ne pas modifier un ancien exercice par erreur.
Gardez Package.swift intact pour ce premier passage, sauf si le cours demande explicitement une modification. Ce fichier déclare la structure et les éléments du package ; ce n’est pas l’endroit où écrire le résultat affiché par le programme. Ajouter une dépendance externe ou changer la configuration avant d’avoir fait fonctionner le modèle augmente le nombre de causes possibles en cas d’échec.
Lorsque le projet est ouvert depuis un Mac distant, vérifiez également le chemin affiché dans le terminal et dans l’éditeur. Le dossier visible sur un ordinateur Windows n’est pas automatiquement le même que celui créé sur le Mac. Enregistrez les changements dans le répertoire distant utilisé pour la compilation et gardez à part toute copie locale éventuelle. Cette vérification évite de tester une version du fichier et d’en rendre une autre.
Petit contrôle avant compilation. Le fichier doit être enregistré, le terminal doit se trouver dans le dossier du package et le code modifié doit être celui que le cours demande. Si un éditeur signale une erreur, lisez d’abord la ligne concernée avant de modifier les réglages du projet.
[ SECTION_05 ] Troisième étape : construisez, exécutez ou testez
La construction vérifie que le code peut être compilé dans l’environnement actif. Depuis le dossier du package, lancez :
swift build
Cette commande fait partie des opérations de base présentées dans le guide Swift.org pour les projets en ligne de commande. Une construction réussie indique que le code et la configuration permettent de produire le projet. Elle ne prouve pas que le résultat répond à toutes les consignes du devoir.
Pour un modèle exécutable, lancez ensuite le programme avec :
swift run
Vérifiez le résultat dans le terminal. Si le programme doit afficher un message, comparez le texte obtenu avec le résultat attendu par le cours. S’il doit calculer une valeur, essayez aussi les entrées prévues dans l’exercice. Cette validation visible aide à distinguer « le programme compile » de « le programme fait ce qui est demandé ».
Pour une bibliothèque, la vérification passe généralement par les tests prévus dans le package. La commande est :
swift test
Le guide Swift.org sur les tests des packages Swift explique cette étape et la manière dont les tests permettent de vérifier le code. Un projet nouvellement généré peut avoir des tests de départ ; après modification, examinez ce qu’ils vérifient réellement. Un test réussi confirme les assertions présentes, pas des exigences qui n’ont pas été codées dans les tests.
Comment vérifier la version Swift utilisée par le terminal ? Exécutez swift --version dans la même session et le même environnement que ceux utilisés pour construire le package. Si le résultat diffère de la version demandée dans la consigne, consignez-le avant de poursuivre. Un projet peut échouer pour une erreur de code, un mauvais répertoire ou une différence d’environnement ; la version n’est qu’une cause possible.
Si une construction ou un test échoue, procédez dans un ordre simple. Confirmez d’abord le dossier courant. Vérifiez ensuite que les modifications sont enregistrées, puis relisez le premier message d’erreur plutôt que la longue série de messages qui peut le suivre. Comparez enfin la version affichée avec celle prévue par le cours. Ne supprimez pas de fichiers et ne changez pas plusieurs réglages à la fois : une correction isolée permet de savoir si le problème a réellement disparu.
Les dépendances peuvent aussi compliquer un exercice, notamment si le package doit récupérer du code externe. Pour un premier package sans dépendance demandée, n’en ajoutez pas simplement pour tester l’outil. Si le cours en impose une, gardez la consigne et le message d’erreur sous les yeux, puis vérifiez la configuration avant d’attribuer l’échec à Swift ou à la chaîne d’outils.
[ SECTION_06 ] Choisissez l’environnement selon le résultat à rendre
Le tableau suivant sert à sélectionner le format, non à comparer des performances. Les appréciations sont des repères pédagogiques : elles ne remplacent pas les instructions de l’enseignant ni les fonctions propres à un environnement particulier.
| Travail attendu | Format de départ | Vérification principale | Adéquation pour un premier exercice |
|---|---|---|---|
| Fonctions réutilisables, logique ou code partagé | Package de type bibliothèque | Compilation et tests du package | Très adaptée si le cours demande du code réutilisable |
| Petit programme qui affiche un résultat | Package exécutable | Compilation, puis exécution dans le terminal | Très adaptée pour observer immédiatement le résultat |
| Écrans, interface SwiftUI ou application iOS | Projet d’application Xcode, si demandé | Construction et exécution dans l’environnement prévu par le cours | À choisir lorsque la consigne exige une application |
| Exercice Swift sans exigence macOS explicite | Environnement autorisé par le cours | Vérification des outils disponibles et du résultat | À décider selon la consigne, sans louer ou installer par défaut |
Une bibliothèque et un exécutable peuvent partager l’usage de Swift Package Manager, mais leur résultat attendu n’est pas le même. Il ne faut donc pas choisir une bibliothèque uniquement parce qu’elle semble plus avancée, ni un programme exécutable lorsque le devoir exige des vues iOS. Si la consigne reste floue, demandez quel type de livrable est attendu avant de reconstruire tout le projet.
Un environnement macOS devient pertinent quand le cours exige un outil Apple qui n’est pas disponible sur la machine actuelle, notamment Xcode ou le simulateur iOS. Si le package se construit déjà dans l’environnement autorisé et que le résultat satisfait l’exercice, changer d’ordinateur n’apporte pas nécessairement de bénéfice. Pour distinguer ces cas, les étudiants peuvent consulter les informations sur l’environnement Mac proposé par NOVAKVM, puis vérifier que l’accès et les outils nécessaires correspondent à la consigne.
[ SECTION_07 ] Terminez l’exercice avec une remise vérifiable
Avant de considérer le travail terminé, contrôlez que les fichiers enregistrés sont ceux que la consigne demande. Conservez le manifeste, les sources et les tests nécessaires au package. Ne transmettez pas seulement une capture du terminal si le cours demande le projet lui-même ; suivez le format de remise annoncé par l’enseignant.
Une liste de vérification évite les oublis au moment de rendre l’exercice :
- [ ] Le type de projet correspond au livrable demandé : bibliothèque, programme en ligne de commande ou application Xcode.
- [ ] La commande
swift --versiona été exécutée dans le terminal utilisé pour le projet, et son résultat a été comparé à la version exigée par le cours. - [ ] Le package a été créé dans le bon dossier et les fichiers attendus sont présents.
- [ ] Le code source modifié est enregistré dans le répertoire réellement compilé.
- [ ] La construction, l’exécution ou les tests correspondant au modèle ont été lancés.
- [ ] Les messages de réussite ou d’erreur ont été examinés avant de préparer la remise.
- [ ] Les fichiers conservés correspondent aux exigences de soumission du cours.
Que faire si les tests échouent après la création du package ? Vérifiez d’abord que les tests ont été lancés depuis le dossier du package et que le code a été enregistré. Ensuite, lisez le premier échec et comparez la version active avec celle demandée. Si l’erreur porte sur une fonction, corrigez le code ou le test concerné ; si elle signale un outil manquant, consultez la configuration autorisée par le cours avant d’installer quoi que ce soit.
Quand faut-il passer à Xcode ? Ce passage se justifie lorsque l’exercice exige une interface d’application, SwiftUI, un simulateur ou une fonction du projet Xcode. Pour une fonction Swift simple, un package de bibliothèque ou un programme en ligne de commande, l’interface complète n’est pas automatiquement nécessaire. La consigne détermine le besoin ; le nom « Swift » seul ne suffit pas à trancher.
En l’absence d’un Mac local compatible, un Mac distant peut être une solution de travail si le devoir impose réellement macOS ou Xcode. Il reste toutefois tributaire de la connexion réseau et des règles d’accès, et un environnement distant ne garantit pas par lui-même que les outils correspondent au cours. Un Mac acheté localement convient mieux aux personnes qui ont besoin d’un accès physique régulier ou d’un usage durable ; un Mac déjà disponible peut être le choix le plus simple si son environnement répond aux exigences. Pour un besoin ponctuel de cours, l’accès à un Mac à distance proposé par NOVAKVM peut éviter de remplacer immédiatement l’ordinateur actuel, à condition de vérifier au préalable que la tâche est réalisable dans l’environnement disponible.
Le meilleur prochain pas dépend donc du résultat des vérifications : si le package se construit et se teste dans l’environnement autorisé, poursuivez les exercices avec celui-ci. Si la consigne impose macOS ou Xcode et que l’ordinateur actuel ne le permet pas, comparez les options d’accès à un Mac avant de commencer le travail noté. Pour un essai sur une chaîne Swift 6.4 en préversion, gardez un projet distinct et ne faites pas de cette préversion l’environnement de remise sans validation explicite du cours.