Upload app packages

The Packages 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.

Important

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.

Important

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.

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.

Package URL
Required

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.

Architecture
Required

You must select the architecture of the code contained in the package from one of the following values:

• x86
• x64
• neutral
• arm
• arm64

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

Languages
Required

You can submit apps to the Microsoft Store in over 100 languages. Your app must support at least one of the following languages.

Note

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
Required

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

Installer parameters
Required

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 apps, the Store uses the default silent switch ‘/qn’ to run your installer in silent mode.

Installer handling for your EXE app
Required

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.

Important

App packages are currently not supported for add-ons.