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.

Package details

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.

Mandatory update

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.

A screenshot of the overview of Packages section in Partner Center.

You must complete the Packages page for at least one package. To add package, click Add package from Packages page.

A screenshot of the Packages section showing the overview of package details.

Add and edit Package info

To edit Package info, select the Package from the Packages page. You must edit each package separately.

Package URL

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.

A screenshot of the Packages section where you can provide your package URL details.

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:

  • x86
  • x64
  • neutral
  • arm
  • arm64

A screenshot of the Packages section where you can provide your app architecture details.

If you have packages compiled in more than 1 architecture, you should add them to the submission.


A screenshot of the Packages section where you can provide the languages your app supports.

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
Afrikaans af, af-za
Albanian sq, sq-al
Amharic am, am-et
Armenian hy, hy-am
Assamese as, as-in
Azerbaijani az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az
Basque (Basque) eu, eu-es
Belarusian be, be-by
Bangla bn, bn-bd, bn-in
Bosnian bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba
Bulgarian bg, bg-bg
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
Czech cs, cs-cz
Danish da, da-dk
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
Estonian et, et-ee
Filipino fil, fil-latn, fil-ph
Finnish fi, fi-fi
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
Galician gl, gl-es
Georgian ka, ka-ge
German de, de-at, de-ch, de-de, de-lu, de-li
Greek el, el-gr
Gujarati gu, gu-in
Hausa ha, ha-latn, ha-latn-ng
Hebrew he, he-il
Hindi hi, hi-in
Hungarian hu, hu-hu
Icelandic is, is-is
Igbo ig-latn, ig-ng
Indonesian id, id-id
Inuktitut (Latin) iu-cans, iu-latn, iu-latn-ca
Irish ga, ga-ie
isiXhosa xh, xh-za
isiZulu zu, zu-za
Italian it, it-it, it-ch
Japanese ja , ja-jp
Kannada kn, kn-in
Kazakh kk, kk-kz
Khmer km, km-kh
K'iche' quc-latn, qut-gt, qut-latn
Kinyarwanda rw, rw-rw
KiSwahili sw, sw-ke
Konkani kok, kok-in
Korean ko, ko-kr
Kurdish ku-arab, ku-arab-iq
Kyrgyz ky-kg, ky-cyrl
Lao lo, lo-la
Latvian lv, lv-lv
Lithuanian lt, lt-lt
Luxembourgish lb, lb-lu
Macedonian mk, mk-mk
Malay ms, ms-bn, ms-my
Malayalam ml, ml-in
Maltese mt, mt-mt
Maori mi, mi-latn, mi-nz
Marathi mr, mr-in
Mongolian (Cyrillic) mn-cyrl, mn-mong, mn-mn, mn-phag
Nepali ne, ne-np
Norwegian nb, nb-no, nn, nn-no, no, no-no
Odia or, or-in
Persian fa, fa-ir
Polish pl, pl-pl
Portuguese (Brazil) pt-br
Portuguese (Portugal) pt, pt-pt
Punjabi pa, pa-arab, pa-arab-pk, pa-deva, pa-in
Quechua quz, quz-bo, quz-ec, quz-pe
Romanian ro, ro-ro
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
Sinhala si, si-lk
Slovak sk, sk-sk
Slovenian sl, sl-si
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
Tamil ta, ta-in
Tatar tt-arab, tt-cyrl, tt-latn, tt-ru
Telugu te, te-in
Thai th, th-th
Tigrinya ti, ti-et
Turkish tr, tr-tr
Turkmen tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr
Ukrainian uk, uk-ua
Urdu ur, ur-pk
Uyghur ug-arab, ug-cn, ug-cyrl, ug-latn
Uzbek (Latin) uz, uz-cyrl, uz-latn, uz-latn-uz
Vietnamese vi, vi-vn
Welsh cy, cy-gb
Wolof wo, wo-sn
Yoruba yo-latn, yo-ng

App type

Select your app type – (EXE/MSI). If you choose EXE, you are required to provide Installer parameters and details for Installer handling.

A screenshot of the Packages section where you can provide the type (msi/exe) of your app.

A screenshot of the Packages section showing the the additional fields required for exe type of apps.

Installer parameters

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.

A screenshot of the Packages section where you can provide the installer parameters for your app.

For MSI aps, the Store uses the default silent switch ‘/qn’ to run your installer in silent mode.

Installer handling for your EXE app

A screenshot of the section of the Partner Center package details page where you can specify which return codes correspond to which installer outcomes.

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:

Scenario Description
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.