CI/CD för .NET MAUI med GitHub Actions: iOS och Android 2026

Uppdaterad: 28 juli 2026

CI/CD för .NET MAUI med GitHub Actions innebär att du sätter upp automatiserade workflows som bygger, signerar och distribuerar iOS- och Android-appar från samma repository (med macOS-runners för Apple-plattformar och Ubuntu-runners för Android och gemensam kod). Efter att Visual Studio App Center pensionerades i mars 2025 har GitHub Actions blivit standardvalet för team som vill hålla pipelines nära koden. Så, den här guiden visar hur vi bygger en produktionsklar pipeline från grunden, hanterar signering säkert och skickar releaser till TestFlight och Google Play.

• App Center avvecklades officiellt 31 mars 2025, och GitHub Actions är idag det primära ersättningsvalet för de flesta MAUI-team.
• iOS-builds kräver en macos-14- eller macos-15-runner med Xcode 16+ och en installerad .NET MAUI-workload. Android går att bygga på ubuntu-24.04.
• Signeringsnycklar ska aldrig checkas in. Använd GitHub Encrypted Secrets tillsammans med Apple App Store Connect API-nycklar och Google service accounts.
• Fastlane match förenklar certifikathanteringen för iOS avsevärt, särskilt när flera utvecklare pushar releaser.
• En vältrimmad pipeline med caching bygger både Android och iOS på 12 till 18 minuter för en medelstor MAUI-app.

Varför GitHub Actions efter App Center?

När Microsoft stängde ner Visual Studio App Center den 31 mars 2025 tvingades tusentals MAUI- och Xamarin-team välja ny pipeline på kort tid. I mitt förra team migrerade vi tre appar från App Center under ett enda kvartal, och GitHub Actions blev valet av tre skäl: pipelines lever bredvid koden, macOS-runners är förhållandevis prisvärda, och marketplace har färdiga actions för både Apple- och Google-integration.

Konkurrenterna är fortfarande relevanta. Azure DevOps Pipelines passar företag med Microsoft-avtal och integrerad ärendehantering. Bitrise är byggd runt mobil-CI och har den mest polerade UI:n för certifikathantering. Men om koden redan bor på GitHub finns det få skäl att splittra flödet, och nya funktioner som återanvändbara workflows och OIDC-autentisering mot Azure gör GitHub Actions minst lika kraftfullt.

Ett viktigt varningens ord: bara det att flytta workflows garanterar inte kvalitet. Vi såg samma team återinföra manuella signeringssteg efter migrering "för att det gick fortare just då". Ta chansen att skriva ner alla steg, inklusive signering, i YAML från dag ett.

Vad behöver du innan du börjar?

Innan du skriver första raden YAML, samla följande. Vi lärde oss den hårda vägen att en halvfärdig checklista leder till en pipeline som fungerar en fredag och kraschar på måndagen.

1. Apple Developer-konto med App Manager-behörighet och en giltig Distribution Certificate plus Provisioning Profile.
2. App Store Connect API-nyckel (en .p8-fil, Key ID och Issuer ID) för att kunna ladda upp till TestFlight utan Apple ID-lösenord.
3. Google Play-konsol med ett service account som har Release manager-behörighet, samt dess JSON-nyckel.
4. Android upload keystore (.keystore-fil) och tillhörande lösenord. Google Play App Signing hanterar sedan den slutliga signeringen.
5. .NET 9 SDK (eller senare) installerat lokalt så du kan verifiera att dotnet publish fungerar utanför pipelinen först.

När du har allt detta redo, konvertera de binära filerna (.p8, .p12, .keystore) till base64 med base64 -i file -o file.b64 och lagra dem som GitHub Encrypted Secrets. Aldrig i klartext, aldrig i repot.

Bygg .NET MAUI Android-appen i GitHub Actions

Android-delen är enklast eftersom Ubuntu-runners är billiga och Android SDK redan förinstallerat på GitHub-imagesarna. Här är en minimal men produktionsklar workflow-fil. Lägg den i .github/workflows/android-release.yml.

name: Android Release

on:
  push:
    tags: ['v*']
  workflow_dispatch:

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

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

      - name: Install MAUI workload
        run: dotnet workload install maui-android

      - name: Restore NuGet packages
        run: dotnet restore src/MyApp/MyApp.csproj

      - name: Decode upload keystore
        env:
          KEYSTORE_B64: ${{ secrets.ANDROID_KEYSTORE_B64 }}
        run: echo "$KEYSTORE_B64" | base64 --decode > $RUNNER_TEMP/upload.keystore

      - name: Publish signed AAB
        env:
          KS_PASS: ${{ secrets.ANDROID_KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.ANDROID_KEY_ALIAS }}
          KEY_PASS: ${{ secrets.ANDROID_KEY_PASSWORD }}
        run: |
          dotnet publish src/MyApp/MyApp.csproj \
            -f net9.0-android \
            -c Release \
            -p:AndroidPackageFormat=aab \
            -p:AndroidKeyStore=true \
            -p:AndroidSigningKeyStore=$RUNNER_TEMP/upload.keystore \
            -p:AndroidSigningKeyAlias=$KEY_ALIAS \
            -p:AndroidSigningKeyPass=$KEY_PASS \
            -p:AndroidSigningStorePass=$KS_PASS

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: android-release-aab
          path: '**/*-Signed.aab'

Två saker som ofta trippar upp nya team här. Först: -f net9.0-android måste matcha din TargetFrameworks i csproj-filen exakt. Sedan: AndroidPackageFormat=aab är obligatoriskt eftersom Google Play sedan augusti 2021 bara accepterar Android App Bundles för nya appar. En APK-fil kommer att avvisas i Play Console.

Om ni redan har en välfungerande pipeline för Native AOT och prestandaoptimering i .NET MAUI 10, kan ni återanvända samma workload-installation här, vilket gör att builds går snabbare eftersom cachen delas.

Så bygger du iOS-appen på macOS-runners

iOS-builds kräver en macOS-runner. Rekommendationen 2026 är macos-15 med Xcode 16.3 eller senare, men macos-14 fungerar också om du behöver hålla dig till en äldre Xcode-version. Här är en workflow som bygger en signerad IPA-fil.

name: iOS Release

on:
  push:
    tags: ['v*']
  workflow_dispatch:

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

      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_16.3.app

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

      - name: Install MAUI workload
        run: dotnet workload install maui-ios

      - name: Import signing certificate
        env:
          CERT_B64: ${{ secrets.IOS_DIST_CERT_B64 }}
          CERT_PASS: ${{ secrets.IOS_DIST_CERT_PASSWORD }}
          KEYCHAIN_PASS: ${{ secrets.KEYCHAIN_PASSWORD }}
        run: |
          echo "$CERT_B64" | base64 --decode > $RUNNER_TEMP/dist.p12
          security create-keychain -p "$KEYCHAIN_PASS" build.keychain
          security default-keychain -s build.keychain
          security unlock-keychain -p "$KEYCHAIN_PASS" build.keychain
          security import $RUNNER_TEMP/dist.p12 -k build.keychain \
            -P "$CERT_PASS" -T /usr/bin/codesign
          security set-key-partition-list -S apple-tool:,apple: \
            -s -k "$KEYCHAIN_PASS" build.keychain

      - name: Install provisioning profile
        env:
          PROFILE_B64: ${{ secrets.IOS_PROVISIONING_PROFILE_B64 }}
        run: |
          mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
          echo "$PROFILE_B64" | base64 --decode > \
            ~/Library/MobileDevice/Provisioning\ Profiles/dist.mobileprovision

      - name: Publish signed IPA
        run: |
          dotnet publish src/MyApp/MyApp.csproj \
            -f net9.0-ios \
            -c Release \
            -p:ArchiveOnBuild=true \
            -p:RuntimeIdentifier=ios-arm64 \
            -p:CodesignKey="Apple Distribution: My Company AB (TEAMID)" \
            -p:CodesignProvision="My App Distribution"

      - uses: actions/upload-artifact@v4
        with:
          name: ios-release-ipa
          path: '**/*.ipa'

CodesignKey-strängen måste matcha certifikatets Common Name exakt inklusive team-ID i parentes. Om du får ett "No matching signing identity"-fel, dubbelkolla först stavningen. Det är nästan alltid ett tomt mellanslag eller fel team-ID. Ärligt talat, jag har fastnat i den där fällan mer än en gång själv.

Hur signerar man MAUI-appar säkert?

Certifikathanteringen är den del där de flesta team fastnar. Vi rekommenderar en av två strategier beroende på teamets storlek.

Alternativ 1: GitHub Secrets direkt (små team)

För team med en eller två utvecklare räcker det att lägga certifikat och profil som base64-kodade secrets, exakt som exemplen ovan. Det tar tio minuter att sätta upp och du behöver ingen extern tjänst. Nackdelen är att när certifikatet går ut om ett år måste någon manuellt förnya och kopiera in det nya i GitHub.

Alternativ 2: Fastlane match (större team)

När fler än tre utvecklare pushar releaser blir manuell rotation snabbt en flaskhals. Fastlane match lagrar signaturmaterialet i ett separat privat git-repo krypterat med en gemensam passphrase. Alla utvecklare kör fastlane match appstore och får rätt certifikat installerat lokalt, och pipeline gör samma sak. Vi gick över till match när teamet växte till sex personer, och slutade jaga signeringsfel dagen efter.

Jämförelse: signeringsstrategier

Egenskap	GitHub Secrets	Fastlane match	App Store Connect API
Setup-tid	10 min	1 till 2 timmar	30 min
Delning i team	Manuell	Automatisk via git	Automatisk
Certifikatrotation	Manuell	Halvautomatisk	Automatisk (cloud signing)
Extra infrastruktur	Ingen	Privat git-repo	Ingen
Passar bäst för	1 till 2 utvecklare	3 till 10 utvecklare	Nya projekt 2026+

Ett tredje alternativ som blivit stabilt under 2026 är Apples Cloud Managed Signing via App Store Connect API. Där behöver du inte hantera certifikat eller profiler alls, eftersom Apple gör det åt dig. För nya projekt är det värt att titta på. För befintliga med etablerad match-workflow är migreringen sällan värd tiden.

Distribuera till TestFlight och Google Play

Att bygga en signerad artefakt är halva jobbet. Nästa steg är att skicka den vidare till respektive testkanal utan manuell inblandning.

Skicka till TestFlight

Använd xcrun altool eller det modernare xcrun notarytool tillsammans med en App Store Connect API-nyckel. Det här steget läggs till efter Publish signed IPA i iOS-workflowen.

- name: Upload to TestFlight
  env:
    ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
    ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
    ASC_KEY_B64: ${{ secrets.ASC_KEY_B64 }}
  run: |
    mkdir -p ~/.appstoreconnect/private_keys
    echo "$ASC_KEY_B64" | base64 --decode > \
      ~/.appstoreconnect/private_keys/AuthKey_$ASC_KEY_ID.p8
    IPA_PATH=$(find . -name "*.ipa" | head -n 1)
    xcrun altool --upload-app -f "$IPA_PATH" \
      --type ios \
      --apiKey "$ASC_KEY_ID" \
      --apiIssuer "$ASC_ISSUER_ID"

Efter uppladdning kör Apple sin processing (5 till 30 minuter) innan buildet dyker upp i TestFlight. Låt inte pipelinen vänta på det. Publicera direkt till en intern testgrupp så får testare pushnotis så snart processingen är klar.

Skicka till Google Play

För Android använder vi den öppna r0adkll/upload-google-play-actionen med service account-nyckeln.

- name: Upload to Google Play
  uses: r0adkll/upload-google-play@v1
  with:
    serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_JSON }}
    packageName: com.mycompany.myapp
    releaseFiles: '**/*-Signed.aab'
    track: internal
    status: completed

track: internal lägger buildet i den snabbaste testkanalen. Inga review-krav, och den blir tillgänglig för listade testare inom minuter. Från internal kan ni sedan promota vidare till closed, open och slutligen production med enkla knapptryck i konsolen, eller genom att köra actionen igen med annan track.

Om ni redan har läst vår genomgång av migrering från Xamarin till .NET MAUI kan ni återanvända era befintliga bundle-ID:n och Play Console-listings. De följer med automatiskt.

Caching och pipeline-optimering

En första fungerande pipeline tar ofta 25 till 30 minuter per plattform. Med två enkla optimeringar sänker vi det till 12 till 18 minuter.

NuGet-caching är det som ger mest per minut jobb. GitHub Actions har inbyggt stöd för det:

- uses: actions/setup-dotnet@v4
  with:
    dotnet-version: '9.0.x'
    cache: true
    cache-dependency-path: '**/packages.lock.json'

Kravet är att du kör dotnet restore --use-lock-file minst en gång lokalt så att packages.lock.json finns i repot. Utan låsfilen kan cache inte återanvändas mellan körningar.

MAUI workload-caching kräver lite mer jobb men sparar 3 till 5 minuter per körning:

- name: Cache MAUI workloads
  uses: actions/cache@v4
  with:
    path: |
      ~/.dotnet/sdk-manifests
      ~/.dotnet/metadata/workloads
    key: maui-${{ runner.os }}-net9-v2

Tredje optimering: parallellisera Android och iOS som två separata jobs istället för sekventiella steg. Så länge de inte delar artefakter kan de köras samtidigt, och totaltiden blir max(Android, iOS) istället för summan.

Vanliga fel och hur du felsöker dem

Efter att ha felsökt hundratals pipelines för olika team är det här listan över fel jag ser oftast, och den snabbaste vägen till en lösning.

"No installed provisioning profiles match" på iOS

Nästan alltid orsakat av att CodesignProvision är hårdkodat men provisioning profile-namnet inte matchar. Kör security cms -D -i profile.mobileprovision lokalt för att verifiera Name-fältet, eller använd wildcarden iOS Team Provisioning Profile: * för utvecklingsbuilds.

"Package name mismatch" mot Google Play

ApplicationId i din csproj (eller <ApplicationId> i Platforms/Android/AndroidManifest.xml) måste matcha exakt vad som är registrerat i Play Console. En bokstavs skillnad ger en tydlig error, men första gången är felmeddelandet lätt att missa.

Långa iOS-builds på macos-runners

Om buildet tar mer än 25 minuter, kontrollera om ni bygger både x86_64 och arm64. För distribution behövs bara ios-arm64. Sätt -p:RuntimeIdentifier=ios-arm64 och slipp den överflödiga arkitekturen.

TestFlight avvisar buildet efter uppladdning

Nästan alltid en av två saker: saknad NSCameraUsageDescription (eller motsvarande) i Info.plist, eller version-string som inte är strikt högre än föregående build. Höj <ApplicationVersion> i csproj med 1 och pusha en ny tag.

Vanliga frågor

Vad är det bästa alternativet till App Center för .NET MAUI 2026?

Det korta svaret är GitHub Actions för team som redan använder GitHub, Azure DevOps Pipelines för organisationer med Microsoft-avtal, och Bitrise för team som prioriterar en polerad UI för certifikathantering. GitHub Actions dominerar i den senaste .NET MAUI-communityn tack vare marketplace och OIDC-stöd.

Kan man bygga iOS-appar utan en Mac?

Inte lokalt, men i CI kan du använda GitHub Actions macOS-runners eller molntjänster som MacinCloud och AWS EC2 Mac. Själva den slutliga codesign-processen kräver alltid en Apple-signerad toolchain, vilket bara finns på macOS.

Hur mycket kostar CI/CD för en typisk MAUI-app?

På GitHub Team-planen (4 USD/användare/månad) ingår 3 000 Linux-minuter men bara 300 macOS-minuter i priset, och utöver det kostar en macOS-minut cirka 0,08 USD. En medelstor MAUI-app med tio releaser per månad landar oftast på 30 till 80 USD för iOS-buildarna, plus Ubuntu som ofta ryms i den gratis kvoten.

Behöver man Fastlane för att distribuera MAUI-appar?

Nej, det är helt valfritt. xcrun altool och Play Consoles service account räcker för de flesta team. Fastlane blir värdefullt när ni har mer än tre utvecklare, kör screenshots automatiserat eller distribuerar till flera regioner samtidigt.

Hur ofta ska man rotera signeringscertifikat?

Apples Distribution-certifikat är giltiga i ett år och bör förnyas 30 dagar innan de går ut. Android upload keystore ska inte roteras alls, eftersom förloras den kan Google Play App Signing bara återställas via en formell key-upgrade-process som tar 1 till 2 veckor.