Teilen über

Erstellen von Xamarin-Apps für iOS

  • 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.

Hinweis

Unterstützte Versionen und Anforderungen App Center unterstützt PCL-Projekte (Portable Class Library) und .NET Standard . Versionen von .NET Standard finden Sie unter Cloud Build Machines . App Center unterstützt keine Komponenten aus dem Xamarin-Komponentenspeicher, und es wird empfohlen, NuGet-Pakete zu verwenden, wann immer verfügbar. Wenn Sie eine Komponente verwenden, die nicht ersetzt werden kann, wenden Sie sich an uns. Weitere Informationen finden Sie unter Hilfe und Feedback.

Um mit dem Erstellen Ihrer ersten Xamarin iOS-App zu beginnen, müssen Sie Folgendes ausführen:

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

Wenn Sie noch keine Verbindung mit Ihrem Repositorydienstkonto hergestellt haben, müssen Sie es herstellen. Nachdem Ihr Konto verbunden ist, wählen Sie das Repository aus, in dem sich Ihr iOS-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 Xamarin-Projekt konfiguriert werden.

3.1. Projekt/Projektmappe

App Center erkennt die Projektmappen- und Projektdateien in Ihrem Repository automatisch, wenn sie sich innerhalb des Analysebereichs befinden. Wählen Sie die .sln oder .csproj/.fsproj aus, die Sie erstellen möchten.

Hinweis

Um eine optimale Leistung zu erzielen, ist die Analyse derzeit auf zwei Verzeichnisebenen für .sln und vier Verzeichnisebenen für .csproj/fsproj beschränkt, einschließlich des Stammverzeichnisses Ihres Repositorys.

3.1.1. Erstellen aus der Projektmappendatei (.sln)

Stellen Sie in Ihrem Code sicher, dass Sie Android- und UWP-Projekte für Buildkonfigurationen deaktivieren, die für iOS-Builds vorgesehen sind. Wechseln Sie zu den Konfigurationszuordnungen der Lösung, und deaktivieren Sie für alle Zuordnungen, die auf iPhone und iPhoneSimulator abzielen, alle Projekte, die auf andere Plattformen abzielen. Durch diese Änderung wird sichergestellt, dass die .sln nicht versucht, die anderen Projekte zu erstellen. Es gibt weitere Informationen zur Zuordnung von Lösungskonfigurationen , die Sie lesen können.

3.1.2. Erstellen aus der Projektdatei (.csproj/.fsproj)

Um aus einer CSPROJ/FSPROJ-Datei zu erstellen, müssen alle Projekte, auf die verwiesen wird (z. B. Ihr PCL-Projekt), die Konfiguration mit demselben Namen wie die aus Ihrem iOS-Quellprojekt enthalten. Wenn Sie also die Debugkonfiguration für den Simulator in App Center ausführen, muss Ihr PCL-Projekt über die Debug|iPhoneSimulator-Konfiguration verfügen. Falls sie nicht vorhanden sind und um weitere Fehler zu vermeiden, fügen wir diese Konfigurationen vor dem Erstellen Ihrer Projekte hinzu. Diese Konfigurationen verfügen nur über grundlegende Standardeinstellungen für Debug und Release.

3.2. Konfiguration

Wählen Sie die Konfiguration aus, mit der Sie erstellen möchten. Die Konfigurationen werden automatisch erkannt, abhängig von der Quelldatei, die im vorherigen Schritt ausgewählt wurde.

3.3. Mono-Version

App Center ermöglicht die Verwendung verschiedener Mono-Umgebungen, die mit dem jeweiligen Xamarin.iOS SDK für Ihren Build gebündelt sind, um die Abwärtskompatibilität zu gewährleisten und gleichzeitig unterstützung für neue Features zu veröffentlichen. Der Mono-Standard für eine neue Branchkonfiguration ist die neueste stabile Konfiguration. Sie können eine der vorherigen Mono-Umgebungen verwenden, um ältere Versionen von Frameworks oder Bibliotheken zu erstellen. Wenn Sie eine andere Mono-Version auswählen, wird die Xamarin.iOS SDK-Version angezeigt, die im Lieferumfang enthalten ist. Um Xamarin SDK-Versionsupdates nachzuverfolgen, können Sie Beiträge im Blog zur Xamarin-Version lesen.

3.3.1. .NET-Version

Die richtige .NET-Version wird automatisch basierend auf der für den Build verwendeten Xamarin.iOS-Version ausgewählt und kann nicht überschrieben werden. Sie können die Zuordnung von Xamarin.iOS zu dem von unseren Diensten verwendeten .NET in der folgenden Tabelle anzeigen:

Xamarin.iOS .NET
13.20 3.1.401
14,0 3.1.401
14.2 3.1.401
14.4 3.1.401
14.6 5.0.100
14.8 5.0.100
14.10 5.0.100
14,14 5.0.100
14.16 5.0.100
14,20 5.0.100
15 5.0.100
15.2 5.0.100
15.4 5.0.100
15,6 5.0.100
15.8 5.0.100
15.10 5.0.100
15.12 5.0.100
16,0 5.0.100
16.0 (.NET 6) 6.0.405
16.1 6.0.405
16.2 6.0.405

3.4. Xcode-Version

Derzeit unterstützte Versionen von Xamarin erfordern Xcode 11.7 oder höher

3.5. 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.6. Simulatorbuild

Simulatorbuilds können nur in Simulatoren ausgeführt und nicht auf dem Gerät installiert werden, aber die Builds werden schneller abgeschlossen als Gerätebuilds. Wenn Es sich bei Ihrem Build nicht um einen Simulatorbuild handelt, müssen Sie im nächsten Schritt Codesignaturdateien hochladen.

3.7. 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.8. Codesignierung

Ein erfolgreicher Gerätebuild erzeugt eine IPA-Datei. Um den Build auf einem Gerät zu installieren, muss er 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) und ein gültiges Zertifikat (.p12) zusammen mit dem Kennwort für das Zertifikat hoch. Weitere Informationen zur Codesignatur und Gerätebereitstellung von Xamarin iOS-Apps finden Sie in der Xamarin-Dokumentation.

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

Hinweis

Bei der Ausführung nuget restore in Projekten, die Xamarin watchOS-Apps enthalten, tritt ein Problem auf. Das Erstellen einer watchOS-App im App Center ohne Problemumgehung führt zu einem Fehler:

Project <project> is not compatible with xamarinios10 (Xamarin.iOS,Version=v1.0) / win-x86. Project <project> supports: xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0).

Zum Erstellen von watchOS-Apps in App Center ist eine Problemumgehung erforderlich. Innerhalb des enthaltenden iOS-Projekts, das auf die Watch-App verweist, muss eine zusätzliche Zeile enthalten sein:

<ReferenceOutputAssembly>False</ReferenceOutputAssembly>

Beispiel für watchApp-Referenz mit Problemumgehung:

    <ProjectReference Include="..\MyWatchApp\MyWatchApp.csproj">
      <Project>{59EB034F-3D29-43A5-B89F-124879504771}</Project>
      <Name>MyWatchApp</Name>
      <IsWatchApp>True</IsWatchApp>
      <ReferenceOutputAssembly>False</ReferenceOutputAssembly>
    </ProjectReference>

3.9. 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 Starttest erhöht die Buildzeit um etwa zehn Minuten. Sie sollten sich eine umfassendere Anleitung zum Testen Ihrer Builds ansehen.

3.10. NuGet-Wiederherstellung

Wenn die NuGet.config-Datei für das Repository eingecheckt ist und sich neben der .sln oder der Stammebene Ihres Repositorys befindet, stellt App Center Ihre privaten NuGet-Feeds wieder her, wenn sie wie im folgenden Beispiel gezeigt hinzugefügt werden. Anmeldeinformationen können mithilfe von Umgebungsvariablen sicher hinzugefügt werden:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="MyGet" value="https://www.myget.org/F/MyUsername/api/v2/index.json" />
    <add key="MyAuthNuget" value="https://nuget.example.com/v2/index.json" />
  </packageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
  <packageSourceCredentials>
    <MyAuthNuget>
      <add key="Username" value="$USER_VARIABLE" />
      <add key="ClearTextPassword" value="$PASSWORD_VARIABLE" />
    </MyAuthNuget>
  </packageSourceCredentials>
</configuration>

Wenn Sie über komplexe Konfigurationen verfügen und weitere Informationen benötigen, lesen Sie Konfigurieren des NuGet-Verhaltens.

3.11. 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 befindet sich in einer Warteschlange, die darauf wartet, dass Ressourcen freigegeben werden.
  • building : Der Build wird ausgeführt und die vordefinierten Aufgaben ausgeführt.
  • erfolgreich : Der Build wurde erfolgreich abgeschlossen.
  • fehler: Der Build wurde aufgrund eines Fehlers beendet. Sie können Probleme beheben, indem Sie das Buildprotokoll herunterladen und überprüfen.
  • abgebrochen : Der Build wurde durch eine Benutzeraktion abgebrochen oder ein Timeout festgelegt.

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 oder .app)

Bei .ipa handelt es sich um eine iOS-Anwendungsarchivdatei, die die iOS-App enthält. Wenn der Build ordnungsgemäß signiert wurde, kann der .ipa auf einem realen Gerät installiert werden, entsprechend dem beim Signieren verwendeten Bereitstellungsprofil. Es gibt weitere Details zur Codesignatur und -verteilung mit App Center.

Wenn es sich bei der App um einen Simulatorbuild handelt, können Sie die .app Datei in einem Simulator ausführen, aber nicht auf einem echten Gerät verwenden.

4.3. Die Symboldateien (.dsym)

Symboldateien werden nur für Gerätebuilds generiert. Die DSYM-Dateien enthalten die Debugsymbole für die App.

  • Wenn das App Center SDK zuvor in Ihre App integriert wurde und das Absturzberichtsmodul 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 die Absturzberichterstattung in Ihre App integriert haben (z. B. HockeyApp SDK), benötigt der entsprechende Dienst die .dsym Datei, um lesbare Absturzberichte anzuzeigen.