Auf Englisch lesen

Freigeben über


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

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 eine Migration in Betracht ziehen können.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

Führen Sie die folgenden Schritte aus, um mit dem Erstellen Ihrer ersten Mac-App zu beginnen:

  1. Stellen Sie eine Verbindung mit Ihrem Repositorydienstkonto her (GitHub, Bitbucket, VSTS, Azure DevOps).
  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 verteilt werden kann, muss der Build mit einem Zertifikat signiert sein. Ein Bereitstellungsprofil ist optional. Darüber hinaus wird build for Mac Installers derzeit nicht unterstützt.

1. Verknüpfen Ihres Repositorys

Sie müssen eine Verbindung mit Ihrem Repositorydienstkonto herstellen. Nachdem Ihr Konto verbunden ist, wählen Sie das Repository aus, in dem sich Ihr Mac-Projekt befindet. Um einen Build für ein Repository einzurichten, benötigen Sie administrator- und Pullberechtigungen dafür.

2. Auswählen einer Verzweigung

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 Ihres ersten Builds

Vor dem ersten Build muss das Mac-Projekt konfiguriert werden.

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 freigegebenen Schemas in Ihrem Branch. Wählen Sie das Projekt oder den Arbeitsbereich aus, das Bzw. den Sie erstellen möchten, und das entsprechende Schema.

Wenn kein Schema gefunden werden kann, vergewissern Sie sich, dass das Schema, mit dem Sie erstellen möchten, freigegeben ist und der Container für das Schema entweder das Projekt oder der ausgewählte Arbeitsbereich ist. Stellen Sie außerdem sicher, dass diese Änderungen in dem Branch eingecheckt sind, für den Sie den Build einrichten.

Schema als freigegeben markieren

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 bei jedem Pushvorgang eines Entwicklers in einen konfigurierten Branch ein neuer Build ausgelöst. Dies 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. Buildnummer inkrementieren

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

3.5. Tests

Wenn für das ausgewählte Schema eine Testaktion mit ausgewähltem Testziel vorhanden ist, können Sie die Tests so konfigurieren, dass sie als Teil jedes Builds ausgeführt werden. App Center kann derzeit XCTest-Komponententests ausführen. App Center unterstützt keine Starttests für Mac-Builds.

3.6. Codesignierung

Ein erfolgreicher Build erzeugt eine .app Datei. Um den Build auf einem Gerät zu installieren, muss es ein signiertes Zertifikat sein. Um die aus einem Branch erstellten Builds zu signieren, aktivieren Sie die Codesignatur im Konfigurationsbereich, und laden Sie 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. Ein Bereitstellungsprofil ist für die Codesignierung optional.

Derzeit unterstützt App Center nur die folgenden Signaturkonfigurationen:

  • Manuelles Signieren mit der Entwicklungsexportmethode nur mit einem Entwicklungszertifikat
  • Manuelles Signieren mit der Exportmethode der Entwickler-ID
  • Automatisches Signieren mithilfe der Exportmethode "Entwicklung"

Weitere Informationen zur Codesignatur finden Sie im MacOS-Codesignaturhandbuch von App Center und im offiziellen Apple-Entwicklerhandbuch.

3.7. CocoaPods

App Center überprüft den ausgewählten Branch, und wenn eine Podfile gefunden wird, wird automatisch ein pod install Schritt am Anfang jedes Builds ausgeführt. Dadurch wird sichergestellt, dass alle Abhängigkeiten installiert sind.

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.

3.8. Verteilen an eine Verteilergruppe

Sie können jeden erfolgreich signierten 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 enthält, die Zugriff auf die App haben.

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

4. Erstellen von Ergebnissen

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

  • queued : Der Build befindet sich in der Warteschlange und wartet darauf, dass ressourcenfrei sind.
  • Building : Der Build führt die vordefinierten Tasks aus.
  • erfolgreich : Der Build wurde erfolgreich abgeschlossen.
  • fehler : Der Build hat Fehler gefunden, die den Abschluss verhinderten. Sie können probleme mit dem Build beheben, indem Sie die Buildprotokolle herunterladen und überprüfen.
  • canceled : Der Build wurde von einer Benutzeraktion abgebrochen oder ein Timeout aufgetreten.

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 spezifischen Protokolle für Buildschritte (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 (.app)

Die .app Datei ist eine Mac-Anwendungsarchivdatei, die die Mac-App enthält.

  • Wenn der Build ordnungsgemäß signiert ist, kann die .app Datei auf einem Gerät installiert werden, das dem beim Signieren verwendeten Bereitstellungsprofil entspricht. Weitere Informationen zur Codesignierung und Verteilung mit App Center finden Sie in der MacOS-Codesignaturdokumentation von App Center.
  • Wenn der Build nicht signiert wurde, kann die .app Datei vom Entwickler signiert werden. Beispiel: Codesign.

4.3. Die Symboldatei (.dsym)

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

  • Wenn Sie das App Center SDK in Ihrer App mit aktiviertem Modul für die Absturzberichterstattung hinzugefügt haben, benötigt der Absturzberichtsdienst diese .dsym Datei für einen Build, um für Menschen lesbare (symbolische) Absturzberichte anzuzeigen.
  • Wenn Sie in Ihrer App ein weiteres SDK für die Absturzberichterstattung hinzugefügt haben, z. B. das HockeyApp SDK, benötigt der Dienst die .dsym Datei, um lesbare Absturzberichte anzuzeigen.

Die .dsym Dateien werden beim Signieren von .appnicht geändert. Wenn Sie sich dazu entscheiden, den Build später mit einem Code zu signieren, wird die generiert, bevor die .dsym Codesignatur noch gültig ist.

Erstellen von Internen

Zum Erstellen Ihres Projekts verwenden xcodebuildwir ein Befehlszeilentool, mit dem Sie Ihre Xcode-Projekte und Arbeitsbereiche erstellen, abfragen, analysieren, testen und archivieren können.

Unterstützte Versionen und Anforderungen

Buildcomputerversionsdetails werden jedes Mal aktualisiert, wenn eine neue Version von macOS hinzugefügt wird. Wir schließen die neuesten Versionen von Apple so schnell wie möglich auf unseren Build-VMs ein.