Microsoft Store Submission Process

Publishing a Windows application to the Microsoft Store is a structured process that requires developers to work through several interconnected stages: creating and verifying a Publisher account in Partner Center, packaging the application using the MSIX format, assembling the required store listing assets and metadata, and finally passing Microsoft's certification review. Each stage has specific requirements that must be satisfied before an app can appear publicly in the Store. Understanding the full pipeline in detail — from first account registration through to a live listing — helps developers avoid common pitfalls, reduces certification failures, and leads to a polished, discoverable store presence.

Microsoft Partner Center Account Setup

The Microsoft Partner Center (partner.microsoft.com) is the unified portal through which developers register as publishers, submit app packages, monitor sales and install analytics, and configure payout information. Before any application can be submitted to the Microsoft Store, a Publisher account must be created and approved in Partner Center. There are two account types available, and the choice between them affects both cost and the verification steps required.

An Individual developer account is intended for solo developers or hobbyists who are not representing a legal business entity. Registration requires a one-time fee of $19 USD. After payment, Microsoft verifies the identity of the individual through the payment method and associated Microsoft account, and the account is typically activated quickly. Individual accounts display the developer's chosen display name on Store listings rather than a company brand.

A Company account carries a one-time fee of $99 USD and is designed for organisations, studios, and businesses that want to publish apps under a company identity. Because the account will represent a legal entity, Microsoft requires business identity verification. This verification is performed by a third-party verification provider (historically Dun & Bradstreet) and involves confirming that the company name, address, and contact details match official business records. The process can take several business days, and Microsoft may request supporting documentation. Once approved, the company's legal or trading name appears as the publisher identity on all Store listings.

A Microsoft account (an @outlook.com, @hotmail.com, or any email linked to the Microsoft identity system) is mandatory to begin registration. This account becomes the primary owner of the Partner Center publisher profile. Additional users — such as teammates or finance staff — can later be invited to the account with role-based permissions ranging from full manager access to read-only analytics or payout-only roles.

Once the account is active, the Partner Center dashboard becomes the central hub for all publishing operations. From the dashboard a developer can:

• Create new app submissions and reserve an app name in the Store (name reservation is free and holds the name even before a package is ready).
• Upload MSIX packages and manage release branches or flight rings for phased rollouts.
• Author or update store listings in multiple languages.
• View acquisition, usage, and health analytics broken down by region, OS version, and device type.
• Configure pricing, markets, and availability schedules.
• Set up bank accounts and tax profiles to receive revenue from paid apps or in-app purchases.

It is good practice to reserve an app name in Partner Center as early as possible during development. The reserved name must match the Name declared in the MSIX package manifest, so reserving it early lets you embed the correct identity in the package without changes later.

Windows App Packaging with MSIX

MSIX is the modern Windows application packaging format and is the required format for all submissions to the Microsoft Store. It supersedes older formats such as AppX (which it extends), MSI, and ClickOnce for Store distribution. MSIX packages are digitally signed container files (with the .msix or .msixbundle extension) that encapsulate an application's binaries, assets, and a declarative XML manifest. Because MSIX uses containerised installation, applications are installed cleanly without registry sprawl, uninstall completely without leaving residue, and support features such as automatic updates and differential package downloads.

Building MSIX packages in Visual Studio is the most common path for developers writing new applications targeting Windows. Visual Studio 2019 and later include a dedicated Windows Application Packaging Project template. Adding this project type to a solution and setting it as the startup project causes Visual Studio to produce a signed MSIX package when building in Release configuration. The packaging project references the main application project, and its Package.appxmanifest file is edited through a visual designer inside the IDE. When submitting to the Store, developers typically select Create App Packages from the project context menu, which invokes a wizard that guides through architecture selection (x86, x64, arm64), version numbering, and whether to produce a bundle. A bundle (.msixbundle) contains packages for multiple architectures in a single file, and the Store delivers only the architecture-appropriate slice to each user's device.

For software that already exists as a traditional Win32 installer (MSI, EXE setup, etc.), Microsoft provides the MSIX Packaging Tool, available free from the Microsoft Store itself. The tool works by monitoring an installation on a clean reference machine — either a physical machine or a Hyper-V virtual machine — and captures all file system and registry changes made by the installer. It then packages those artefacts into an MSIX structure. This conversion pathway lets legacy applications gain the benefits of MSIX deployment (clean uninstall, Store distribution, automatic updates) without requiring a rewrite. After conversion, developers typically review and trim the captured content to remove unnecessary registry keys or files before submission.

At the heart of every MSIX package is the manifest file, AppxManifest.xml. This XML document is the authoritative declaration of the application's identity and behaviour on the Windows platform. Key sections include:

• Identity element: Specifies the Name (which must match the name reserved in Partner Center), Publisher (the publisher distinguished name from your Store certificate), Version (a four-part version number such as 1.0.0.0), and ProcessorArchitecture.
• Properties: Contains the human-readable DisplayName, PublisherDisplayName, and the path to the app's logo image used on the Start menu tile.
• Capabilities: Declares the system resources and sensitive APIs the application needs access to, such as internetClient, microphone, webcam, or location. Windows enforces these declarations — an app that attempts to use a capability not listed in the manifest will be denied access at runtime. Reviewers during certification also verify that declared capabilities match the app's actual behaviour.
• Applications element: Defines the entry points of the package — the executable(s) that appear on the Start menu, their display names, descriptions, and visual assets. A single MSIX package can contain multiple application entry points.
• Extensions: Optional declarations for OS integration features such as file type associations, URI scheme handlers, background tasks, share targets, and toast notification activation.

A minimal manifest snippet for a WinUI 3 application looks like the following:

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10">
  <Identity
    Name="ContosoWeather"
    Publisher="CN=Contoso, O=Contoso Ltd, C=US"
    Version="2.1.0.0"
    ProcessorArchitecture="x64" />
  <Properties>
    <DisplayName>Contoso Weather</DisplayName>
    <PublisherDisplayName>Contoso Ltd</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
  </Properties>
  <Capabilities>
    <Capability Name="internetClient" />
    <uap:Capability Name="location" />
  </Capabilities>
  <Applications>
    <Application Id="App" Executable="ContosoWeather.exe"
                 EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements DisplayName="Contoso Weather"
        Description="Live weather forecasts."
        Square150x150Logo="Assets\Square150x150Logo.png"
        Square44x44Logo="Assets\Square44x44Logo.png"
        BackgroundColor="transparent" />
    </Application>
  </Applications>
</Package>

Before uploading to Partner Center, the package must be digitally signed. During development and sideload testing, developers sign with a self-signed certificate. For Store submissions, however, the package is typically uploaded unsigned — or signed with a developer certificate — because Microsoft re-signs the package with their own certificate infrastructure during the ingestion process, which is what users ultimately receive. Partner Center validates that the package identity metadata matches the reserved app name and publisher identity associated with the account.

Store Listing and Asset Requirements for Microsoft Store

A store listing is everything a potential user sees on the app's Store page: visuals, descriptions, ratings, and metadata. Crafting a complete and accurate listing is not only a certification requirement but also a significant factor in discoverability and conversion — how many people who view the page actually click Install. Partner Center allows listings to be localised into dozens of languages, each with its own set of assets and copy.

The visual asset requirements for a desktop app listing are precise. The store logo must be provided at a minimum size of 300×300 pixels. This image appears in search results, the app's Store page header, and various editorial placements across the Store. It should be a clean, high-contrast image that is legible at small sizes. PNG format with a transparent background is recommended so the Store can render it correctly on both light and dark UI themes.

Screenshots must be at least 1366×768 pixels for desktop app listings. Screenshots are among the highest-impact elements of a store listing; users scan them to quickly judge what the app looks like and does. Best practice is to provide at least three to four screenshots showing the app's primary features. Partner Center accepts up to ten screenshots per listing language. Captions can be added beneath each screenshot to call out specific functionality. While the minimum dimension is 1366×768, providing screenshots at higher resolutions (such as 1920×1080 or even 2560×1440) produces crisper visuals on high-DPI displays.

Every listing requires two written descriptions:

• A short description (up to 270 characters) that appears in search result cards and in some Store surface areas where space is limited. It should summarise the app's core value proposition succinctly.
• A full description (up to 10,000 characters) that appears on the app's dedicated Store page. This is the place to explain features in depth, list supported hardware or OS requirements, describe subscription tiers, and include keywords that improve organic search ranking within the Store. Plain text with line breaks is supported; basic formatting conventions like capitalisation and short bullet-style paragraphs improve readability.

Additional optional but recommended listing fields include a What's new in this version section (up to 1,500 characters), which is shown to existing users considering an update; search terms (up to seven terms, each up to 30 characters) that supplement the organic indexing of the description; and a support URL and privacy policy URL.

Age ratings are not assigned manually by the developer. Instead, Partner Center presents a questionnaire covering the nature of content in the app — including questions about violence, sexual content, drug references, user-generated content, social interaction features, and gambling mechanics. Based on the answers, Partner Center calculates ratings from recognised classification bodies such as ESRB, PEGI, USK, and others simultaneously. The developer is responsible for answering accurately; misrepresenting content in the questionnaire is a policy violation. Apps whose content changes significantly in an update (for example, adding in-app chat) must re-evaluate their rating questionnaire responses.

The table below summarises the key asset and metadata requirements for a typical desktop app listing:

Microsoft Store Certification and Policies

Before a submitted app becomes publicly visible in the Store, it must pass Microsoft's certification process. Certification enforces the Microsoft Store Policies — a publicly available document (part of the App Developer Agreement) that defines what apps are permitted to do, how they must behave, and what content they may contain. The policies span several major areas including content standards (no illegal content, no content that exploits minors, restricted adult content only in appropriate age-gated markets), privacy and data handling requirements, security requirements (no malware or deceptive behaviour), functionality standards (the app must work as described), and monetisation rules (in-app purchases of digital goods must use the Store's commerce system or a permitted alternative).

The certification pipeline has two complementary components that run in parallel or in sequence:

• Automated testing: The Windows App Certification Kit (WACK) and additional automated tools analyse the package for common technical violations — things like missing manifest declarations, use of deprecated APIs, packages that crash on launch, incorrect file structures, or binaries that contain known malware signatures. Automated tests are fast and catch a large proportion of technical issues before any human reviewer is involved. Developers can and should run WACK locally against their MSIX package before submission to catch these problems early.
• Manual review by Microsoft staff: Human reviewers install and interact with the application to verify that it behaves as the store listing describes, that it does not engage in deceptive or harmful behaviour, that declared capabilities match actual usage, and that the content complies with policies. Certain categories of apps — particularly those involving financial services, health data, apps for children, or user-generated content — receive more rigorous manual scrutiny.

One of the most consistently enforced requirements relates to privacy. If an application collects, stores, or transmits any personally identifiable information — including but not limited to names, email addresses, location data, usage telemetry, or device identifiers — it must provide a privacy policy URL as part of the store listing. The URL must point to a live, human-readable document (not a placeholder or coming-soon page) that accurately describes what data is collected, why it is collected, how it is stored and protected, and how users can request deletion or access to their data. Failure to provide a valid privacy policy URL when one is required is one of the most common reasons for certification failure.

When a submission fails certification, Microsoft does not simply reject it silently. Developers receive a detailed certification failure report through Partner Center and by email. The report identifies each specific policy violation or technical failure, cites the relevant policy section number, describes the steps the reviewer took to reproduce the issue, and in most cases provides guidance on how to resolve it. This structured feedback allows developers to address all identified issues and resubmit efficiently. It is important to read the full report carefully — sometimes a single user-facing issue (such as a crash on a specific screen) is listed alongside a policy citation that explains the standard it violated, and both pieces of information are needed to understand and fix the root cause.

Typical causes of certification failure, and the strategies for avoiding them, include:

• App crashes or fails to launch: Run the app on a clean machine against the minimum supported OS version declared in the manifest before submission. Ensure all runtime dependencies (such as the Visual C++ Redistributable or .NET Desktop Runtime) are either bundled in the MSIX or declared as framework package dependencies.
• Functionality not matching the description: Every feature described in the store listing must be present and working. Listing features that are "coming soon" or that require external account credentials not explained in the listing will cause a review failure.
• Missing or inaccurate privacy policy: Audit the application's network activity and data storage carefully. If any personal or device data leaves the user's machine — including through third-party analytics SDKs embedded in the app — a privacy policy is required.
• Undeclared capabilities: If the app accesses location, the microphone, the camera, or contacts without declaring the corresponding capability in the manifest, Windows will block the access and the reviewer will observe broken functionality.
• Misleading metadata: Using competitor brand names as search terms, or including unrelated keywords in the description to game search ranking, violates Store policies on metadata honesty.

Once all issues are resolved and a resubmission passes certification, the app transitions to the In the Store status and becomes available to users in the markets and on the release schedule the developer configured. Microsoft typically targets a certification turnaround of one to three business days for standard submissions, though complex manual reviews or policy edge cases can extend this timeline. Developers can monitor the real-time status of every submission — from Package acceptance through Pre-processing, Certification, and finally Publishing — directly within the Partner Center dashboard.

Publishing a Windows application to the Microsoft Store is a structured process with four main stages: registering a developer account in Microsoft Partner Center, packaging your app (most commonly as an MSIX package), building a store listing with the required metadata and visual assets, and passing certification against Microsoft Store policies. Each stage has concrete requirements — an identity-verified account, a signed and correctly manifested package, screenshots and descriptions at specified sizes and lengths, and content that complies with the Store Policies and Developer Agreement.

This matters in an HCI course because the store listing is often the first interface a user encounters. Your icons, screenshots, short description, and accessibility information shape whether someone installs your app at all, and store requirements effectively impose a baseline of usability, accessibility, and transparency on the product itself. Learning the Microsoft process also gives you a point of comparison with the Apple App Store and Google Play, which solve the same problems with different rules.

As you watch the videos below, note that they come from Microsoft's own developer conference sessions, so they present the publishing pipeline from the platform owner's perspective. Look for the sequence of steps from code to published app, the specific listing elements that influence discoverability and conversion, and the policy and business-model changes that define the current Store. Keep in mind that these sessions are a few years old: always confirm exact size limits, fees, and policy clauses against current Microsoft Partner Center documentation before you submit.

Microsoft Developer · 10:14 · 115 views · 4y ago · captions — Watch on YouTube

About this video

A Microsoft Developer session that walks through the end-to-end app publishing process, from finished code to an app available to customers. Based on its framing, expect coverage of packaging and submission steps, the Partner Center workflow, and practices that help a submission move quickly through review rather than getting stuck.

Why this video

It is the most direct match for the overall submission workflow — account, package, submit, certify — and comes from Microsoft itself, so the described process reflects the platform owner's intended path.

Microsoft Developer · 14:21 · 366 views · 4y ago · captions — Watch on YouTube

About this video

This session focuses on optimizing your Store listing so that customers respond to it, framed around "love at first sight" and increasing downloads. It is likely to address listing elements such as the app title, description, icon, screenshots, and other assets, and how they affect discoverability and install decisions.

Why this video

It targets the Store Listing and Asset Requirements subtopic specifically, and connects asset quality to user perception — exactly the HCI angle on publication materials.

Microsoft Developer · 19:25 · 498 views · 4y ago · captions — Watch on YouTube

About this video

A keynote-style breakout on the rebuilt Microsoft Store and its "open Store" premise, explaining what changed for developers and why. Expect discussion of relaxed packaging and commerce requirements, what kinds of apps are now accepted, and the policy and ecosystem thinking behind those decisions.

Why this video

It provides the policy and platform context behind certification rules and packaging options, helping you understand why Microsoft's requirements differ from Apple's and Google's.

Together these videos cover the Microsoft side of MO1 by laying out the submission pipeline and review expectations that you can then compare with Apple App Store and Google Play requirements. The session on the new Store surfaces the policy and acceptance rules you need in order to assess your own interface project for publication readiness (MO2), while the listing-optimization session models the metadata, screenshots, and descriptive assets you will be asked to prepare to store standards (MO3). Use the publishing best-practices session as the procedural backbone, and verify any specific numbers or policy details against current Partner Center documentation before applying them to your project.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.