Erstellen von Objective-C- oder Swift-Apps für iOS

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.

Um Ihre erste native iOS-App zu erstellen, müssen Sie die folgenden Aktionen ausführen:

1. Herstellen einer Verbindung mit Ihrem Repositorydienstkonto (GitHub, Bitbucket, VSTS, Azure DevOps)
2. Wählen Sie ein Repository und einen Branch aus, in dem sich Ihre App befindet.
3. Konfigurieren des Projekts oder Arbeitsbereichs des Builds und des Schemas, das Sie erstellen möchten

Hinweis

Um die App auf einem echten Gerät auszuführen, muss der Build Code sein, der mit einem gültigen Bereitstellungsprofil und einem Zertifikat signiert ist.

1. Verknüpfen Ihres Repositorys

Wenn Sie noch keine Verbindung mit Ihrem Repositorydienstkonto hergestellt haben, müssen Sie die Verbindung autorisieren. Nachdem Ihr Konto verbunden ist, wählen Sie das Repository aus, in dem sich Ihr iOS-Projekt befindet. App Center erfordert, dass Ihr Konto über die Berechtigung Admin und Pull verfügt, um einen Build für ein Repository einzurichten.

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

Konfigurieren Sie Ihr iOS-Projekt vor dem ersten Build.

3.1 Projekt/Arbeitsbereich und Schema

Für eine Buildkonfiguration sind ein Xcode-Projekt oder ein Xcode-Arbeitsbereich und ein freigegebenes Schema erforderlich. App Center erkennt automatisch die Projekte, Arbeitsbereiche und freigegebene Schemas (solange sich die Schemas im richtigen Ordner befinden) in Ihrem Branch. Wählen Sie das Projekt oder den Arbeitsbereich aus, den Sie erstellen möchten, und das entsprechende Schema.

Wenn kein Schema gefunden wird, stellen Sie sicher, dass das gewünschte Schema freigegeben ist und sein Container das ausgewählte Projekt oder Arbeitsbereich ist. Sie sollten auch sicherstellen, dass diese Änderungen in den Branch eingecheckt sind, den Sie konfigurieren.

Beachten Sie, dass Sie eine .xcscheme Datei nicht exportieren und an einer beliebigen Stelle im Projekt platzieren können. Es muss sich im xcshareddata/xcschemes/ Ordner befinden. Stellen Sie sicher, dass dieser Pfad nicht in Ihrer .gitignore Datei enthalten ist.

3.2. Xcode-Version

Wählen Sie die Xcode-Version aus, auf der der Build ausgeführt werden soll.

3.3. Buildtrigger

Standardmäßig wird jedes Mal ein neuer Build ausgelöst, wenn ein Entwickler pusht an einen konfigurierten Branch. Dieser Prozess wird als "Continuous Integration" bezeichnet. Wenn Sie einen neuen Build lieber manuell auslösen möchten, können Sie diese Einstellung in der Buildkonfiguration ändern.

3.4. Nummer des Inkrementbuilds

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

Hinweis

Damit die Inkrementbuildnummer funktioniert, nennen Sie die .plist file als *Info.plist solche Production-Info.plist.

3.5. Tests

Wenn das ausgewählte Schema eine Testaktion mit einem ausgewählten Testziel enthält, können Sie die Tests so konfigurieren, dass sie als Teil jedes Builds ausgeführt werden. App Center kann derzeit XCTest-Komponententests ausführen.

3.6. Codesignierung

Zum Erstellen einer iOS-App für reale Geräte muss sie mit gültigen Anmeldeinformationen signiert werden. Um Builds in App Center zu signieren, aktivieren Sie die Codesignatur im Konfigurationsbereich, und laden Sie ein Bereitstellungsprofil (.mobileprovision) 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. Weitere Informationen zur Codesignatur finden Sie in der offiziellen Apple Developer-Dokumentation.

Für Apps mit App- oder watchOS-Erweiterungen muss ein zusätzliches Bereitstellungsprofil pro Erweiterung signiert werden.

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

Verwenden Sie Ihre neu erstellte .ipa Datei, um zu testen, ob Ihre App auf einem echten Gerät gestartet wird. Der Start auf einem echten Gerät führt zu einer zusätzlichen Gesamtbuildzeit von ca. 10 Minuten. 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. Mit diesem Schritt wird sichergestellt, dass alle Abhängigkeiten installiert sind.

Warnung

Wenn das Repository bereits einen Ordner /Pods enthält, geht App Center davon aus, dass Sie die Pods in Ihrem Repository eingecheckt haben und nicht mehr ausführen pod install. Wenn Sie den Ordner /Pods entfernen oder ändern, müssen Sie die Buildkonfiguration möglicherweise manuell mit Save oder Save and Build neu speichern, damit das Update wirksam wird.

3.9. Verteilen an eine Verteilergruppe

Sie können jeden erfolgreichen Build aus einem Branch so konfigurieren, dass er an eine zuvor erstellte Verteilergruppe verteilt wird. Sie können eine neue Verteilergruppe im Abschnitt Verteilen hinzufügen. 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

Nachdem ein Build ausgelöst wurde, kann er sich in den folgenden Zuständen befinden:

• queued : Der Build wird in die Warteschlange gestellt, um auf die Freigabe von Ressourcen zu warten.
• Erstellen : Der Build führt die vordefinierten Aufgaben aus.
• erfolgreich : Der Build wurde abgeschlossen und war erfolgreich.
• fehler – der Build wurde abgeschlossen, aber fehler. Sie können probleme beheben, indem Sie die Buildprotokolle überprüfen.
• abgebrochen : Der Build wurde durch eine Benutzeraktion abgebrochen oder ein Timeout ausgeführt.

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 buildschrittspezifischen Protokolle (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 iOS-Geräteanwendung, die die iOS-App enthält.

• 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.
• Wenn der Build ordnungsgemäß signiert ist, kann die .ipa Datei auf einem realen Gerät installiert werden, das dem beim Signieren verwendeten Bereitstellungsprofil entspricht. Weitere Details zur Codesignatur und -verteilung mit App Center finden Sie in der Dokumentation zur iOS-Codesignatur von App Center.
• Wenn der Build nicht signiert wurde, kann die .ipa Datei vom Entwickler signiert (z. B. lokal mit Codesign) oder für andere Zwecke verwendet werden (z. B. hochladen in Testdienst für UI-Tests auf realen Geräten oder Ausführen im Simulator).

4.3. Die Symboldatei (.dsym)

Die .dsym Dateien enthalten die Debugsymbole für die App.

• Wenn Sie zuvor das App Center SDK in Ihre App integriert haben und das Modul für die Absturzberichterstattung aktiviert ist, benötigt der Absturzberichtsdienst diese .dsym Datei für einen Build, um lesbare (symbolische) Absturzberichte anzuzeigen.
• Wenn Sie zuvor ein anderes SDK für Absturzberichterstattungszwecke in Ihre App integriert haben (z. B. HockeyApp SDK), erfordert der entsprechende Dienst die .dsym Datei, um lesbare Absturzberichte anzuzeigen.

Beachten Sie, dass sich die .dsym Dateien nicht ändern, wenn der Code signiert wird .ipa. Wenn Sie sich entscheiden, den Build später mit einem Code zu signieren, ist die vor der .dsym Codesignatur generierte weiterhin gültig.

Unterstützte Versionen und Anforderungen

Die Xcode-Versionsdetails des Buildcomputers werden jedes Mal aktualisiert, wenn eine neue Version von Xcode hinzugefügt wird. Wir behalten die neuesten Versionen im Auge, die von Apple veröffentlicht werden, und fügen sie so bald wie möglich auf den virtuellen Computern ein, die zum Ausführen der Builds verwendet werden.