An open API service indexing awesome lists of open source software.

https://github.com/tsjdev-apps/github-actions-dotnet-maui

Repository containing GitHub Actions to build and sign .NET MAUI applications.
https://github.com/tsjdev-apps/github-actions-dotnet-maui

Last synced: 2 months ago
JSON representation

Repository containing GitHub Actions to build and sign .NET MAUI applications.

Awesome Lists containing this project

README

          

# GitHub Actions for .NET MAUI

This repository shows how to build a .NET MAUI application in GitHub Actions for multiple target platforms. It contains a sample app and production-oriented workflow examples for Android, iOS, and Windows.

The goal is not just to compile the app, but to demonstrate the parts that usually matter in CI/CD for MAUI projects:

- installing the .NET SDK from `global.json`
- installing the MAUI workload on the runner
- restoring NuGet packages
- signing platform-specific packages with secrets
- publishing deployable artifacts
- uploading final build outputs for download and testing

The sample app under `src/MyAwesomeMauiApp` targets .NET 10 and is used to validate the workflows end to end.

## Supported workflows

| Platform | Runner | Target framework | Output |
| --- | --- | --- | --- |
| Android | `windows-latest` | `net10.0-android` | `.aab`, `.apk` |
| iOS | `macos-26` | `net10.0-ios` | `.ipa` |
| Windows | `windows-latest` | `net10.0-windows10.0.19041.0` | `.msix` |

Current workflow files:

- `.github/workflows/android-build.yml`
- `.github/workflows/ios-build.yml`
- `.github/workflows/windows-build.yml`

## Repository layout

- `src/MyAwesomeMauiApp`: sample .NET MAUI application used by the workflows
- `.github/workflows`: GitHub Actions workflow definitions
- `global.json`: pins the .NET SDK used locally and in CI
- `NuGet.Config`: NuGet source configuration
- `MyAwesomeMauiApp.slnx`: solution entry point

## Project details

The sample app currently uses these MAUI target frameworks:

- `net10.0-android`
- `net10.0-ios`
- `net10.0-maccatalyst`
- `net10.0-windows10.0.19041.0` on Windows hosts

The SDK is pinned through `global.json` to `.NET SDK 10.0.200`, which keeps local and CI builds aligned.

## What the workflows demonstrate

### Android build

The Android workflow runs on `windows-latest` and publishes signed Android packages.

Main steps:

1. Check out the repository.
2. Install the SDK version from `global.json`.
3. Install the MAUI workload.
4. Decode the Android keystore from a GitHub secret.
5. Generate version metadata from the GitHub Actions run number.
6. Restore NuGet packages.
7. Publish the app for `net10.0-android` in `Release` mode.
8. Collect `.aab` and `.apk` files into a flat output folder.
9. Upload the final Android artifacts.

This workflow is useful as a baseline for signed Android CI builds where the final app packages should be ready for testing or store preparation.

### iOS build

The iOS workflow runs on `macos-26` and produces an `.ipa` package.

Main steps:

1. Check out the repository.
2. Install the SDK version from `global.json`.
3. Select Xcode `26.2` explicitly.
4. Install the MAUI workload.
5. Import the signing certificate from GitHub Secrets.
6. Download provisioning profiles from App Store Connect.
7. Generate version metadata from the GitHub Actions run number.
8. Restore NuGet packages.
9. Publish the app for `net10.0-ios` in `Release` mode.
10. Collect the generated `.ipa` file.
11. Upload the iOS artifact.

This workflow shows the essential moving parts for iOS signing in CI: certificate import, provisioning profile download, and publishing a distributable package.

### Windows build

The Windows workflow runs on `windows-latest` and produces a signed `.msix` package for testing and distribution.

Main steps:

1. Check out the repository.
2. Install the SDK version from `global.json`.
3. Install the MAUI workload.
4. Restore NuGet packages.
5. Decode a base64-encoded `.pfx` signing certificate from GitHub Secrets.
6. Import the certificate into the current user certificate store.
7. Validate that the certificate subject matches the publisher defined in `Platforms/Windows/Package.appxmanifest`.
8. Export a public `.cer` certificate for installation on test machines.
9. Publish the app for `net10.0-windows10.0.19041.0` as an MSIX package.
10. Collect the generated `.msix` and helper files into an artifact folder.
11. Upload the Windows build artifact.

The uploaded Windows artifact is designed for practical testing. It contains:

- the app package as `.msix`
- any required Windows App Runtime dependency package copied from the publish output
- a public test certificate (`.cer`)
- an `INSTALL.txt` file with installation notes

This makes the Windows workflow more useful than a simple compile-only job because a tester can install the package on another machine with minimal manual preparation.

## Required GitHub Secrets

The workflows rely on platform-specific secrets for signing and distribution.

### Android secrets

- `ANDROID_KEYSTORE`: base64-encoded keystore file
- `ANDROID_KEY_ALIAS`: alias inside the keystore
- `ANDROID_KEY_PASSWORD`: key password
- `ANDROID_KEYSTORE_PASSWORD`: keystore password

### iOS secrets

- `IOS_P12_BASE64`: base64-encoded `.p12` certificate
- `IOS_P12_PASSWORD`: password for the `.p12` certificate
- `IOS_BUNDLE_ID`: app bundle identifier
- `APP_STORE_CONNECT_ISSUER_ID`: App Store Connect issuer ID
- `APP_STORE_CONNECT_KEY_ID`: App Store Connect API key ID
- `APP_STORE_CONNECT_PRIVATE_KEY`: App Store Connect private key content

### Windows secrets

- `PFX_BASE64`: base64-encoded `.pfx` certificate
- `PFX_PASSWORD`: password for the `.pfx` certificate

For the Windows workflow, make sure the imported certificate subject matches the publisher configured in the app manifest. If those values differ, the workflow intentionally fails early.

## Running the workflows

All three workflows currently use `workflow_dispatch`, so they can be triggered manually from the GitHub Actions tab.

Typical execution flow:

1. Open the repository in GitHub.
2. Go to the Actions tab.
3. Select the workflow you want to run.
4. Start it with Run workflow.
5. Download the uploaded artifact after the run completes.

## Local build examples

The same project can also be built locally. Exact prerequisites depend on the target platform and host operating system.

Install workloads and restore packages:

```powershell
dotnet workload install maui
dotnet restore src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj
```

Build Android locally:

```powershell
dotnet publish src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj `
-f net10.0-android `
-c Release
```

Build iOS locally on macOS:

```bash
dotnet publish src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj \
-f net10.0-ios \
-c Release
```

Build Windows locally on Windows:

```powershell
dotnet publish src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj `
-f net10.0-windows10.0.19041.0 `
-c Release `
-p:RuntimeIdentifierOverride=win-x64 `
-p:WindowsPackageType=MSIX `
-p:AppxPackage=true
```

If you want a signed Windows package locally, you also need a valid certificate whose publisher matches the Windows app manifest.

## Why Windows needs special handling

Windows packaging for MAUI is different from a basic desktop build. A useful CI workflow normally has to address these details:

- package generation as MSIX instead of only compiling binaries
- code signing with a trusted certificate
- publisher validation between manifest and certificate
- distribution of the public certificate for test environments
- optional Windows App Runtime dependencies for machines that do not already have them

That is why the Windows workflow in this repository includes certificate import, publisher validation, MSIX packaging, and extra installation guidance in the artifact.

## Next steps for this repository

Possible future additions include:

- automatic triggers on push and pull request
- store submission or release workflows
- notarization and distribution enhancements for Apple platforms
- reusable workflows for MAUI repositories
- matrix-based variants for Debug and Release builds

## Summary

This repository now contains end-to-end GitHub Actions examples for the main .NET MAUI platform targets used in CI:

- Android with signed `.aab` and `.apk` output
- iOS with signed `.ipa` output
- Windows with signed `.msix` output and test-installation assets

The Windows build is fully part of the documented setup and no longer missing from the project overview.