Le projet fonctionne dans le simulateur, mais vous ne savez pas quel fichier remettre à votre enseignant. La solution la plus sûre est de vérifier le projet, de créer une archive avec Product > Archive, puis d’exporter ou de téléverser cette archive selon l’objectif du cours.

Cet article s’adresse aux étudiants qui viennent de terminer leur premier projet SwiftUI et veulent fournir une version utilisable à un enseignant ou à un camarade. Il concerne aussi les utilisateurs de Windows ou de Chromebook qui préparent leur code ailleurs avant de rejoindre un Mac compatible, local ou distant.

Commencez par identifier le livrable attendu

Avant de modifier la signature ou de chercher un certificat, demandez-vous ce que la consigne exige réellement. Un devoir qui demande une démonstration n’a pas besoin du même fichier qu’un test sur iPhone ou qu’une invitation TestFlight.

<
Objectif étudiantAction principaleRésultat attenduNiveau de configuration
Montrer l’application en classeCliquer sur Run et lancer le simulateurDémonstration locale du projetFaible
Remettre le code sourceCompresser ou synchroniser le projet avec ses ressourcesProjet ouvrable par l’enseignantFaible à moyen
Faire tester l’application sur un appareil autoriséCréer une archive puis utiliser l’export adaptéApplication installable selon les droits disponiblesMoyen à élevé
Préparer une version bêtaCréer une archive puis passer par App Store Connect et TestFlightInvitation à des testeurs autorisésÉlevé
**Run** ressemble à un brouillon que vous ouvrez devant la classe. **Archive** ressemble au dossier que vous remettez pour validation : il conserve une version de compilation destinée à la distribution. Apple décrit la création d’une archive comme une étape préalable aux opérations de distribution dans sa documentation sur la [préparation d’une app pour la distribution](https://developer.apple.com/documentation/Xcode/preparing-your-app-for-distribution).

Ne commencez donc pas par TestFlight si votre enseignant demande seulement le projet ou une capture vidéo. Vous risqueriez de perdre du temps dans la configuration du compte et de la signature alors que la consigne ne l’exige pas.

Préparez le projet avant la première archive

L’archivage ne corrige pas un projet désordonné. Il révèle souvent des problèmes qui ne sont pas visibles pendant une exécution rapide dans le simulateur.

Vérifiez la construction de base

Ouvrez votre projet et choisissez le schéma correspondant à l’application que vous devez remettre. Un schéma indique à Xcode quelle cible construire et avec quelles options. Si votre projet contient une application principale, une extension ou plusieurs variantes, ne supposez pas que le premier choix affiché est le bon.

Lancez ensuite l’application dans le simulateur prévu pour votre cours. Notez précisément le résultat :

  • une erreur de compilation bloque le code lui-même ;
  • une ressource introuvable signale souvent un fichier absent de la cible ;
  • une application qui démarre mais affiche un écran vide nécessite une vérification du code ou des données de test ;
  • une erreur de signature concerne l’identité de développement, l’équipe ou la destination choisie.
Le [guide Apple consacré aux schémas de construction](https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project) explique les réglages qui déterminent la cible et la configuration utilisées par Xcode. Consultez-le si votre projet semble compiler une mauvaise application.

Contrôlez l’identité de l’application

Le Bundle Identifier est l’identifiant unique utilisé pour distinguer votre application. Vous le trouverez dans les réglages de la cible, avec le nom de l’équipe et les options de signature. Ne le changez pas au hasard pour faire disparaître une erreur : une modification peut rendre incompatible une configuration déjà associée à un compte ou à un appareil.

Vérifiez aussi les éléments visibles par l’utilisateur :

  • nom de l’application ;
  • icône fournie dans les ressources ;
  • numéro de version ;
  • numéro de compilation ;
  • autorisations demandées ;
  • fichiers inclus dans la cible.
Le numéro de version décrit la version présentée aux utilisateurs, tandis que le numéro de compilation aide à distinguer plusieurs fichiers techniquement proches. Pour un devoir, suivez la convention demandée par l’enseignant et notez ces valeurs dans votre fichier de remise.

Sauvegardez avant de corriger

Avant l’archivage, créez un point de retour : commit dans votre dépôt, copie locale ou dossier compressé. Cette précaution est importante lorsque vous débutez, car une tentative de correction de signature peut modifier des réglages qui fonctionnaient auparavant.

**Attention :** ne partagez jamais un compte Apple, un certificat, une clé privée ou un fichier d’identification avec un camarade. Demandez plutôt à l’enseignant quelle méthode officielle de test est prévue pour le cours.

Passez de Run à Archive avec Xcode 27

Sélectionnez la bonne cible

Dans Xcode 27, commencez par sélectionner le schéma de l’application et une destination compatible avec l’archivage. Un simulateur convient à l’exécution de développement, mais il ne représente pas toujours la destination attendue pour une archive distribuable.

Si le menu d’archivage est indisponible, ne cliquez pas au hasard dans les réglages. Contrôlez d’abord :

  • que la cible active est bien une application ;
  • que le schéma n’est pas configuré uniquement pour un simulateur ;
  • que le projet et les dépendances sont entièrement résolus ;
  • que la version de macOS et de Xcode correspond aux exigences officielles affichées par Apple dans les prérequis système de Xcode.
Les intitulés exacts peuvent évoluer avec une nouvelle version de Xcode. La logique reste toutefois la même : choisir la cible, vérifier la configuration, construire une archive et examiner le résultat.

Lancez Product > Archive

Lorsque le projet compile dans une configuration cohérente, utilisez Product > Archive. Xcode construit alors une version archivée du projet au lieu de lancer simplement l’application dans le simulateur.

Une archive réussie apparaît dans l’organiseur Archives. Elle doit être associée au bon projet, à la bonne cible et au bon numéro de version. Ne considérez pas l’opération comme terminée uniquement parce qu’une fenêtre de progression a disparu : ouvrez l’organiseur et vérifiez que l’élément est bien présent.

Le tableau suivant sert à distinguer les états que les débutants confondent souvent. La note est une évaluation éditoriale de la pertinence pour un devoir, pas une mesure technique officielle.

<
État obtenuCe que vous pouvez affirmerCe que vous ne pouvez pas encore affirmerNote pour une remise étudiante
Run réussi dans le simulateurLe projet peut être exécuté dans cette configurationQu’un appareil réel acceptera l’application3/5
Projet compilé sans erreurLe code sélectionné est compilableQue les ressources et la distribution sont prêtes3/5
Archive crééeUne version de compilation est conservée pour la suiteQue l’installation sur l’appareil du destinataire est garantie4/5
Export acceptéUn format de distribution a été produit selon les droits disponiblesQue le test est identique sur tous les appareils4/5
Version disponible via TestFlightUne voie de test bêta a été préparée dans App Store ConnectQue le contenu respecte automatiquement la consigne du cours5/5
Si l’archive échoue, lisez le premier message utile du journal de construction. Apple maintient une page dédiée à la [résolution des problèmes courants d’archivage](https://developer.apple.com/documentation/technotes/tn3109-resolving-common-archiving-issues). Évitez de supprimer successivement les certificats, les dépendances et les réglages : vous risqueriez de transformer une erreur identifiable en plusieurs erreurs difficiles à isoler.

Choisissez l’export selon le destinataire

La présence d’une archive ne signifie pas que vous devez publier l’application. Dans l’organiseur, l’option de distribution vous oriente vers plusieurs chemins. Le bon choix dépend du destinataire, de la consigne et des droits liés à votre compte.

<
Besoin réelÉtape à privilégierFichier ou service remisPoint à confirmer
Remettre seulement le travail réaliséFournir le projet source et ses ressourcesDossier du projet ou dépôtL’enseignant peut-il ouvrir le projet ?
Tester sur un appareil autoriséDistribuer vers les appareils enregistrésApplication exportée selon le profil prévuL’appareil est-il autorisé pour ce type de distribution ?
Faire tester par plusieurs personnesPréparer la distribution bêtaInvitation et version TestFlightLe compte et la fiche App Store Connect sont-ils prêts ?
Préparer une publication futureSuivre la procédure de distribution correspondanteArchive téléversée et informations de l’appLa publication est-elle réellement demandée ?
Pour un appareil enregistré, suivez la procédure officielle de [distribution aux appareils enregistrés](https://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices). Cette méthode ne donne pas automatiquement le droit d’installer l’application sur n’importe quel iPhone.

La signature associe la construction à une identité et à des autorisations. En tant qu’étudiant, vous devez utiliser votre compte ou celui prévu officiellement par votre établissement ; ne cherchez pas à contourner ces contrôles.

Pour TestFlight, il faut également préparer l’environnement App Store Connect. La création de la fiche de l’application et le test bêta sont deux étapes distinctes : consultez les instructions Apple pour ajouter une app dans App Store Connect, puis le fonctionnement de TestFlight.

Continuez depuis Windows ou Chromebook avec un Mac

Vous pouvez préparer une grande partie du travail sans Mac :

  1. écrivez et organisez le code SwiftUI ;
  2. enregistrez le projet dans un dépôt ou une copie structurée ;
  3. rassemblez les images, fichiers de configuration et notes de remise ;
  4. vérifiez que les chemins de fichiers ne dépendent pas d’un dossier personnel ;
  5. transférez le projet vers un Mac compatible pour la compilation Xcode.
Le point important est la séparation entre **préparer le projet** et **construire l’application iOS**. Une connexion distante ne transforme pas Windows en environnement Xcode. Elle vous donne simplement accès à un Mac qui exécute les outils nécessaires.

L’interface distante convient mieux aux réglages graphiques, à l’ouverture du projet, au choix du schéma, à l’archivage et à l’export. SSH peut être utile pour vérifier les fichiers, récupérer un dépôt ou exécuter une commande contrôlée, mais il ne remplace pas l’interface Xcode lorsque vous devez examiner une archive ou une erreur de signature.

Si vous explorez cette solution, commencez par consulter le fonctionnement d’un Mac distant pour apprendre Xcode. Pour une session ponctuelle, choisissez ensuite une offre correspondant à votre zone et à votre méthode de connexion, par exemple un environnement Mac distant orienté développement. Vous pouvez également comparer une autre implantation proposée par MACGPU, sans supposer qu’une localisation résoudra à elle seule un problème de projet ou de signature.

Votre premier objectif à distance doit rester limité : ouvrir le projet, compiler la cible, créer l’archive et vérifier qu’elle apparaît dans l’organiseur. Si ces quatre opérations réussissent, vous pourrez ensuite traiter l’export demandé par votre cours.

Validez le dossier avant de le remettre

La dernière erreur fréquente consiste à confondre « l’application fonctionne chez moi » avec « le destinataire peut l’utiliser ». Faites une vérification séparée pour le simulateur, l’archive et le mode d’installation demandé.

Liste de contrôle exécutable

  • [ ] Le projet source a été copié ou enregistré dans un dépôt avant l’archivage.
  • [ ] Le schéma sélectionné correspond bien à l’application évaluée.
  • [ ] Le projet se lance sans erreur dans la configuration de développement prévue.
  • [ ] Les ressources, icônes et fichiers de données sont inclus dans la bonne cible.
  • [ ] Le Bundle Identifier et le numéro de version ont été vérifiés.
  • [ ] La configuration de signature correspond à votre compte ou à la procédure de l’établissement.
  • [ ] L’action Product > Archive a produit une archive visible dans l’organiseur.
  • [ ] L’export choisi correspond à la demande : code, appareil autorisé ou TestFlight.
  • [ ] Le fichier exporté peut être retrouvé et ouvert depuis le dossier de remise.
  • [ ] Le destinataire dispose d’instructions d’installation compréhensibles.
  • [ ] Une copie du projet qui compilait avant l’export est conservée.
  • [ ] La remise indique clairement ce qui a été testé dans le simulateur et ce qui a été testé sur appareil.
Si vous remettez une archive, indiquez son numéro de version et expliquez comment l’enseignant doit l’utiliser. Si vous remettez uniquement le code, précisez que le projet a été compilé et dans quelle configuration. Cette distinction évite qu’un fichier source soit pris pour une application directement installable.

Questions fréquentes

Comment créer une archive iOS avec Xcode 27 ?

Ouvrez le bon projet, sélectionnez le schéma de votre application et choisissez une destination de compilation compatible avec l’archivage. Vérifiez ensuite le numéro de version, l’identifiant d’application et la signature, puis utilisez Product > Archive. Si l’opération échoue, consultez le journal de construction avant de modifier plusieurs réglages à la fois.

Comment remettre un projet SwiftUI à un enseignant pour test ?

Commencez par demander le format attendu : code source, archive, application exportée ou lien TestFlight. Pour une remise de code, fournissez le projet et les instructions de lancement. Pour un test sur appareil, l’export doit respecter le mode de distribution autorisé et les appareils ou comptes concernés. Ajoutez toujours le numéro de version et la procédure d’installation.

Peut-on empaqueter une app iOS sans posséder de Mac ?

Vous pouvez écrire le code, versionner vos fichiers et préparer les ressources sur Windows ou Chromebook. En revanche, la construction iOS avec Xcode, la création de l’archive et les opérations de distribution doivent être réalisées dans un environnement macOS compatible. Un Mac distant peut donc servir pour la dernière partie, à condition de pouvoir utiliser Xcode et de conserver vos fichiers sous votre contrôle.

Quelle est la différence entre Run et Archive dans Xcode ?

Run compile le projet pour l’exécuter rapidement dans un simulateur ou sur un appareil autorisé, ce qui convient au développement quotidien. Archive produit un paquet de compilation destiné à une étape de distribution ou de conservation. Une application qui fonctionne avec Run peut encore échouer lors de l’archivage à cause de la configuration, de la signature ou des ressources incluses.

Quelles étapes faut-il suivre pour remettre un projet iOS étudiant ?

Contrôlez d’abord le code, les ressources, le schéma et le numéro de version. Faites ensuite une compilation propre, créez l’archive, puis choisissez entre remise du code, export pour appareil autorisé ou TestFlight selon la consigne. Enfin, ouvrez les fichiers destinés au destinataire, documentez l’installation et conservez une copie du projet qui compilait avant l’export.

Pour un devoir ponctuel, votre ordinateur Windows ou Chromebook reste utile pour écrire, organiser et sauvegarder le projet, mais il présente trois limites concrètes : il ne fournit pas l’environnement Xcode, il ne crée pas directement l’archive iOS attendue et il complique la vérification de la signature avant la remise. Acheter un Mac peut être cohérent si vous développez régulièrement ou si vous avez besoin d’interfaces audio, de montage vidéo ou de design au quotidien. En revanche, pour terminer un projet déjà écrit, un Mac distant MACGPU peut être plus proportionné : vous préparez vos fichiers localement, vous ouvrez le projet dans macOS, puis vous réalisez l’archivage et l’export sans immobiliser le coût d’un ordinateur complet. Vérifiez d’abord l’accès à Xcode, les droits de votre compte et le format demandé par votre établissement avant de louer.