Erstellen von Objective-C- oder Swift-Apps für macOS
Führen Sie die folgenden Schritte aus, um mit dem Erstellen Ihrer ersten Mac-App zu beginnen:
- Stellen Sie eine Verbindung mit Ihrem Repositorydienstkonto her (GitHub, Bitbucket, VSTS, Azure DevOps).
- Wählen Sie ein Repository und einen Branch aus, in dem sich Ihre App befindet.
- 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 codesigniert sein, der mit einem Zertifikat signiert ist. 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 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 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 freigegebene Schemas in Ihrem Branch. Wählen Sie das Projekt oder den Arbeitsbereich aus, das 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.
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, wenn ein Entwickler pusht, ein neuer Build an einen konfigurierten Branch 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. Nummer des Inkrementbuilds
Wenn aktiviert, werden die CFBundleVersion
in der Info.plist Ihrer App automatisch für jeden Build inkrementiert. Die Änderung erfolgt vor dem Build und wird nicht für Ihr Repository festgelegt.
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. 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 er 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 optional für die Codesignatur.
Derzeit unterstützt App Center nur die folgenden Signaturkonfigurationen:
- Manuelles Signieren mit der Exportmethode "Entwicklung" nur mit einem Entwicklungszertifikat
- Manuelles Signieren mithilfe 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 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.
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 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 befindet sich in einer Warteschlange und wartet darauf, dass ressourcenfrei sind.
- Erstellen : Der Build führt die vordefinierten Aufgaben aus.
- erfolgreich : Der Build wurde erfolgreich abgeschlossen.
- Fehler : Beim Build wurden Fehler gefunden, die den Abschluss verhinderten. Sie können Probleme mit dem Build beheben, indem Sie die Buildprotokolle herunterladen und überprüfen.
- abgebrochen : Der Build wurde von einer 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 die Funktionsweise des Builds 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 (.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 Details zur Codesignatur und -verteilung mit App Center finden Sie in der Dokumentation zur macOS-Codesignatur 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 hinzugefügt 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 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 .app
nicht geändert. Wenn Sie sich entscheiden, den Build später mit einem Code zu signieren, ist die vor der .dsym
Codesignatur generierte weiterhin gültig.
Erstellen von Internen
Zum Erstellen Ihres Projekts verwenden xcodebuild
wir 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, die von Apple veröffentlicht wurden, so bald wie möglich auf unseren Build-VMs ein.