Création d’applications Objective-C ou Swift pour iOS

  • Article

Important

La mise hors service de Visual Studio App Center est prévue pour le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à sa mise hors service complète, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager la migration.

En savoir plus sur les chronologies et les alternatives de support.

Pour créer votre première application iOS native, vous devez effectuer les actions suivantes :

  1. Se connecter à votre compte de service de dépôt (GitHub, Bitbucket, VSTS, Azure DevOps)
  2. Sélectionnez un dépôt et une branche où se trouve votre application
  3. Configurer le projet ou l’espace de travail de la build, ainsi que le schéma que vous souhaitez générer

Notes

Pour exécuter l’application sur un appareil réel, la build doit être signée par du code avec un profil d’approvisionnement valide et un certificat.

1. Liaison de votre dépôt

Si vous ne vous êtes pas encore connecté à votre compte de service de dépôt, vous devez autoriser la connexion. Une fois votre compte connecté, sélectionnez le dépôt où se trouve votre projet iOS. App Center nécessite que votre compte dispose d’Administration et de l’autorisation Pull pour configurer une build pour un dépôt.

2. Sélection d’une branche

Après avoir sélectionné un dépôt, sélectionnez la branche que vous souhaitez générer. Par défaut, toutes les branches actives sont répertoriées.

3. Configuration de votre première build

Configurez votre projet iOS avant votre première build.

3.1 Projet/espace de travail et schéma

Pour une configuration de build, un projet Xcode ou un espace de travail Xcode et un schéma partagé sont requis. App Center détecte automatiquement les projets, les espaces de travail et les schémas partagés (tant que les schémas se trouvent dans le dossier approprié) dans votre branche. Sélectionnez le projet ou l’espace de travail que vous souhaitez générer et le schéma correspondant.

Si aucun schéma n’est trouvé, vérifiez que le schéma souhaité est partagé et que son conteneur est le projet ou l’espace de travail que vous avez sélectionné. Vous devez également vérifier que ces modifications sont archivées dans la branche que vous configurez.

Gardez à l’esprit que vous ne pouvez pas exporter un .xcscheme fichier et le placer n’importe où dans le projet. Il doit se trouver dans le xcshareddata/xcschemes/ dossier . Assurez-vous que ce chemin d’accès ne figure pas dans votre .gitignore fichier.

Marquer le schéma comme partagé

3.2. Version Xcode

Sélectionnez la version Xcode sur laquelle exécuter la build.

3.3. Déclencheurs de génération

Par défaut, une nouvelle build est déclenchée chaque fois qu’un développeur envoie (push) à une branche configurée. Ce processus est appelé « intégration continue ». Si vous préférez déclencher une nouvelle build manuellement, vous pouvez modifier ce paramètre dans la configuration de build.

3.4. Incrémenter le numéro de build

Lorsqu’il est activé, le CFBundleVersion dans le Info.plist de votre application s’incrémente automatiquement pour chaque build. La modification se produit avant la génération et ne sera pas validée dans votre dépôt.

Notes

Pour que le numéro de build Incrémenter fonctionne, nommez par .plist file*Info.plist exemple Production-Info.plist.

3.5. Tests

Si le schéma sélectionné a une action de test avec une cible de test sélectionnée, vous pouvez configurer les tests pour qu’ils s’exécutent dans le cadre de chaque build. App Center peut actuellement exécuter des tests unitaires XCTest.

3.6. Signature de code

La création d’une application iOS pour des appareils réels nécessite de la signer avec des informations d’identification valides. Pour connecter des builds dans App Center, activez la signature du code dans le volet de configuration et chargez un profil d’approvisionnement (.mobileprovision) et un certificat valide (.p12), ainsi que le mot de passe du certificat.

Les paramètres de votre projet Xcode doivent être compatibles avec les fichiers que vous chargez. Vous pouvez en savoir plus sur la connexion de code dans la documentation officielle d’Apple Developer.

Les applications avec des extensions d’application ou watchOS nécessitent la signature d’un profil d’approvisionnement supplémentaire par extension.

3.7. Lancer votre build réussie sur un appareil réel

Utilisez votre fichier nouvellement produit .ipa pour tester si votre application démarre sur un appareil réel. Le lancement sur un appareil réel ajoute environ 10 minutes de plus au temps de génération total. En savoir plus sur la configuration des tests de lancement.

3.8. CocoaPods

App Center analyse la branche sélectionnée et s’il trouve un Podfile, il effectue automatiquement une pod install étape au début de chaque build. Cette étape garantit que toutes les dépendances sont installées.

Avertissement

Si le dépôt contient déjà un dossier /Pods , App Center suppose que vous avez archivé les pods dans votre dépôt et n’effectuera pod installplus . Si vous supprimez ou modifiez le dossier /Pods , vous devrez peut-être enregistrer manuellement la configuration de build à l’aide Save de ou Save and Build pour que la mise à jour prenne effet.

3.9. Distribuer à un groupe de distribution

Vous pouvez configurer chaque build réussie à partir d’une branche pour qu’elle soit distribuée à un groupe de distribution créé précédemment. Vous pouvez ajouter un nouveau groupe de distribution à partir de la section Distribuer. Il existe toujours un groupe de distribution par défaut appelé « Collaborateurs » qui inclut tous les utilisateurs qui ont accès à l’application.

Une fois que vous avez enregistré la configuration, une nouvelle build est lancée automatiquement.

4. Résultats de génération

Une fois qu’une build est déclenchée, elle peut se trouver dans les états suivants :

  • en file d’attente : la build est mise en file d’attente en attendant que les ressources soient libérées.
  • build : la build exécute les tâches prédéfinies.
  • réussite : la build est terminée et elle a réussi.
  • failed : la build s’est terminée, mais elle a échoué. Vous pouvez résoudre les problèmes en inspectant les journaux de build.
  • canceled : la build a été annulée par une action de l’utilisateur ou a expiré

4.1. Journaux d’activité de génération

Pour une build terminée (réussie ou ayant échoué), téléchargez les journaux pour en savoir plus sur la façon dont la build s’est déroulée. App Center fournit une archive avec les fichiers suivants :

|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
    |-- <build-step-1> (e.g. 2_Get Sources.txt)
    |-- <build-step-2> (e.g. 3_Pod install.txt)
    |--
    |-- <build-step-n> (e.g. n_Post Job Cleanup.txt)

Les journaux spécifiques à l’étape de génération (situés dans le build/ répertoire de l’archive) sont utiles pour résoudre les problèmes et comprendre quelle étape et pourquoi la build a échoué.

4.2. L’application (.ipa)

Le .ipa fichier est un fichier d’archive d’application d’appareil iOS qui contient l’application iOS.

  • Les builds non signées ne produisent pas de .ipa fichier. L’artefact d’une build non signée est le .xcarchive fichier qui peut être utilisé pour générer un .ipa fichier avec l’organisateur Xcode Archives.
  • Si la build est signée correctement, le .ipa fichier peut être installé sur un appareil réel correspondant au profil d’approvisionnement utilisé lors de la signature. Pour plus d’informations sur la signature et la distribution du code avec App Center, consultez la documentation sur la signature de code iOS d’App Center.
  • Si la build n’a pas été signée, le .ipa fichier peut être signé par le développeur (par exemple, localement à l’aide de codesign) ou utilisé à d’autres fins (par exemple, charger vers le service test pour tester l’interface utilisateur sur des appareils réels ou exécuter dans le simulateur).

4.3. Fichier de symboles (.dsym)

Les .dsym fichiers contiennent les symboles de débogage de l’application.

  • Si vous avez déjà intégré le Kit de développement logiciel (SDK) App Center dans votre application avec le module rapport d’incident activé, le service de création de rapports d’incidents nécessite ce .dsym fichier pour qu’une build affiche des rapports d’incident lisibles par l’utilisateur (symboliques).
  • Si vous avez déjà intégré un autre SDK à des fins de création de rapports d’incidents dans votre application (par exemple, le Kit de développement logiciel (SDK) HockeyApp), le service correspondant exige que le .dsym fichier affiche des rapports d’incident lisibles par l’utilisateur.

Gardez à l’esprit que les .dsym fichiers ne changent pas lors de la signature du code ..ipa Si vous décidez de signer la build ultérieurement, le .dsym généré avant la signature de code est toujours valide.

Versions et exigences prises en charge

Les détails de la version Xcode de la machine de build sont mis à jour chaque fois qu’une nouvelle version de Xcode est ajoutée. Nous gardons un œil sur les dernières versions publiées par Apple et les incluons dès que possible sur les machines virtuelles utilisées pour exécuter les builds.