Upload app packages
The Packages page page of the app submission process is where you upload all of the package files (.msix, .msixupload, .msixbundle, .appx, .appxupload, and/or .appxbundle) for the app that you're submitting. You can upload all your packages for the same app on this page, and when a customer downloads your app, the Store will automatically provide each customer with the package that works best for their device. After you upload your packages, you’ll see a table indicating which packages will be offered to specific Windows 10 or Windows 11 device families (and earlier OS versions, if applicable) in ranked order.
You can no longer upload new XAP packages built using the Windows Phone 8.x SDK(s). Apps that are already in Store with XAP packages will continue to work on Windows 10 Mobile devices. For more info, see this blog post.
For details about what a package includes and how it must be structured, see App package requirements. You'll also want to learn about how version numbers impact which packages are delivered to specific customers and how to manage packages for various scenarios.
Uploading packages to your submission
To upload packages, drag them into the upload field or click to browse your files. The Packages page will let you upload .msix, .msixupload, .msixbundle, .appx, .appxupload, and/or .appxbundle files.
For Windows 10, we recommend uploading the .msixupload or .appxupload file here rather than .msix, .appx, .msixbundle, or .appxbundle. For more info about packaging UWP apps for the Store, see Packaging a UWP app with Visual Studio.
If you have created any package flights for your app, you’ll see a drop-down with the option to copy packages from one of your package flights. Select the package flight that has the packages you want to pull in. You can then select any or all of its packages to include in this submission.
If we detect errors with a package while validating it, we'll display a message to let you know what's wrong. You'll need to remove the package, fix the issue, and then try uploading it again. You may also see warnings to let you know about issues that may cause problems but won't block you from continuing with your submission.
Device family availability
After your packages have been successfully uploaded, the Device family availability section will display a table that indicates which packages will be offered to specific Windows 10 or Windows 11 device families (and earlier OS versions, if applicable), in ranked order. This section also lets you choose whether or not to offer the submission to customers on specific Windows 10 or Windows 11 device families.
For more info, see Device family availability.
Your uploaded packages are listed here, grouped by target operating system. The name, version, and architecture of the package will be displayed. For more info such as the supported languages, app capabilities, and file size for each package, click Show details.
If you need to remove a package from your submission, click the Remove link at the bottom of each package's Details section.
Removing redundant packages
If we detect that one or more of your packages is redundant, we'll display a warning suggesting that you remove the redundant packages from this submission. Often this happens when you have previously uploaded packages, and now you are providing higher-versioned packages that support the same set of customers. In this case, no customers would ever get the redundant package, because you now have a better (higher-versioned) package to support these customers.
When we detect that you have redundant packages, we'll provide an option to remove all of the redundant packages from this submission automatically. You can also remove packages from the submission individually if you prefer.
Gradual package rollout
If your submission is an update to a previously published app, you'll see a checkbox that says Roll out update gradually after this submission is published (to Windows 10 or Windows 11 customers only). This allows you to choose a percentage of customers who will get the packages from the submission so that you can monitor feedback and analytic data to make sure you’re confident about the update before rolling it out more broadly. You can increase the percentage (or halt the update) any time without having to create a new submission.
For more info, see Gradual package rollout.
If your submission is an update to a previously published app, you'll see a checkbox that says Make this update mandatory. This allows you to set the date and time for a mandatory update, assuming you have used the Windows.Services.Store APIs to allow your app to programmatically check for package updates and download and install the updated packages. Your app must target Windows 10, version 1607 or later in order to use this option.
For more info, see Download and install package updates for your app.
The Packages page of the app submission process is where you provide the packages (MSI/EXE) and associated information for the app that you're submitting. When a customer downloads your app, the Store will automatically provide each customer with the package that works best for their device.
You must complete the Packages page for at least one package. To add package, click Add package from Packages page.
Add and edit Package info
To edit Package info, select the Package from the Packages page. You must edit each package separately.
You must enter at least one versioned secure URL pointing to app package (MSI/EXE) hosted on your CDN. An example of versioned secure URL is https://www.contoso.com/downloads/1.1/setup.exe. When customer installs your app from the Store, the Store downloads the package from this URL. You need to follow good CDN practices and ensure that this URL is performant, reliable, and available based on your market selection.
If you need to update the package URL, you may use the Update submission option in Partner Center to specify a new package URL.
The binary on the package URL must not change after it is submitted to ensure only certified binaries are installed by users. The Store will retain copies of your most recent app packages to distribute in case the app installer hosted by you on a separate hosting service, such as a content delivery network (CDN), is swapped with new app installer packages without submission through Partner Center or API. The Store will also download the new app packages and initiate the process of certification. If the updates pass certification tests, the Store makes them available for end users. If the updates fail certification tests, the Stores notifies you to submit the updates through Partner Center or API.
You must submit a standalone/offline installer and not a downloader that downloads binaries when invoked. This is required to certify the binaries that get installed are the same ones that passed the certification process.
You must select the architecture of the code contained in the package from one of the following values:
If you have packages compiled in more than 1 architecture, you should add them to the submission.
You can submit apps to the Microsoft Store in over 100 languages. Your app must support at least one of the following languages.
Language codes not listed here are not supported by the store.
|Language name||Supported language codes|
|Azerbaijani||az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az|
|Basque (Basque)||eu, eu-es|
|Bangla||bn, bn-bd, bn-in|
|Bosnian||bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba|
|Catalan||ca, ca-es, ca-es-valencia|
|Cherokee||chr-cher, chr-cher-us, chr-latn|
|Chinese (Simplified)||zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg|
|Chinese (Traditional)||zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw|
|Croatian||hr, hr-hr, hr-ba|
|Dari||prs, prs-af, prs-arab|
|Dutch||nl, nl-nl, nl-be|
|English||en, en-au, en-ca, en-gb, en-ie, en-in, en-nz, en-sg, en-us, en-za, en-bz, en-hk, en-id, en-jm, en-kz, en-mt, en-my, en-ph, en-pk, en-tt, en-vn, en-zw|
|Filipino||fil, fil-latn, fil-ph|
|French||fr, fr-be , fr-ca , fr-ch , fr-fr , fr-lu, fr-cd, fr-ci, fr-cm, fr-ht, fr-ma, fr-mc, fr-ml, fr-re, frc-latn, frp-latn|
|German||de, de-at, de-ch, de-de, de-lu, de-li|
|Hausa||ha, ha-latn, ha-latn-ng|
|Inuktitut (Latin)||iu-cans, iu-latn, iu-latn-ca|
|Italian||it, it-it, it-ch|
|Japanese||ja , ja-jp|
|K'iche'||quc-latn, qut-gt, qut-latn|
|Malay||ms, ms-bn, ms-my|
|Maori||mi, mi-latn, mi-nz|
|Mongolian (Cyrillic)||mn-cyrl, mn-mong, mn-mn, mn-phag|
|Norwegian||nb, nb-no, nn, nn-no, no, no-no|
|Portuguese (Portugal)||pt, pt-pt|
|Punjabi||pa, pa-arab, pa-arab-pk, pa-deva, pa-in|
|Quechua||quz, quz-bo, quz-ec, quz-pe|
|Russian||ru , ru-ru|
|Scottish Gaelic||gd-gb, gd-latn|
|Serbian (Latin)||sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs|
|Serbian (Cyrillic)||sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs|
|Sesotho sa Leboa||nso, nso-za|
|Setswana||tn, tn-bw, tn-za|
|Sindhi||sd-arab, sd-arab-pk, sd-deva|
|Spanish||es, es-cl, es-co, es-es, es-mx, es-ar, es-bo, es-cr, es-do, es-ec, es-gt, es-hn, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us, es-uy, es-ve|
|Swedish||sv, sv-se, sv-fi|
|Tajik (Cyrillic)||tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn|
|Tatar||tt-arab, tt-cyrl, tt-latn, tt-ru|
|Turkmen||tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr|
|Uyghur||ug-arab, ug-cn, ug-cyrl, ug-latn|
|Uzbek (Latin)||uz, uz-cyrl, uz-latn, uz-latn-uz|
Select your app type – (EXE/MSI). If you choose EXE, you are required to provide Installer parameters and details for Installer handling.
The Store will need to run your installer in silent mode. To support this, you need to provide the required switches, such as /s, specific to installer for your EXE app. This is not required if your installer runs in silent mode by default, without any switches.
For MSI aps, the Store uses the default silent switch ‘/qn’ to run your installer in silent mode.
Installer handling for your EXE app
EXE apps usually have installers that return custom codes during installation. The Store supports suitable customer facing messages and actions for the custom return codes provided by you.
The following are the standard install scenarios supported by the Store:
|Installation cancelled by user||The install operation was cancelled by the user.|
|Application already exists||The application already exists on the device.|
|Installation already in progress||Another installation is already in progress. User needs to complete the installation before proceeding with this install.|
|Disk space is full||The disk space is full.|
|Reboot required||A restart is required to complete the install.|
|Network failure||Provide custom return code values for various network related failures.|
|Package rejected during installation||Package rejected during installation due to a security policy enabled on the device.|
|Installation successful||Installation has been successful.|
You can add more than 1 return code for each of the above scenarios depending on your installer behavior.
For scenarios beyond the above list of standard scenarios, customers are directed to your installer return code documentation. For miscellaneous install failure scenarios, you can add your custom return codes along with return code specific documentation URL that Store can point customers to.
We highly recommend this information to be provided for EXE apps so the Store can provide tailored experience to customers. This will also help the Store to treat and report your app installs for EXE apps.
After adding the package, click on Save draft. You will be back on Manage Packages page. In the List of packages, you will see your package has been added. After verifying that your package has been added in the List of packages, click on Save All. You will see a message that your package is uploading and after a successful upload, you will get a message as Saved Successfully.
App packages are currently not supported for add-ons.
Submit and view feedback for