Konfigurieren eines React Native iOS-Builds in App Center

  • Artikel

Wichtig

Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie möglicherweise eine Migration in Erwägung ziehen.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

App Center kann React Native Apps erstellen, die in React Native Version 0.34 oder höher geschrieben wurden.

So erstellen Sie eine React Native-App für iOS:

  1. Stellen Sie eine Verbindung mit Ihrem Repositorydienstkonto her (z. B. Azure DevOps, Bitbucket, GitHub oder VSTS).
  2. Wählen Sie ein Repository und einen Branch aus, in dem sich Ihre App befindet.
  3. Konfigurieren Sie das Projekt oder den Arbeitsbereich des Builds und das Schema, das Sie erstellen möchten.

Hinweis

Damit die App auf einem realen Gerät ausgeführt werden kann, muss der Build codesigniert sein, der mit einem gültigen Bereitstellungsprofil und einem Zertifikat signiert ist.

1. Verknüpfen Ihres Repositorys

Verbinden Sie zunächst Ihr Repositorydienstkonto mit App Center. Nachdem Ihr Konto verbunden ist, wählen Sie das Repository aus, in dem sich Ihr iOS-Projekt befindet. Sie müssen über Administrator- und Pullberechtigungen für das Repository verfügen.

2. Auswählen eines Zweigs

Nachdem Sie ein Repository ausgewählt haben, wählen Sie den Branch aus, den Sie erstellen möchten. Standardmäßig werden alle aktiven Branches aufgelistet.

3. Einrichten Des ersten Builds

Vor dem ersten Build muss das React Native-Projekt konfiguriert werden.

3.1. Project

Wählen Sie das Projekt aus package.json. App Center erkennt automatisch das zugeordnete Xcode-Projekt/-Arbeitsbereich.

3.2. Xcode-Version

Wählen Sie in der Dropdownliste die Xcode-Version aus, auf der der Build ausgeführt werden soll. Wenn die Umschaltfläche "Legacybuildsystem verwenden" lautet On, wird das Legacybuildsystem unabhängig von den Projekt- oder Arbeitsbereichseinstellungen verwendet. Wenn das Umschaltzeichen "Legacybuildsystem verwenden" lautet Off, wird die Buildsystemkonfiguration aus den Projekt- oder Arbeitsbereichseinstellungen verwendet.

Hinweis

  • Die Arbeitsbereichseinstellung sollte für das Repository festgelegt werden.
  • Wenn die Arbeitsbereichseinstellung nicht festgelegt wurde, wird das moderne Buildsystem verwendet.

3.3. Node.js-Version

Wählen Sie die Node.js Version aus, die für den Build verwendet werden soll. Weitere Informationen zum Auswählen Node.js Version

3.4. Buildtrigger

Standardmäßig wird jedes Mal ein neuer Build ausgelöst, wenn ein Entwickler pusht an einen konfigurierten Branch. Wenn Sie einen neuen Build lieber manuell auslösen möchten, können Sie diese Einstellung im Konfigurationsbereich ändern.

3.5. Nummer des Inkrementbuilds

Wenn aktiviert, wird die CFBundleVersion in der Info.plist-Liste Ihrer App des Projekts automatisch für jeden Build erhöht. Die Änderung erfolgt vor dem Build und wird nicht für Ihr Repository festgelegt.

3.6. Codesignierung

Ein erfolgreicher Build erzeugt eine .ipa Datei. Um den Build auf einem Gerät zu installieren, muss der Build mit einem gültigen Bereitstellungsprofil und zertifikat signiert werden. Um die aus einem Branch erstellten Builds zu signieren, aktivieren Sie die Codesignatur im Konfigurationsbereich, und laden Sie ein Bereitstellungsprofil (.mobileprovision Datei) und ein gültiges Zertifikat (P12) zusammen mit dem Kennwort für das Zertifikat hoch.

Die Einstellungen in Ihrem Xcode-Projekt müssen mit den dateien kompatibel sein, die Sie hochladen. Erfahren Sie mehr über die iOS-Codesignatur von App Center und die Apple Developer-Dokumentation.

Das Signieren von Apps mit App- oder watchOS-Erweiterungen erfordert ein zusätzliches Bereitstellungsprofil pro Erweiterung.

3.7. Starten Sie Ihren erfolgreichen Build auf einem echten Gerät

Verwenden Sie die neu erstellte .ipa Datei, um zu testen, ob Ihre App auf einem echten Gerät gestartet wird. Der Starttest fügt der Gesamtbuildzeit etwa zehn Minuten mehr hinzu. Weitere Informationen zum Konfigurieren von Starttests finden Sie hier.

3.8. CocoaPods

App Center scannt den ausgewählten Branch und führt automatisch einen Schritt am Anfang jedes Builds durch pod install , wenn es eine Podfile-Datei findet. Dadurch wird sichergestellt, dass alle Abhängigkeiten installiert werden.

3.9. Verteilen an eine Verteilergruppe

Konfigurieren Sie jeden erfolgreichen Build aus einem Branch so, dass er an eine zuvor erstellte Verteilergruppe verteilt wird. Fügen Sie im Abschnitt Verteilen eine neue Verteilergruppe hinzu. Es gibt immer eine Standardverteilergruppe namens "Collaborators", die alle Benutzer umfasst, die Zugriff auf die App haben.

Nachdem Sie die Konfiguration gespeichert haben, wird automatisch ein neuer Build gestartet.

4. Ergebnisse erstellen

Builds können sich in einem der folgenden Zustände befinden:

  • in die Warteschlange gestellt: Der Build wird in die Warteschlange gestellt, um auf verfügbare Ressourcen zu warten.
  • Erstellen : Der Build führt vordefinierte Aufgaben aus und führt sie aus.
  • erfolgreich : Der Build wurde erfolgreich abgeschlossen
  • Fehler : Der Build wurde nicht erfolgreich abgeschlossen. Problembehandlung bei Fehlern durch Herunterladen und Überprüfen des Buildprotokolls
  • abgebrochen : Der Build wurde durch Benutzeraktion abgebrochen oder timeouts

4.1. Buildprotokolle

Laden Sie für einen abgeschlossenen Build (erfolgreich oder fehlgeschlagen) die Protokolle herunter, um mehr über den Buildvorgang zu erfahren. App Center stellt ein Archiv mit den folgenden Dateien bereit:

|-- 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)

Die Buildprotokolle (im build/ Verzeichnis des Archivs) sind hilfreich, um die Problembehandlung zu beheben und zu verstehen, in welchem Schritt und warum der Buildfehler aufgetreten ist.

4.2. Die App (IPA)

Die .ipa Datei ist eine Archivdatei der iPhone-Anwendung, die die iOS-App enthält.

  • Wenn der Build ordnungsgemäß signiert wurde, können Sie die .ipa Datei auf einem echten Gerät installieren, das in dem beim Signieren verwendeten Bereitstellungsprofil enthalten ist. Weitere Details zur Codesignatur und -verteilung mit App Center finden Sie in der Dokumentation zur iOS-Codesignatur von App Center.
  • Wenn der Build während des Builds nicht signiert wird, können Entwickler die .ipa Datei signieren (lokal mithilfe von Codesign) oder für andere Zwecke (z. B. hochladen in Testdienst für UI-Tests auf realen Geräten oder Ausführen im Simulator).
  • Nicht signierte Builds erzeugen .ipa keine Datei. Das Artefakt eines nicht signierten Builds ist die Datei, mit der .xcarchive eine .ipa Datei mit dem Xcode Archives-Organizer generiert werden kann.

4.3. Die Quellzuordnungs- und Symboldateien

Beim Erstellen einer React Native iOS-App werden eine JavaScript-Quellübersicht und eine oder mehrere .dsym Dateien automatisch mit jedem Build generiert und können heruntergeladen werden, sobald der Build abgeschlossen ist.

  • Wenn Sie zuvor das App Center SDK in Ihre App integriert haben und das Absturzberichtsmodul aktiviert ist, erfordert das Absturzberichts-Beacon diese .dsym Datei und die JavaScript-Quellübersicht für einen Build, um für Menschen lesbare (symbolische) Absturzberichte anzuzeigen.
  • wenn Sie zuvor ein anderes SDK für Absturzberichterstattungszwecke in Ihre App integriert haben, benötigt der entsprechende Dienst die .dsym Datei und die JavaScript-Quellzuordnung, um lesbare (symbolische) Absturzberichte anzuzeigen.

Beachten Sie, dass sich die .dsym Datei beim Signieren von .ipanicht ändert. Wenn Sie sich entscheiden, den Build später mit einem Code zu signieren, ist die vor der .dsym Codesignatur generierte weiterhin gültig.

Wenn für diese App das SDK für Abstürze enthalten ist, werden iOS-Symbole und Quellzuordnungen an den App Center Crashes-Dienst gesendet. Die Symbole ermöglichen lesbare (symbolische) Absturzberichte sowohl im nativen Als auch im JavaScript-Stapel.

5. Tipps zum Erstellen

5.1. Yarn

Yarn ist ein schnellerer, deterministischerer Ersatz für npm. Wenn eine yarn.lock Datei in Ihrem Repository neben package.jsonvorhanden ist, verwendet App Center Yarn, und dies yarn install zu Beginn des Builds. Andernfalls erfolgt dies npm install.

5.2. Benutzerdefinierte Buildskripts

Es gibt mehrere Optionen zum Ausführen von Skripts, bevor die Standardmäßigen Buildbefehle von App Center ausgeführt werden.

  • Erstellen Sie ein Postinstallationsskript in der package.json Datei Ihres Projekts. Dies wird automatisch ausgeführt, nachdem Ihre Abhängigkeiten installiert wurden.

      "scripts": {
    ...
    "postinstall" : "eslint ./" // other examples: "node ./postinstall.js" or "./postinstall.sh"
  },

  • Schreiben Sie ein Shellskript mithilfe der benutzerdefinierten Buildskripts-Funktionalität von App Center.

    #!/usr/bin/env bash

# Example: Authenticate with private NPM registry
echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc

# Example: Create a file that's not in version control (from base64 encoded environment variable)
base64 -d <<< "$MY_FILE_CONTENTS" > ios/SuperSecretFile.txt