.NET MAUI 10 App Store Guide (2026)

Warum das Deployment der letzte große Stolperstein ist

Die App ist fertig. ViewModels sauber getestet, Navigation läuft, Performance stimmt. Alles gut — bis zu dem Moment, wo es wirklich ernst wird: die Veröffentlichung im App Store und bei Google Play.

Und mal ehrlich, genau hier geraten viele Entwickler ins Schwitzen. Was auf dem lokalen Emulator einwandfrei funktioniert, muss erst Apples Review-Team und Googles Prüfprozess überstehen. Zertifikate, Provisioning Profiles, Privacy Manifests, ständig wechselnde API-Level-Anforderungen — die Liste ist lang.

Dieser Leitfaden führt Sie durch den kompletten Deployment-Prozess für .NET MAUI 10 im Jahr 2026. Von der Vorbereitung übers Signieren und Hochladen bis zur CI/CD-Automatisierung mit GitHub Actions — alles drin, was Sie brauchen, um Ihre App zuverlässig in die Stores zu bringen.

Voraussetzungen und Vorbereitung

Bevor Sie den ersten Build starten, müssen ein paar Grundlagen stimmen. Die Vorbereitung entscheidet oft darüber, ob die Veröffentlichung glatt durchläuft — oder in einer nervigen Endlosschleife aus Ablehnungen und kryptischen Fehlermeldungen endet.

Entwickler-Konten einrichten

Für beide Plattformen brauchen Sie ein Entwickler-Konto:

Apple Developer Program: Kostet 99 USD pro Jahr. Ohne Mitgliedschaft können Sie weder Apps im App Store veröffentlichen noch Distribution-Zertifikate erstellen. Die Registrierung erfolgt unter developer.apple.com.
Google Play Developer-Konto: Einmalige Gebühr von 25 USD. Die Registrierung läuft über die Google Play Console. Planen Sie ein paar Tage Wartezeit ein — Google verifiziert die Identität neuer Konten, und das dauert manchmal.

.NET 10 und Workloads aktualisieren

.NET MAUI 10 wird als .NET-Workload plus mehrere NuGet-Pakete ausgeliefert. Stellen Sie sicher, dass die aktuelle Version installiert ist:

dotnet workload update
dotnet workload install maui

Kurzer Check der installierten Version:

dotnet workload list

Für iOS-Builds brauchen Sie außerdem einen Mac mit aktueller Xcode-Version (mindestens Xcode 16). Da führt leider kein Weg dran vorbei — die Erstellung nativer iOS-Apps geht nur mit Apples eigenen Build-Tools.

Projektdatei für Release vorbereiten

Ihre .csproj-Datei muss korrekte Metadaten für beide Plattformen enthalten. Hier die wichtigsten Einstellungen:

<PropertyGroup>
  <TargetFrameworks>net10.0-android;net10.0-ios</TargetFrameworks>
  <ApplicationTitle>MeineApp</ApplicationTitle>
  <ApplicationId>com.meinefirma.meineapp</ApplicationId>
  <ApplicationDisplayVersion>1.0.0</ApplicationDisplayVersion>
  <ApplicationVersion>1</ApplicationVersion>
</PropertyGroup>

Ganz wichtig: Die ApplicationId muss auf beiden Plattformen identisch mit dem registrierten Bundle Identifier bzw. Package Name sein. Nachträgliche Änderungen? Nicht möglich. Also lieber einmal richtig machen.

Android: Veröffentlichung im Google Play Store

Die Android-Seite ist erfahrungsgemäß der leichtere Einstieg. Kein Mac nötig, keine komplizierten Provisioning Profiles. Aber ein paar Fallstricke gibt's trotzdem.

API Level 36 — die Anforderung für 2026

Ab dem 31. August 2026 müssen alle neuen Apps und Updates im Google Play Store mindestens Android 16 (API Level 36) als Target-SDK verwenden. .NET MAUI 10 unterstützt API Level 35 und 36 nativ — Sie müssen also nur das richtige Target-Framework in der Projektdatei setzen:

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">
  <SupportedOSPlatformVersion>21</SupportedOSPlatformVersion>
  <TargetPlatformVersion>36</TargetPlatformVersion>
</PropertyGroup>

Apps, die das API-Level nicht erfüllen, werden für Nutzer auf neueren Android-Geräten schlicht unsichtbar. Und das betrifft nicht nur Neuinstallationen — auch Updates für Bestandskunden werden blockiert.

Keystore erstellen und App signieren

Jede Android-App muss vor dem Upload digital signiert werden. Den Keystore erstellen Sie mit dem JDK-Tool keytool:

keytool -genkeypair -v -keystore meineapp-release.keystore \
  -alias meineapp -keyalg RSA -keysize 2048 -validity 10000 \
  -storepass IhrSicheresPasswort -keypass IhrSicheresPasswort

Bewahren Sie den Keystore unbedingt sicher auf! Ohne diesen Schlüssel können Sie keine Updates mehr veröffentlichen. Ein verlorener Keystore bedeutet im schlimmsten Fall: komplett neue App anlegen, neue Package-ID, und alle bisherigen Bewertungen und Nutzer sind weg. Das will niemand.

Die Signierung konfigurieren Sie in der Projektdatei:

<PropertyGroup Condition="$(TargetFramework.Contains('-android')) and '$(Configuration)' == 'Release'">
  <AndroidKeyStore>true</AndroidKeyStore>
  <AndroidSigningKeyStore>meineapp-release.keystore</AndroidSigningKeyStore>
  <AndroidSigningKeyAlias>meineapp</AndroidSigningKeyAlias>
  <AndroidSigningKeyPass>IhrSicheresPasswort</AndroidSigningKeyPass>
  <AndroidSigningStorePass>IhrSicheresPasswort</AndroidSigningStorePass>
</PropertyGroup>

Release-Build erstellen (AAB-Format)

Google Play verlangt seit Jahren das Android App Bundle (AAB) statt einer klassischen APK-Datei. Der Vorteil: Google Play generiert daraus optimierte APKs für jede Gerätekonfiguration, was kleinere Downloads für Ihre Nutzer bedeutet.

Den Release-Build erstellen Sie über die Kommandozeile:

dotnet publish -f net10.0-android -c Release

Die fertige AAB-Datei finden Sie unter bin/Release/net10.0-android/publish/. Alternativ geht das Ganze auch über Visual Studio: Rechtsklick auf das Projekt, dann Veröffentlichen und Google Play wählen.

Upload in die Google Play Console

Der erste Upload muss manuell über die Google Play Console erfolgen — so stellt Google sicher, dass die Signatur künftiger Updates verifiziert werden kann. Die Schritte im Überblick:

Melden Sie sich in der Google Play Console an.
Erstellen Sie eine neue App und füllen Sie die Pflichtangaben aus (Titel, Beschreibung, Screenshots, Datenschutzerklärung).
Navigieren Sie zu Release > Produktion und laden Sie die AAB-Datei hoch.
Konfigurieren Sie die App-Signierung durch Google Play — Google verwaltet dann den Upload-Schlüssel und generiert die Release-Signatur.
Vervollständigen Sie das Dashboard: Inhaltsbewertung, Zielgruppe, Datensicherheitsformular und Kontaktdaten.
Senden Sie die App zur Überprüfung.

Die Erstprüfung durch Google dauert in der Regel ein paar Tage. Nachfolgende Updates werden dann deutlich schneller freigegeben — meistens innerhalb weniger Stunden.

iOS: Veröffentlichung im Apple App Store

Jetzt wird's etwas anspruchsvoller. Apples Ökosystem verlangt mehrere Zertifikate und Profile, die alle korrekt zusammenspielen müssen. Das klingt erstmal abschreckend, aber nach der Ersteinrichtung läuft der Prozess erstaunlich zuverlässig.

Zertifikat und Provisioning Profile erstellen

Um eine iOS-App zu signieren, brauchen Sie drei Dinge:

Distribution-Zertifikat: Bestätigt Ihre Identität als Entwickler. Erstellen Sie es im Apple Developer Portal unter Certificates, Identifiers & Profiles.
App-ID: Eine eindeutige App-ID, die mit der ApplicationId in Ihrer .csproj-Datei übereinstimmen muss.
Distribution Provisioning Profile: Verknüpft Zertifikat und App-ID miteinander. Wählen Sie bei der Erstellung den Typ App Store.

Installieren Sie das Zertifikat im Schlüsselbund und laden Sie das Provisioning Profile herunter. Visual Studio erkennt beides automatisch, wenn es korrekt installiert ist.

Privacy Manifest — Pflicht seit 2024

Apple verlangt seit Mai 2024 ein Privacy Manifest (PrivacyInfo.xcprivacy) in jeder iOS-App. Ohne dieses Manifest wird Ihre App bei der Einreichung abgelehnt — da gibt es keine Ausnahme.

Jede .NET MAUI-App benötigt mindestens die folgenden Einträge, weil das .NET-Runtime und die BCL (Base Class Library) sogenannte Required Reason APIs verwenden:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>NSPrivacyTracking</key>
  <false/>
  <key>NSPrivacyTrackingDomains</key>
  <array/>
  <key>NSPrivacyCollectedDataTypes</key>
  <array/>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>CA92.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>3B52.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>35F9.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>7D9E.1</string></array>
    </dict>
  </array>
</dict>
</plist>

Speichern Sie diese Datei als Platforms/iOS/PrivacyInfo.xcprivacy und registrieren Sie sie in der Projektdatei:

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier(
    '$(TargetFramework)')) == 'ios'">
  <BundleResource
    Include="Platforms\iOS\PrivacyInfo.xcprivacy"
    LogicalName="PrivacyInfo.xcprivacy" />
</ItemGroup>

Falls Ihre App zusätzliche APIs nutzt oder Daten sammelt, müssen Sie die entsprechenden Einträge ergänzen. Drittanbieter-SDKs bringen übrigens oft eigene Privacy Manifests mit, die Xcode beim Build automatisch zusammenführt.

Release-Build und IPA erstellen

Der iOS-Release-Build muss auf einem Mac (oder über einen Remote-Mac) erfolgen:

dotnet publish -f net10.0-ios -c Release \
  -p:ArchiveOnBuild=true \
  -p:CodesignKey="Apple Distribution: Ihre Firma (TEAMID)" \
  -p:CodesignProvision="MeineApp AppStore Profile"

Die erzeugte IPA-Datei liegt unter bin/Release/net10.0-ios/publish/. In Visual Studio für Mac können Sie den Archivierungsprozess auch grafisch durchführen — das ist manchmal übersichtlicher.

Upload über App Store Connect

Bevor Sie die IPA-Datei hochladen, brauchen Sie einen Eintrag in App Store Connect:

Melden Sie sich bei appstoreconnect.apple.com an.
Erstellen Sie einen neuen App-Eintrag mit Bundle-ID, Name und primärer Sprache.
Füllen Sie alle Pflichtfelder aus: Beschreibung, Keywords, Screenshots für verschiedene Geräte, App-Kategorie und Altersfreigabe.

Laden Sie die IPA über den Transporter (macOS-App) oder xcrun altool hoch:

xcrun altool --upload-app \
  --type ios \
  --file MeineApp.ipa \
  --apiKey IHR_API_KEY \
  --apiIssuer IHR_ISSUER_ID

Wählen Sie den Build in App Store Connect und senden Sie die App zur Überprüfung.

Apples Review dauert typischerweise 24 bis 48 Stunden. Die häufigsten Ablehnungsgründe? Fehlende Privacy-Angaben, kaputte Links in der Datenschutzerklärung und vergessene Login-Testdaten für den Reviewer. Lässt sich alles vermeiden, wenn man vorher die Checkliste durchgeht (dazu weiter unten mehr).

CI/CD-Pipeline mit GitHub Actions automatisieren

Manuelles Signieren, Bauen und Hochladen funktioniert — ist aber fehleranfällig und kostet jedes Mal unnötig Zeit. Mit GitHub Actions können Sie den gesamten Prozess automatisieren, vom Commit bis zum Store-Upload.

Aus eigener Erfahrung kann ich sagen: Die initiale Einrichtung braucht ein paar Stunden, aber danach spart man sich bei jedem Release eine Menge Stress.

Secrets konfigurieren

Sensible Daten gehören nie ins Repository. Nutzen Sie stattdessen GitHub Secrets:

ANDROID_KEYSTORE_BASE64: Ihr Keystore als Base64-String
ANDROID_KEYSTORE_PASSWORD: Keystore-Passwort
ANDROID_KEY_ALIAS: Key-Alias
ANDROID_KEY_PASSWORD: Key-Passwort
IOS_CERTIFICATE_BASE64: Apple Distribution-Zertifikat als Base64
IOS_CERTIFICATE_PASSWORD: Zertifikat-Passwort
IOS_PROVISIONING_PROFILE_BASE64: Provisioning Profile als Base64
APPSTORE_API_KEY: App Store Connect API-Schlüssel
APPSTORE_API_ISSUER: App Store Connect Issuer-ID

Android-Workflow

Der Android-Build läuft auf einem Ubuntu-Runner und erzeugt eine signierte AAB-Datei:

name: Android Release

on:
  push:
    tags:
      - 'v*'

jobs:
  build-android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: .NET Setup
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: MAUI Workload installieren
        run: dotnet workload install maui-android

      - name: Keystore dekodieren
        run: |
          echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | \
            base64 --decode > meineapp-release.keystore

      - name: Android Release Build
        run: |
          dotnet publish -f net10.0-android -c Release \
            -p:AndroidKeyStore=true \
            -p:AndroidSigningKeyStore=meineapp-release.keystore \
            -p:AndroidSigningKeyAlias=${{ secrets.ANDROID_KEY_ALIAS }} \
            -p:AndroidSigningKeyPass=${{ secrets.ANDROID_KEY_PASSWORD }} \
            -p:AndroidSigningStorePass=${{ secrets.ANDROID_KEYSTORE_PASSWORD }}

      - name: AAB-Artifact hochladen
        uses: actions/upload-artifact@v4
        with:
          name: android-aab
          path: ./**/publish/*.aab

iOS-Workflow

iOS-Builds brauchen zwingend einen macOS-Runner. Der folgende Workflow installiert Zertifikat und Provisioning Profile, baut die App und lädt sie via App Store Connect API hoch:

name: iOS Release

on:
  push:
    tags:
      - 'v*'

jobs:
  build-ios:
    runs-on: macos-15
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v4

      - name: Xcode einrichten
        uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: '16.3'

      - name: .NET Setup
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: MAUI Workload installieren
        run: dotnet workload install maui

      - name: Apple-Zertifikat installieren
        run: |
          CERT_PATH=$RUNNER_TEMP/certificate.p12
          KEYCHAIN_PATH=$RUNNER_TEMP/app-signing.keychain-db

          echo "${{ secrets.IOS_CERTIFICATE_BASE64 }}" | \
            base64 --decode > $CERT_PATH

          security create-keychain -p "" $KEYCHAIN_PATH
          security set-keychain-settings $KEYCHAIN_PATH
          security unlock-keychain -p "" $KEYCHAIN_PATH
          security import $CERT_PATH -k $KEYCHAIN_PATH \
            -P "${{ secrets.IOS_CERTIFICATE_PASSWORD }}" \
            -T /usr/bin/codesign
          security set-key-partition-list -S apple-tool:,apple: \
            -k "" $KEYCHAIN_PATH
          security list-keychains -d user -s $KEYCHAIN_PATH

      - name: Provisioning Profile installieren
        run: |
          PP_PATH=$RUNNER_TEMP/profile.mobileprovision
          echo "${{ secrets.IOS_PROVISIONING_PROFILE_BASE64 }}" | \
            base64 --decode > $PP_PATH
          mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
          cp $PP_PATH ~/Library/MobileDevice/Provisioning\ Profiles/

      - name: iOS Release Build
        run: |
          dotnet publish -f net10.0-ios -c Release \
            -p:ArchiveOnBuild=true \
            -p:CodesignKey="Apple Distribution" \
            -p:CodesignProvision="MeineApp AppStore Profile"

      - name: An App Store Connect hochladen
        run: |
          xcrun altool --upload-app \
            --type ios \
            --file bin/Release/net10.0-ios/publish/*.ipa \
            --apiKey ${{ secrets.APPSTORE_API_KEY }} \
            --apiIssuer ${{ secrets.APPSTORE_API_ISSUER }}

Sobald alles eingerichtet ist, wird bei jedem getaggten Commit automatisch ein Release-Build für beide Plattformen erstellt und hochgeladen. Das spart nicht nur Zeit — es eliminiert auch die typischen menschlichen Fehler beim Signierungsprozess.

Versionierung richtig umsetzen

Beide Stores haben strenge Regeln für die Versionierung. Apple verlangt, dass jede hochgeladene Build-Nummer höher ist als die vorherige. Bei Google muss der versionCode mit jedem Update steigen.

In .NET MAUI steuern Sie beides über die Projektdatei:

<PropertyGroup>
  <!-- Angezeigte Version im Store (Semantic Versioning) -->
  <ApplicationDisplayVersion>1.2.0</ApplicationDisplayVersion>

  <!-- Interne Build-Nummer (muss bei jedem Upload steigen) -->
  <ApplicationVersion>12</ApplicationVersion>
</PropertyGroup>

In einer CI/CD-Pipeline lässt sich die Build-Nummer elegant aus der GitHub-Run-Nummer generieren:

dotnet publish -f net10.0-android -c Release \
  -p:ApplicationVersion=${{ github.run_number }}

So steigt die Build-Nummer bei jedem Pipeline-Lauf automatisch — ganz ohne manuelle Pflege. Ein kleiner Trick, der einem viel Ärger erspart.

Häufige Fehler und wie Sie sie vermeiden

Nach unzähligen Store-Submissions haben sich bestimmte Fehler als besonders häufig (und besonders ärgerlich) herausgestellt. Hier die wichtigsten, damit Sie nicht in die gleichen Fallen tappen.

Android-spezifische Probleme

Keystore verloren: Ohne Backup des Keystores können Sie keine Updates veröffentlichen. Speichern Sie ihn an einem sicheren Ort außerhalb des Repositories — und am besten an zwei verschiedenen Stellen.
Target-SDK zu niedrig: Prüfen Sie vor jedem Release die aktuellen Anforderungen von Google. Ab August 2026 ist API Level 36 Pflicht.
Fehlende Datensicherheitserklärung: Google Play verlangt seit 2022 eine Datensicherheitserklärung. Ohne diese wird Ihr App-Eintrag als unvollständig markiert.
Falsches Paketformat: Stellen Sie sicher, dass Sie eine AAB und keine APK hochladen. APK-Dateien werden für neue Apps schlicht nicht mehr akzeptiert.

iOS-spezifische Probleme

Abgelaufenes Provisioning Profile: Profile sind nur ein Jahr gültig. Richten Sie sich eine Erinnerung ein und erneuern Sie rechtzeitig — am besten mindestens zwei Wochen vor Ablauf.
Fehlendes Privacy Manifest: Die mit Abstand häufigste Ablehnungsursache bei .NET MAUI-Apps. Vergessen Sie nicht, PrivacyInfo.xcprivacy einzubinden.
Fehlende Screenshots: Apple verlangt Screenshots für verschiedene Gerätegrößen (iPhone 6,7 Zoll, iPad 12,9 Zoll). Bereiten Sie die vor dem Upload vor.
Kein Testaccount für den Reviewer: Wenn Ihre App einen Login braucht, müssen Sie Demo-Zugangsdaten angeben. Sonst wird die App garantiert abgelehnt.

Plattformübergreifende Probleme

Versionsnummer nicht erhöht: Beide Stores lehnen Uploads mit gleicher oder niedrigerer Build-Nummer ab. Klingt offensichtlich, passiert aber überraschend oft.
Debug-Build statt Release: Ein klassischer Anfängerfehler. Prüfen Sie immer die Build-Konfiguration (-c Release).
Fehlende App-Icons: Beide Plattformen haben spezifische Anforderungen an Icon-Größen. Die gute Nachricht: In .NET MAUI können Sie ein einzelnes SVG-Icon verwenden, das automatisch in alle benötigten Größen konvertiert wird.

Checkliste vor dem Release

Nutzen Sie diese Checkliste als letzten Schritt vor jedem Store-Upload. Ich empfehle, sie tatsächlich Punkt für Punkt durchzugehen — gerade wenn man es eilig hat, übersieht man sonst schnell etwas:

Build-Konfiguration auf Release umgestellt
Versionsnummer und Build-Nummer erhöht
App-Icons für alle Plattformen vorhanden
Splash Screen konfiguriert
Privacy Manifest für iOS eingebunden und vollständig
Target-SDK für Android auf aktuellem Level (API 36)
Keystore bzw. Zertifikat und Provisioning Profile gültig
Store-Eintrag vollständig: Beschreibung, Screenshots, Datenschutz-URL
Datensicherheitsformular (Google) bzw. Datenschutzangaben (Apple) ausgefüllt
Testdurchlauf auf echten Geräten im Release-Modus abgeschlossen

FAQ — Häufig gestellte Fragen

Kann ich eine .NET MAUI-App ohne Mac für iOS veröffentlichen?

Kurz gesagt: Nein. Ein Mac ist für den iOS-Build zwingend erforderlich. Aber es muss kein physischer Mac auf Ihrem Schreibtisch sein. Visual Studio auf Windows kann sich per Pair to Mac mit einem Remote-Mac im Netzwerk verbinden. Alternativ funktionieren Cloud-basierte Mac-Dienste oder macOS-Runner in Ihrer CI/CD-Pipeline (wie runs-on: macos-15 bei GitHub Actions).

Was ist der Unterschied zwischen APK und AAB bei Android?

Eine APK (Android Package) ist eine monolithische Installationsdatei mit allen Ressourcen für alle Gerätekonfigurationen. Eine AAB (Android App Bundle) hingegen wird von Google Play genutzt, um daraus optimierte, gerätespezifische APKs zu generieren. Ergebnis: Kleinere Downloads für Ihre Nutzer. Seit 2021 akzeptiert Google Play für neue Apps ausschließlich AAB-Dateien.

Wie oft muss ich das Apple Provisioning Profile erneuern?

Distribution Provisioning Profiles sind ein Jahr lang gültig. Wenn das Profil abläuft, können Sie keine neuen Builds mehr signieren — bereits veröffentlichte Apps bleiben davon aber unberührt. Planen Sie die Erneuerung rechtzeitig ein, idealerweise mindestens zwei Wochen vor Ablauf.

Warum wird meine iOS-App abgelehnt trotz erfolgreichem Build?

Ein erfolgreicher Build heißt leider noch nicht, dass Apple die App auch durchwinkt. Die häufigsten Ablehnungsgründe: fehlendes oder unvollständiges Privacy Manifest, fehlende Datenschutzerklärung (Privacy Policy URL), keine Testdaten für den Reviewer bei Login-pflichtigen Apps, und App-Funktionen die nicht wie beschrieben funktionieren. Der Tipp: Lesen Sie die Ablehnung in App Store Connect genau durch — Apple gibt immer einen spezifischen Grund an.

Kann ich die CI/CD-Pipeline auch mit Azure DevOps statt GitHub Actions nutzen?

Ja, absolut. Die Konzepte sind identisch. Azure DevOps bietet ebenfalls macOS-Build-Agenten und unterstützt die gleichen Signierungsprozesse. Der Hauptunterschied liegt in der YAML-Syntax der Pipeline-Definition. Die .NET-Build-Befehle (dotnet publish) und Signierungsparameter bleiben komplett gleich.