Overview of the Submission Pipeline
Publishing an app to the Microsoft Store starts in Partner Center, Microsoft's web portal for managing app identities, pricing, and releases. A developer first reserves a unique app name, which generates a Store-specific package identity (a reserved Package/Identity/Name and Publisher pair) that must be embedded into the app's AppxManifest.xml before the package will be accepted. From there, the developer creates a submission: uploading one or more MSIX/MSIXUPLOAD packages, filling in Store listing details (description, screenshots, age ratings), setting pricing and market availability, and finally submitting for certification, after which Microsoft's automated and manual review pipeline takes over.
Cricket analogy: Reserving an app name in Partner Center is like a player registering their name with the ICC before an auction, without that registered identity they can't be listed for bidding in the IPL auction at all.
Preparing the Package for Submission
Before uploading, the app's AppxManifest.xml Identity element must contain the exact Package Name and Publisher values Partner Center assigned during name reservation, and the Version number must be higher than any previously published submission. Developers typically use Visual Studio's 'Create App Packages' wizard, which can produce architecture-specific packages (x86, x64, ARM64) bundled into a single .msixupload file, run the Windows App Certification Kit locally, and optionally enable automatic block map generation for differential updates. Getting the identity fields wrong is the most common reason a package is rejected before certification even begins.
Cricket analogy: The Version number needing to increase with each submission is like a player's Test cap number always going up, never reused, uniquely marking each new appearance.
# Run the Windows App Certification Kit locally before submitting
CertificationTools\appcert.exe test `
-apptype packagedwin32 `
-packagefullname "Contoso.NotesApp_3.2.0.0_x64__8wekyb3d8bbwe" `
-reportoutputpath "C:\Reports\wack_report.xml"
# Validate the report exit code before uploading to Partner Center
if ($LASTEXITCODE -ne 0) {
Write-Error "WACK validation failed - fix issues before submission"
}Certification Review and Publishing
After submission, packages go through Microsoft's certification pipeline, which combines automated security and policy scans (malware detection, API usage checks, manifest validation) with a manual functional test pass where a reviewer installs and exercises the app on real or virtualized hardware against the Microsoft Store Policies. Certification typically completes within a few hours to a couple of days depending on app complexity and current queue volume. If the app fails, Partner Center returns a detailed report citing the specific policy or technical failure; once it passes, the developer can choose immediate publish, a scheduled release date, or a staged rollout to a percentage of users before going to 100%.
Cricket analogy: The manual reviewer installing and exercising the app is like a pitch inspector physically walking and testing a wicket before a Test match is cleared to proceed, automated checks alone aren't enough.
Partner Center lets you configure 'gradual package rollout,' releasing an update to an initial small percentage of existing users (e.g. 10%) and monitoring crash/feedback telemetry before increasing to 50% and then 100% — this catches regressions before they hit your entire install base.
Store Listing and Policy Compliance
Beyond the binary itself, Partner Center requires a complete Store listing: localized descriptions, at least one screenshot per supported device family, an age rating obtained through the International Age Rating Coalition (IARC) questionnaire, and privacy policy URL if the app collects any user data. The Microsoft Store Policies (section 10 in particular) govern in-app purchases, ads, and content requirements, and violating them — such as using deceptive metadata, requesting excessive capabilities the app doesn't use, or failing to disclose data collection — is the leading cause of manual rejection even when the automated scan passes cleanly.
Cricket analogy: The IARC age rating questionnaire is like a board classifying a cricket broadcast's content for TV audiences, determining what warnings or restrictions apply before it airs.
Certification failures for 'insufficient description of data collection' or 'requesting capabilities not used in the app' are among the most common manual-review rejections — always audit the Capabilities section of AppxManifest.xml and remove anything the app doesn't actually exercise before submitting.
- App name reservation in Partner Center generates the Package Identity that must match AppxManifest.xml exactly.
- Package Version must increase with every new submission; Visual Studio's packaging wizard can produce multi-architecture .msixupload files.
- Certification combines automated security/policy scans with a manual functional review against Microsoft Store Policies.
- Gradual/staged rollout lets developers release updates to a percentage of users before going to 100%.
- A complete Store listing requires localized descriptions, screenshots per device family, and an IARC age rating.
- Unused requested capabilities and undisclosed data collection are leading causes of manual rejection.
- Running the Windows App Certification Kit locally before submitting catches many issues before official review.
Practice what you learned
1. What must be reserved in Partner Center before an app's identity can be embedded in AppxManifest.xml?
2. What is required for every new submission's Version number in AppxManifest.xml?
3. What does a 'gradual package rollout' in Partner Center accomplish?
4. Which of the following is a common cause of manual certification rejection even when automated scans pass?
Was this page helpful?
You May Also Like
MSIX Packaging
MSIX is Microsoft's modern Windows app packaging format that unifies MSI, APPX, ClickOnce, and App-V into a single container with clean install/uninstall and dependency management.
UWP App Certification
How the Windows App Certification Kit and Microsoft's Store review pipeline validate UWP/MSIX apps for security, performance, and policy compliance.
UWP App Updates
How UWP and MSIX apps receive updates through the Microsoft Store, differential block-map delivery, and enterprise deployment tools.
Sideloading UWP Apps
How to install UWP/MSIX apps outside the Microsoft Store for development, testing, and enterprise line-of-business distribution.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics