What are Windows 11 .appx and .appbundle packages and how do they work?

If you use Windows 10 or Windows 11, sooner or later you'll come across the infamous .appx and .appxbundle files . They might appear when you download a UWP app, browse the Microsoft Store, or follow a tutorial to install apps from outside the store. And of course, you'll naturally wonder what they are, what they're for, and how to install them without messing things up.

These formats replace the classic .exe or .msi installers in Microsoft's modern app ecosystem . There's much more to these names than meets the eye: a different security model , a different way to update, integration with the Microsoft Store, options for mass deployment in enterprises, and even specific PowerShell and DISM commands for managing them. Let's take a closer look so you can use them with ease.

What are .appx and .appxbundle packages in Windows 10 and Windows 11?

A file with the .appx extension is the standard installation package for UWP (Universal Windows Platform) applications introduced with Windows 8 and Windows Phone 8.1. It is a compressed container that follows the OPC (Open Packaging Convention) specification and groups the app ready for installation into a single file: binaries, resources, manifest, permissions, descriptions, icons, etc., similar to an .msi file , but designed for Microsoft's new app model.

The .appx file includes a key file, AppxManifest.xml , which defines the package name, app identifier, version, supported architectures, necessary dependencies, languages, capabilities (permissions), and other additional settings. This allows Windows to install the app without a "Next, Next, Finish" wizard, reducing errors common in traditional Win32 installers.

An .appxbundle, on the other hand, is a "bundle" or grouping of several .appx packages and resources into a single file. In other words, it's an organized collection of application and resource packages (languages, interface scaling, DirectX, etc.) used together to deliver an optimal experience on each device, while minimizing the disk space the application occupies on each specific computer.

The goal of these formats is to allow the same application to be distributed and run uniformly across PCs, tablets, mobile phones, and other devices compatible with Windows 10 and Windows 11, resolving the problems that traditional installers had in mobile or restricted environments. Everything is much more controlled: isolated paths, declarative permissions, clean installation and uninstallation, and the ability to provision apps at the system image level.

Practical difference between .appx and .appxbundle

The distinction between these two formats is important, especially if you manage teams or install apps from outside the Microsoft Store. An .appx file typically contains the app for a specific architecture (for example, x64) and a basic set of resources, while an .appxbundle package includes several versions of that app along with additional resources for different scenarios.

In an .appxbundle file, you can find, for example, the main package for x86, another for x64, another for ARM, and various language or scaling resource packages. Windows will select only the applicable packages during installation, based on the device and operating system configuration. This reduces bandwidth and disk space consumption because the user doesn't need to download languages ​​or architectures they won't use.

This approach is key to the Microsoft Store publishing pipeline. When you upload an app, you can upload .msix, .msixbundle, .appx, .appxupload, and .appxbundle files ; the Store then sorts and decides which specific package is best suited for each device family and Windows version, based on the architecture, package version number, and other metadata.

In environments managed using DISM (Deployment Image Servicing and Management), the behavior also changes: when you add an .appxbundle to an image , only resource bundles that make sense for that image are integrated, as we will see later when discussing language packs and scaling/DXFL resources.

How Microsoft Store manages APPX and APPXBUNDLE packages

The Microsoft Store is the official gateway for most of these apps. When a developer submits an app, they upload all the relevant installation files—.msix, .msixupload, .msixbundle, .appx, .appxupload, and/or .appxbundle—to the Packages section of the publishing dashboard. A developer can upload multiple packages for the same app, and the Store will decide which one to offer to each customer with each download.

After uploading, the publishing console displays a table showing which packages will be delivered to each Windows 10/11 device family (desktop, mobile, Xbox, HoloLens, Surface Hub, IoT, etc.), ordered according to version classification. From there, you can also choose which device families the application will be available on and whether to allow its use on future families as they are released.

If the Store detects errors while validating a package (for example, version issues, poorly defined dependencies, or signature problems), it displays warning messages so the developer can fix the problem, remove the conflicting package, and re-upload it. It can also flag redundant packages when newer versions cover the same set of customers; in that case, it suggests automatically removing them from the submission.

The device family availability section lets you check or uncheck boxes to decide whether the app will be accessible on Windows 10/11 Desktop, Xbox, Windows 10 Team, Windows 10 Holographic, etc. If you upload packages specifically for the Windows.Desktop family, for example, only the desktop box will be activated, and you won't be able to activate the others for those same binaries.

Windows.Universal packages are more versatile: they can run on virtually any Windows 10 or 11 device (including Xbox One). By default, the Store offers them to all eligible families except Xbox, which requires meeting special conditions (for example, being a game within the Xbox Live Creators Program or passing a specific approval process).

Publishing, versions, and package classification

When an update is released for an existing app, the Microsoft Store offers advanced options such as gradual rollout . This allows you to define a percentage of users who will receive the new updates and analyze their behavior and analytics data before rolling out the update to 100% of the installed base.

These updates also allow you to mark an update as mandatory . If the developer has integrated the Windows.Services.Store APIs, the app can check for new versions and force the download and installation of updated packages starting from a specific date and time, provided the device is running at least Windows 10 version 1607.

Internally, the Store ranks packages based on their version numbers. If there are multiple compatible packages for a particular device family (for example, Package_A.appxupload and Package_B.appxupload), the ranking table will show the order in which they will be served. A package with rank 1 takes precedence; if the user's device cannot run it (due to architecture, minimum system version, etc.), the Store will try the next one on the list.

If none of the packages in the set meet the device requirements (for example, because the minVersion property is higher than the installed Windows version), the user will not be able to download or install that app on that computer. This prevents failed installations or inconsistent behavior.

Package management also includes warnings to remove redundant packages when newer versions are available that cover all clients that previously received the older packages. From the console, you can delete these packages individually or use the automatic option to remove all redundant packages in a single step.

What is DISM and how does it work with .appx and .appxbundle packages?

DISM (Deployment Image Servicing and Management) is a command-line tool designed to maintain and modify Windows images , both offline and on running systems. Among its many functions is the management of provisioned application bundles (.appx and .appxbundle) that are automatically installed in user profiles.

The basic DISM syntax for working with images is:

DISM.exe {/Image: | /Online} {maintenance_option}

Commands such as the following are used to maintain application packages provisioned in an offline image:

DISM.exe /Image:

And for a running operating system (online image):

DISM.exe /Online

By using /? after any of these options, DISM displays detailed help about that subcommand, including the available arguments and practical examples, for both online and offline images.

Key DISM commands for APPX packages

DISM offers several specific functions for dealing with provisioned .appx and .appxbundle packages. These tools are very useful for administrators preparing corporate images or deploying UWP applications in bulk.

The `/Get-ProvisionedAppxPackages` option lists all the app packages that are provisioned in the image and will therefore be automatically installed for each new user upon their first login. A typical example would be:

Dism /Image:C:\test\offline /Get-ProvisionedAppxPackages

To add one or more application packages to an image, use `/Add-ProvisionedAppxPackage` . When an app is added this way, it is included in the image and registered for all new and existing user profiles the next time they log in. If the image is online, the current user will not see the registered app until they log out and log back in.

Microsoft recommends provisioning applications on an operating system in audit mode to take advantage of hard links between common files, thus reducing disk space usage and preventing any user from running the apps during the installation and setup process.

Advanced syntax of /Add-ProvisionedAppxPackage

The syntax for /Add-ProvisionedAppxPackage supports several parameters to cover different scenarios:

dism.exe /Add-ProvisionedAppxPackage {/FolderPath: /PackagePath: { } }

The ` /FolderPath` command specifies a folder containing an unpacked application (main package, dependencies, and license). It is only supported for unpacked .appx packages and not for .appxbundle packages.

The /PackagePath option points directly to an .appx or .appxbundle application file. It is valid for provisioning line-of-business applications on online systems, but it is not supported if the host running DISM is on WinPE 4.0, Windows Server 2008 R2, or earlier versions.

The ` /Region` command controls the regions in which the package (.appx or .appxbundle) will be provisioned. You can specify "all" (all regions) or a semicolon-separated list of ISO 3166-1 Alpha-2 or Alpha-3 codes (for example, "US" or "USA"). If no region is specified, the package will only be provisioned if it is anchored to the Home layout.

The ` /DependencyPackagePath` parameter is used to specify each dependency package required by the application. These dependencies are identified by querying the `<PackageDependency>` elements in the parent package's `AppxManifest.xml` file. When multiple apps share the same dependency, the latest minor version of each major version branch of that dependency should be installed to avoid unnecessary duplication.

In mixed architectures, such as an x64 image, dependencies must be included in their applicable variants (x86 and x64). If an ARM dependency package is also specified, DISM will ignore it because it doesn't correspond to the target architecture. On an x86 machine, only x86 dependencies will be installed, and on an ARM device, only ARM dependencies.

License management, custom data, and DISM samples

The ` /CustomDataPath` command allows you to associate an optional custom data file with your app. The filename you specify will be automatically renamed to `Custom.dat` when integrated into the image, and if a `Custom.dat` file already exists for that package, it will be overwritten with the new content.

The ` /LicensePath` option is used in conjunction with `/PackagePath` to point to the .xml file containing the application's license, which is required in certain business scenarios. If the app does not require a license, ` /SkipLicense` can be used , although Microsoft warns that this should only be done in environments prepared for test installations, as using it outside of those scenarios can compromise the validity of the image.

Some typical examples of using DISM with .appx and .appxbundle are:

Dism /Image:C:\test\offline /Add-ProvisionedAppxPackage /FolderPath:c:\Test\Apps\MyUnpackedApp /CustomDataPath:c:\Test\Apps\CustomData.xml

Dism /Online /Add-ProvisionedAppxPackage /PackagePath:C:\Test\Apps\MyPackedApp\MainPackage.appx /DependencyPackagePath:C:\Test\Apps\MyPackedApp\Framework-x86.appx /DependencyPackagePath:C:\Test\Apps\MyPackedApp\Framework-x64.appx /LicensePath:C:\Test\Apps\MyLicense.xml

Dism /Online /Add-ProvisionedAppxPackage /FolderPath:C:\Test\Apps\MyUnpackedApp /SkipLicense

Dism /Image:C:\test\offline /Add-ProvisionedAppxPackage /PackagePath:C:\Test\Apps\MyPackedApp\MainPackage.appxbundle /SkipLicense

Dism /Online /Add-ProvisionedAppxPackage /PackagePath:C:\Test\Apps\MyPackedApp\MainPackage.appxbundle /Region:»all»

These examples show usage with both unpacked app folders and packaged packages, as well as combining them with dependencies, licensing, and specific regions.

Other DISM commands: delete, optimize, and custom data

To remove provisioning for an app package in an image, use `/Remove-ProvisionedAppxPackage` , specifying the package name. This prevents the application from automatically registering with new user accounts created later.

The basic syntax is:

/Remove-ProvisionedAppxPackage /PackageName:

For example:

Dism /Image:C:\test\offline /Remove-ProvisionedAppxPackage /PackageName:microsoft.devx.appx.app1_1.0.0.0_neutral_ac4zc6fex2zjp

DISM also includes the `/Optimize-ProvisionedAppxPackages` option to reduce the overall size of provisioned packages in the image by creating hard links between identical files. This is only possible with offline images and before they are brought online; once the image has booted with those packages, it is no longer possible to optimize what was previously provisioned.

The typical command would be:

DISM.exe /Image:C:\test\offline /Optimize-ProvisionedAppxPackages

For managing custom data with pre-provisioned packages, use `/Set-ProvisionedAppxDataFile` . This option adds (or replaces) a Custom.dat data file for a specific package that has already been added to the image, without needing to re-provision it from scratch.

The syntax is:

/Set-ProvisionedAppxDataFile /PackageName:

Practical example:

DISM.exe /Image:C:\test\offline /Set-ProvisionedAppxDataFile /CustomDataPath:c:\Test\Apps\Custom.dat /PackageName:microsoft.appx.app1_1.0.0.0_neutral_ac4zc6fex2zjp

If a Custom.dat file already exists for that app, it will be overwritten by the new file. This is useful for updating default settings or data without reinstalling the entire package.

StubPackageOption: “stub” packages versus full packages

Another feature associated with .appxbundle management is the /StubPackageOption parameter , which is used in conjunction with application package maintenance options to define the preference between installing a stub version or the full version of an app.

The syntax is:

/StubPackageOption:{installstub | installfull}

Installstub specifies that the provisioned package will be the stub variant, which is typically a minimal container that then downloads additional components from the store when the user runs the app. Installfull provisions the full version of the application directly, so the user has it fully available without further downloads.

If no option is specified, the image's default stub preferences are applied. A real-world example would be:

Dism /image:C:\test\offline /add-provisionedappxpackage /packagepath:»C:\dism\stub\appwithresources.appxbundle» /stubpackageoption:installstub

This is useful when you want to control the initial image size or subsequent download behavior on computers with limited connections.

How does DISM decide which resources from an .appxbundle to add to the image?

When you add an .appxbundle file to a Windows image, not all of the internal packages are considered applicable. DISM evaluates the applicability of resource packages based on the language and certain characteristics of the target hardware.

In the case of language resource packs, if a language is not present in the operating system image, the corresponding app language pack is not added. For example, if the image is Windows with English (US) as the default language and the Spanish (Spain) language pack is also included, the app resource packs for English and Spanish will be installed, but a possible French resource pack will be ignored if it exists in the .appxbundle.

In contrast, the Scale and DirectX (DXFL) resource packs depend on the actual hardware the image will be used on. Since this cannot be determined when provisioning the offline image, DISM adds all the Scale and DXFL resource packs from the batch. Then, on first boot and during the out-of-the-box experience (OOBE) phase, when the user selects a language and the system detects the display and GPU configuration, Windows automatically removes the inapplicable resources.

If the image contains multiple language packs, app resource packs are added for each one. Then, when the first user logs in and selects a language during OOBE, the system cleans up leftover resources (unused languages, scales, or DXFLs that don't match the hardware) to free up disk space.

Practical example: An app supports English (US), French (France), and Spanish (Spain). If an image is added with system languages ​​English and Spanish, the initial image will contain app resources in both languages. If the first user chooses English as their system language, after that first login, the Spanish resources from that app that are not needed for the user's profile will be removed.

Limitations and requirements when installing .appx and .appxbundle packages

Not everything is suitable when installing APPX packages. There are certain Windows version and environment limitations that should be kept in mind to avoid unnecessary errors.

On the one hand, an .appx package cannot be installed on systems that do not support Windows 8 or later applications; and an .appxbundle requires, at a minimum, a system compatible with Windows 8.1 apps. Installation of these apps is not supported in WinPE 4.0 environments, on the Server Core option of Windows Server 2012, or on any version of Windows prior to Windows 8/Windows Server 2012.

For UWP apps to work on Windows Server 2012, you need to install the desktop experience , which enables the capabilities of the modern app platform. In Server Core environments or heavily scaled-down images, these apps are simply not supported.

Furthermore, DISM only supports /FolderPath for unpacked .appx packages, and for .appxbundle packages, /PackagePath must always be used, pointing to the bundled file. Attempting otherwise will result in compatibility or formatting errors when running the command.

It should also be noted that UWP applications are not supported in certain special editions (such as certain variants of WinPE), so even if you manage to copy the .appx file, the operating system will not be able to register or run it correctly.

Install .appx and .appxbundle directly on Windows (without using DISM)

In addition to image management, home users often encounter .appx and .appxbundle files when downloading applications from the Microsoft Store or other sources. On Windows 10 and Windows 11, these can be installed fairly easily, provided certain requirements are met.

To allow these apps to be installed outside the App Store, a special configuration mode called Developer Mode was introduced . This mode allows the execution of APPX packages that are not signed with trusted certificates or that come from sources other than the official store, similar to the option to allow third-party apps in Android.

First, make sure your system has at least the key updates installed (for example, the Anniversary Update for Windows 10). Then, from Settings > Update & Security > For developers, you can enable "Developer mode" or, at least, the trial installation option for apps.

Once the option is enabled and the computer restarted if necessary, installing an .appx or .appxbundle file is as simple as double-clicking the file . Windows opens a UWP app installer that displays the app name, source (for example, Microsoft Store), version, publisher, and the permissions (capability) it requests.

In that window, you can select whether to run the app automatically after installation. Clicking "Install" will allow the system to validate the signature, register the packages, and resolve any necessary dependencies. If the app requires any additional libraries, Windows will download them or install them from the image itself if it's provisioned.

Installing and registering APPX with PowerShell

For advanced users and administrators, PowerShell offers finer control over the installation of .appx and .appxbundle files than the graphical interface. The main cmdlet is Add-AppxPackage , which supports both installing a simple package and registering apps unpacked from their manifest.

If you already have a downloaded .appx or .appxbundle file, simply open PowerShell as administrator and run a command similar to:

Add-AppxPackage -Path «C:\Path\Program.appx»

Obviously, you need to adjust the path and filename to your specific case. If instead of a packaged file you have the unpacked app in a folder, you can register it using the manifest:

Add-AppxPackage -Path C:\Path\Program\AppxManifest.xml -Register

This tells Windows to register that app as if it were installed from an .appx package, which is very useful during development or in scenarios where you want to perform a controlled deployment from a local repository.

In both cases, PowerShell will display detailed errors if any dependencies are missing, if the signature is invalid, or if the package does not comply with system execution policies (for example, if developer mode is not enabled or if the installation policy only allows apps from the Store).

Download UWP apps outside the Microsoft Store: Adguard and similar apps

Although Microsoft encourages users to use the official store, third-party tools exist that allow you to download .appx and .appxbundle packages directly from the company's servers, bypassing the Store interface. One of the best-known is the Adguard website, which acts as a kind of "proxy" for the Microsoft Store.

The idea is simple: first, you get the app's URL from the official Microsoft Store website (for example, by searching for WhatsApp Desktop and copying the address, which includes the product identifier). You paste that URL into the Adguard box, select the desired branch (usually "Retail" for the stable version), and the website generates a list of all the files associated with that app.

The list includes both the main packages (AppxBundle or EAppxBundle) and the signature, dependencies, and other resources. The packages needed to install the application are usually the latest version of the AppxBundle/EAppxBundle for the appropriate architecture (e.g., x64). An SHA1 hash is displayed next to each item to verify the integrity of the download.

Clicking one of these links downloads the file directly from Microsoft's servers, not from AdGuard itself. The user can then install it by double-clicking or using Add-AppxPackage, as described earlier, provided developer mode is enabled if the app requires it.

Advantages, risks, and limitations of installing APPX outside the Store

This "trick" of downloading APPX and APPXBUNDLE from outside the Microsoft Store has a certain appeal: it allows you to keep copies of apps that might be removed in the future or install applications on computers where the Store doesn't work properly or where you don't have access to a Microsoft account.

However, it also has several practical limitations . For starters, downloading a paid app using this method doesn't mean you can use it for free. The Store and the operating system itself integrate DRM mechanisms that require online license validation with a Microsoft account; if this validation isn't performed, the program won't run, even if the package was successfully installed.

Furthermore, by not using the Store normally, you lose the convenience of always receiving the latest available version of the app. If you only keep a copy of the downloaded package, it will likely become outdated in a short time, potentially leading to compatibility issues, bugs already fixed in newer versions, or changes in online services that cause the app to stop working correctly.

In practice, this method only makes sense in specific cases: for example, saving a free app you've already used, that complies with Microsoft's security policies, and that you suspect might disappear from the Store (such as some utilities related to wallpapers, Spotlight, etc.). However, using it as a regular substitute for the Microsoft Store is not recommended.

Another added risk of bypassing the official store is that you might end up downloading packages from untrusted or repackaged sites, with the danger of introducing malware, adware, or unwanted software onto your system. The Store filters and analyzes applications, but intermediary websites don't always offer that guarantee.

Common problems when installing apps from outside the Store

When you choose to install Windows applications from the Internet instead of using the Microsoft Store, a number of common problems arise that you should be aware of, many of them related more to security and compatibility than to the .appx format itself.

The first risk is that the downloaded file may contain viruses or Trojans . When downloading apps directly from third-party websites, there are no guarantees that the installer hasn't been modified or that the page won't redirect you to a different executable file through deceptive banners. In contrast, apps from the App Store undergo compatibility and security checks before being published.

Another common problem is compatibility issues ; in these cases, learning how to use the Event Viewer to diagnose application problems can be helpful. When you download a third-party installer, you might end up installing a version that isn't designed for your Windows edition, architecture, or operating system version, resulting in runtime errors or unpredictable behavior. The Microsoft Store prevents this by restricting the download of apps that don't meet the minimum device requirements.

The user experience of browsing websites overloaded with advertising, pop-ups, and confusing buttons must also be considered. Many sites overuse banners and fake downloads that push users to install additional software (toolbars, extensions, dubious download managers, etc.) that has nothing to do with the app they were originally looking for.

Finally, some apps obtained from outside official channels may include additional components that consume resources or disk space without adding value: trial antivirus software, third-party utilities, toolbars, etc. In the case of UWP apps, if you download unofficial or repackaged versions, the disk size may be larger than that of the original version, precisely because they include "extras" that were not in the certified Store package.

Changing the Role of the Microsoft Store in Windows 11

With the arrival of Windows 11, Microsoft has tried to relaunch the Microsoft Store to make it a more relevant component of the system, after years of relative indifference from many users, who still preferred to download their programs from the developers' official websites.

Among the notable improvements is a revamped interface that is more user-friendly for discovering, downloading, and updating applications, as well as a larger catalog that increasingly includes "conventional" (Win32) programs in addition to UWP apps, bringing the experience closer to what other platforms like macOS, Android, or iOS offer.

For developers, this translates into more distribution channels: they can package their apps in formats like .msix or .appx, publish them in the App Store, and benefit end users with more secure installations, centralized updates, and clean uninstallation. For users, the main advantage is reducing the risk of downloading executables from untrusted websites.

In parallel, Microsoft continues to promote the UWP and APPX package platform , encouraging developers to offer versions adapted to the Store that take better advantage of system integration, even while also maintaining classic installers downloadable from their official pages.

Although the Store has not yet reached the popularity of other ecosystems, the changes introduced in Windows 11 (more apps available, support for different types of packages, performance and design improvements) are in line with making it a key element of the operating system and reducing dependence on installers scattered across the web.

Understanding what .appx and .appxbundle packages are and how they work helps you navigate the Microsoft Store and advanced administration scenarios with DISM and PowerShell with ease: from simply installing a UWP app on your personal PC to bulk provisioning applications in corporate images, or even downloading directly from Microsoft servers when the Store is underutilized or down. Knowing their limitations, requirements, and associated tools makes it much easier to leverage them without compromising Windows security or stability.