Publishing to App Stores

Analogy categoryAnalogies

Getting a MAUI app onto a device via dotnet build is only step one; shipping it to real users means producing a signed, store-ready package (an .aab for Google Play, an .ipa for the App Store), enrolling in each platform's developer program, and passing each store's review process. The two pipelines diverge significantly — Android's is largely automatable from any machine, while iOS requires an active Apple Developer Program membership, code-signing certificates, and (for the final .ipa build) macOS-hosted tooling — but both start from the same shared MAUI project.

🏏

Cricket analogy: It's like the difference between qualifying for a domestic T20 league versus making a national squad — both start from the same underlying cricketing ability, but the second path (iOS) demands a lot more formal accreditation and gatekeeping before you're allowed to play.

Preparing for Android: Signing and the AAB

Google Play requires an Android App Bundle (.aab), not the .apk you sideload during development, built in Release configuration with dotnet publish -f net8.0-android -c Release. Every release build must be signed with a keystore — either one you generate yourself with keytool and store securely, or Play App Signing, where Google holds the final signing key and you upload with an upload key instead; losing your original signing key (if you're not using Play App Signing) means you can never publish an update to that same app listing again, since Android requires all updates to be signed with the same key.

🏏

Cricket analogy: It's like a franchise's team registration certificate — once a squad is officially registered under a certain identity, every future season's roster has to be filed under that same registration, or the league won't recognize it as the same team.

bash

# Publish a signed Android App Bundle for Google Play
dotnet publish -f net8.0-android -c Release \
  -p:AndroidSigningKeyStore=my-release.keystore \
  -p:AndroidSigningKeyAlias=my-key-alias \
  -p:AndroidSigningKeyPass=$KEY_PASS \
  -p:AndroidSigningStorePass=$STORE_PASS \
  -p:AndroidPackageFormat=aab

# Output: bin/Release/net8.0-android/publish/com.company.app-Signed.aab

Keep your Android keystore file and its passwords in a secure secrets vault, not in source control. If you use Play App Signing (the recommended default for new apps), Google manages the final release key for you and you only need to protect your upload key.

Preparing for iOS: Certificates and Provisioning

iOS distribution requires an active Apple Developer Program enrollment, a Distribution Certificate (proving your identity to Apple), and a Provisioning Profile that ties your app's bundle identifier, the certificate, and (for TestFlight/App Store builds) the App Store distribution method together; these are typically managed through Xcode's automatic signing or manually via the Apple Developer portal, and the final signed .ipa is produced with dotnet publish -f net8.0-ios -c Release run on a Mac (or a Mac build host paired to a Windows machine via Visual Studio's Pair to Mac feature).

🏏

Cricket analogy: It's like an overseas player needing both a national federation's official clearance and a specific tournament's accreditation badge before they're allowed onto the field — the certificate is the federation clearance, the provisioning profile is the tournament badge.

Visual Studio's 'Pair to Mac' lets you build, debug, and produce signed iOS builds from Windows by connecting to a networked Mac that runs the actual build and code-signing steps — you still need physical (or cloud-hosted) Mac hardware somewhere in the pipeline.

Versioning, Store Listings, and Review

Both stores key updates off two numbers set in the MAUI project — ApplicationDisplayVersion (the user-facing version like 1.2.0) and ApplicationVersion (an integer build number that must strictly increase with every submission, even for the same display version), configured in the .csproj or per-platform. Store review then checks the binary and its metadata against policy: Google Play's review is largely automated and fast (often hours), while Apple's App Review is manual, can take one to several days, and commonly rejects apps for incomplete metadata, crashes on first launch, or use of private APIs — so budgeting review time into a release schedule, not just build time, is essential.

🏏

Cricket analogy: It's like a team's squad number never being reused within a season even if two players share a jersey number across different tours — ApplicationVersion must strictly increase, just like an incrementing match-day squad list number.

Google Play requires a signed .aab; Apple requires a signed .ipa built with a valid Distribution Certificate and Provisioning Profile.
Android keystores must be protected long-term (or managed via Play App Signing) — losing your only signing key blocks future updates to that listing.
iOS builds require macOS tooling somewhere in the pipeline, whether native Mac hardware or Visual Studio's Pair to Mac feature.
ApplicationDisplayVersion is the user-facing version string; ApplicationVersion is an integer build number that must strictly increase every submission.
Google Play review is largely automated and fast; Apple App Review is manual and can take days, so it needs to be budgeted into release timelines.
Common App Store rejection reasons include incomplete metadata, first-launch crashes, and use of private/undocumented APIs.
Both stores require complete store listings (screenshots, privacy policy, app description) before a build can be submitted for review.

Practice what you learned

1. What package format does Google Play require for a production submission?

2. What is the consequence of losing your only Android signing keystore if you are not using Play App Signing?

3. What is required to produce a signed .ipa for App Store submission?

4. What must be true of ApplicationVersion between two consecutive App Store or Play Store submissions?

Was this page helpful?

Dependency Injection

MAUI Blazor Hybrid

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#Programming#NETMAUIStudyNotes#PublishingToAppStores#Publishing#App#Stores#Preparing#StudyNotes#SkillVeris#ExamPrep

Publishing to App Stores