GitHub Actions automates repeatable build and deployment work from a repository. A workflow is a YAML file that GitHub executes when a configured trigger occurs, such as a push to the main branch or a manual run. For production .NET MAUI apps, it can turn a source change into signed Android and iOS builds ready for store delivery. section 12.0 section 12.2.1
Create workflows under .github/workflows in the repository root. A workflow has a name, triggers, and jobs; each job contains ordered steps. Steps can run shell commands or invoke reusable actions identified by their owner, repository, and version. YAML indentation expresses the structure, so editing the file in a text editor such as Visual Studio Code keeps the configuration visible and maintainable. section 12.2.1 section 12.2.2 section 12.4
A build-and-deploy workflow can separate responsibilities into jobs:
- Build Android on a Windows runner: check out code, recover the signing keystore from a secret, install .NET and the MAUI workload, publish a signed release, and upload the signed AAB as an artifact. section 12.2.2
- Build iOS separately, then make deployment depend on successful Android and iOS build jobs. section 12.2.1 section 12.2.4
- Download the artifacts in the deploy job and upload them to Google Play and App Store Connect or TestFlight. section 12.2.4
Keep signing material and store-upload credentials out of the repository. GitHub Actions secrets hold string values such as passwords, aliases, API keys, and service-account JSON. A binary Android keystore must first be base64-encoded for storage as a string, then decoded by the workflow. Treat these values as confidential: losing an Android keystore or its password prevents uploading future versions signed with that key. section 12.2.2 section 12.2.4
Build and deploy on a push
A workflow named Build and Deploy MauiStockTake can run when code is pushed to main, while workflow_dispatch permits a manual run. Its Android job publishes the project for net7.0-android in Release configuration with signing properties supplied from secrets. After build jobs upload their artifacts, a dependent deploy job downloads the Android AAB and iOS IPA, uploads the AAB to the internal Google Play track, and sends the IPA to TestFlight. section 12.2.1 section 12.2.2 section 12.2.4
Figure 12.7 The GitHub Actions workflow is made up of three jobs. One builds and signs the Android app, another builds and signs the iOS app, and a third one deploys the two signed builds to their respective stores. The deploy job is dependent on the two build jobs, so they must complete successfully for it to run. All jobs depend on GitHub Actions secrets for signing keys, passwords, and other sensitive data.
View the job layout: Android and iOS builds run before deployment, while all jobs rely on secrets for signing and upload credentials. section 12.2.1
Choose runners for the work required. GitHub-hosted runners can execute jobs, while self-hosted runners are presented as a better option for macOS work because hosted macOS use incurs a 10× penalty. Before automating store delivery, complete the manual publishing path: at least one build must be uploaded manually, and Windows publishing must be released publicly before automation can deploy it. section 12.2 section 12.4
