.NET MAUI
Topics in this category
Advanced & Enterprise Advanced Data Binding & Collections App Lifecycle & Windows Best Practices & Architecture Concurrency & Threading Controls & Views Data Binding & MVVM Dependency Injection & Services Desktop - WinUI & Mac Catalyst Device Features & Essentials Fonts, Icons & Media Forms, Input & Validation Fundamentals & Architecture Gestures & Animations Graphics & Drawing Local Storage & Data Maps & Location Migration from Xamarin.Forms Native Interop & Libraries Networking & APIs
.NET MAUI

Publishing & Deployment

7 question(s)

How do you create a release build of a MAUI app?

Beginner
Build with the Release configuration for the target framework, which enables optimizations, trimming, and (on iOS) AOT. Use dotnet publish -f <tfm> -c Release to produce the platform artifact (APK/AAB, IPA, MSIX, or app bundle). Configure signing before publishing.
dotnet publish -f net8.0-android -c Release
dotnet publish -f net8.0-ios -c Release -p:RuntimeIdentifier=ios-arm64
Real-world example A CI job produces signed Release artifacts for each store by running dotnet publish per target framework.

Common follow-ups: What does Release enable? | What artifact does Android produce?

Deployment AOT Publishing & Deployment

What is the difference between an APK and an AAB for Android?

Beginner
An APK is a directly installable package. An Android App Bundle (AAB) is a publishing format uploaded to Google Play, which generates optimized per-device APKs (split by density, ABI, language), reducing download size. Google Play requires AAB for new apps; use APK for sideloading or internal testing.
dotnet publish -f net8.0-android -c Release \
    -p:AndroidPackageFormat=aab
Real-world example A team ships an AAB to Play for smaller user downloads but keeps an APK for QA sideloading.

Common follow-ups: Why does Play prefer AAB? | When do you still use an APK?

Android Deployment Publishing & Deployment

How do you sign a MAUI Android app for release?

Intermediate
Create a keystore, then reference it via MSBuild properties (AndroidKeyStore, AndroidSigningKeyStore, alias, and passwords) or use Play App Signing. Keep the keystore and passwords secret (CI secret store). The signature identifies the app; losing the key can prevent future updates unless Play App Signing manages it.
dotnet publish -f net8.0-android -c Release \
  -p:AndroidKeyStore=true \
  -p:AndroidSigningKeyStore=my.keystore \
  -p:AndroidSigningKeyAlias=mykey \
  -p:AndroidSigningStorePass=env:STORE_PASS
Real-world example Release builds are signed in CI using a keystore pulled from a secret manager, never committed to source control.

Common follow-ups: What is Play App Signing? | Why protect the keystore?

Android Security Deployment

What is required to publish a MAUI app to the Apple App Store?

Intermediate
You need an Apple Developer account, a distribution certificate, an App ID, and a provisioning profile. Build an IPA with the distribution signing identity, then upload via Transporter or Xcode/altool to App Store Connect for TestFlight and review. Builds must be AOT-compiled and meet Apple's guidelines.
dotnet publish -f net8.0-ios -c Release \
  -p:ArchiveOnBuild=true \
  -p:CodesignKey="Apple Distribution: My Co" \
  -p:CodesignProvision="My App Store Profile"
Real-world example A release pipeline archives, signs, and uploads the IPA to TestFlight, then promotes it to the store after review.

Common follow-ups: What is a provisioning profile? | How do you distribute a beta?

iOS Deployment Publishing & Deployment

How do you manage app versioning across platforms?

Intermediate
Set ApplicationDisplayVersion (the user-facing version like 1.2.0) and ApplicationVersion (the build/number that must increment each store upload) in the csproj. Automate the build number from CI (e.g., pipeline run id) so each submission is unique across Android versionCode and iOS build number.
<PropertyGroup>
    <ApplicationDisplayVersion>1.2.0</ApplicationDisplayVersion>
    <ApplicationVersion>$(BUILD_NUMBER)</ApplicationVersion>
</PropertyGroup>
Real-world example CI stamps each build with an incrementing number so store uploads never collide, while the display version follows semantic releases.

Common follow-ups: Which value must increment per upload? | How do you automate it?

Deployment CI/CD Publishing & Deployment

How do you set up CI/CD for a MAUI app?

Advanced
Use a pipeline (GitHub Actions, Azure DevOps) with the .NET MAUI workload installed; build/test on each PR; and on release, publish signed artifacts per platform (iOS on a macOS agent) and deploy to TestFlight/Play internal tracks. Store signing secrets securely and cache the workload/NuGet to speed builds.
- run: dotnet workload install maui
- run: dotnet build -c Release
- run: dotnet test
- run: dotnet publish -f net8.0-android -c Release
Real-world example Every merge to main produces store-ready builds automatically, with iOS built on a hosted Mac and Android on Linux.

Common follow-ups: Why does iOS need a Mac agent? | How do you handle signing secrets in CI?

CI/CD Deployment Security

How do you implement over-the-air updates or feature flags in MAUI?

Advanced
Native app code can't be hot-swapped through stores, but you can update content/config remotely: fetch feature flags from a service (or use a flag SDK), gate features at runtime, and use remote config for values. For UI, Blazor Hybrid content or server-driven UI can change without a store release; native binary changes still require resubmission.
if (await _flags.IsEnabledAsync("new_checkout"))
    await Shell.Current.GoToAsync("checkout-v2");
Real-world example A team dark-launches a new checkout flow behind a remote flag, ramping it to users without shipping a new build.

Common follow-ups: What can't OTA change? | How do flags reduce release risk?

Feature Flags Deployment Advanced & Enterprise