App packaging

In Windows 8.1, new app bundles make app submission even simpler than before. And resource packs let you offer extras, like localization or assets for high-resolution displays, to customers who want them, without affecting disk space, bandwidth, or the app-purchase experience for customers who don't.

For specific examples of how to use app bundles for smart app deployment, check out Package your Windows Store DirectX game topic and the Games with resource packages sample.

New or updated in Windows 8.1

App resources

Windows 8.1 introduces a new type of package into the app model. The resource package allows you to separate the core app package from additional resources (for example, French-specific assets like strings or images) and contain those resources in their own package. The resource package thus serves to tailor the app’s overall experience without requiring download and installation of all resource packages to the PC.

The resource package is optional and can’t be depended on by the app package. This means the app package must contain at least one set of default resources that can always be used in case no resource packages were installed on the PC. This helps keep a couple of key promises:

  • The app package can always be installed and launched properly on any PC without resource packages.

  • If the installed resource package is not complete, the app package has resources to fall back on.

The resource package serves two purposes in the app model:

  • Provide resource candidates that the resource-management system can use when the app runs, to tailor the app’s experience.

  • Provide metadata that allows the resource package to target a specific resource qualifier (for example, user scale, system scale, and Microsoft DirectX features).

Resource packages can target only one resource qualifier per package. However, your app can have many resource packages.

App bundles

In addition to the resource package, Windows 8.1 also introduces the app bundle (or .appxbundle package) to help optimize the packaging and distribution of a Windows Store app and resource packages to users all around the world.

You create the app bundle payload for your app. Visual Studio will create and add the bundle manifest. When Microsoft Visual Studio Express 2013 for Windows bundles your app, it automatically splits the resources into separate packages and adds the app block map and signature files to the bundle. The following items make up a fully self-contained Windows Store app that can be deployed to systems beginning with Windows 8.1.

App packages (.appx)

The app bundle can contain more than one app package only if they each target a different specific architecture. For example, it can contain both an X86.appx and an amd64.appx package, but not two amd64.appx packages.

Resource packages (.appx)

The app bundle contains resource packages (.appx files) for language, scale, and DirectX feature level. Each app bundle can contain many different resource packages to support different device configurations. When directly referencing a resource package in your Windows Store app you should make full use of the resource management system.

Note  Resource packages must never contain code.

App bundle manifest (AppxBundleManifest.xml)

The app bundle manifest (.appxbundlemanifest file) contains all of the applicability info about the contained packages. For any particular package, it specifies the type of package ("Application" or "Resource") plus version and resource-targeting info. Specifically for app packages, the app bundle manifest includes info about the architecture.

In general, the app bundle manifest allows the Windows 8.1 app model to understand the contents of the app bundle and determine at installation time which app package and resource packages should be installed on the user's device.

Here's an example of an app bundle manifest file.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Bundle xmlns="" SchemaVersion="1.0">
  <Identity Name="Example" Publisher="CN=ExamplePublisher" Version="2013.101.312.1053"/>
    <Package Type="application" Version="" Architecture="x86" FileName="AppPackage_X86.appx" Offset="49" Size="3207">
        <Resource Language="en-us"/>
        <Resource Scale="100" />
    <Package Type="application" Version="" Architecture="x64" FileName="AppPackage_X64.appx" Offset="3329" Size="3204">
        <Resource Language="en-us"/>
        <Resource Scale="100" />
    <Package Type="resource" Version="" ResourceId="French" FileName="ResourcePackage_French.appx" Offset="6606" Size="1423">
        <Resource Language="fr"/>
        <Resource Language="fr-fr"/>
        <Resource Language="fr-ca"/>
    <Package Type="resource" Version="" ResourceId="HiRes" FileName="ResourcePackage_HiRes.appx" Offset="8111" Size="1584">
        <Resource Scale="140"/>

App block map (AppxBlockMap.xml)

The block map file lists all the files contained in the bundle (except app and resource packages), along with associated cryptographic hash values that the operating system uses to validate file integrity and to optimize an update for the app. For more info about the block map file, see App package block map.

App signature (AppxSignature.p7x)

The app bundle signature ensures that the package and contents haven't been modified since they were signed. If the signing certificate validates to a Trusted Root Certification Authorities Certificate, the signature also identifies who signed the package. The signer of the package is typically the publisher or author of the app.

Note  If you want to bundle your app manually, you can use the standalone MakeAppx and SignTool utilities. To learn more about how to bundle and deploy Windows Store apps, see Packaging, deployment, and query of Windows Store apps.

Package identity

As is true for the Windows 8 app package, one of the most fundamental elements of the app bundle is the five-part tuple that identifies the bundle. This is called the package identity and it consists of this data.


A general name that is used for the app package. For example, "myCompany.mySuite.myApp".

Note  This name isn't necessarily what is displayed on the app tile.

The publisher of the Windows Store app. In most cases, the publisher is the same as the account that was used to register for a Windows 8 developer account.


A four-part version descriptor ( that is used to service future releases of the app (for example, "").


Set to neutral by default.


Set to "~" by default.


App bundle deployment

The deployment of app bundles via the Windows Store follows this workflow.

app packaging flow

The Windows Store app deployment process occurs in multiple phases. Initially, Windows 8.1 acquires and validates the app bundle manifest, bundle block map, and bundle signature. Next, Windows 8.1 checks the bundle manifest to ensure that there is an app that can be deployed on the current architecture. When the right app package has been found, Windows 8.1 checks the app package’s deployment criteria to make sure that the app deployment will be successful.

Then Windows 8.1 determines the subset of applicable resource packages for deployment and stages these package binaries to the \WindowsApps\ directory. Finally, Windows 8.1 registers the app package and resource packages into the user's account.


After the user starts to install a Windows Store app, Windows 8.1 must complete these checks before deployment can begin.


Architecture support

The bundle can contain up to three architecture-specific app packages, all specified in the app bundle manifest.

Minimum operating-system version

You specify prerequisites within the app package manifest. They express the requirement for a specific minimum operating-system version. For example, for Windows 8.1 the appropriate version number is 6.3. For more info about app prerequisites, see App packaging pre-requisites.

App dependencies

A Windows Store app can express a dependency on another component package for added functionality that the app needs. For more info about app dependencies, see App packaging dependencies.

Disk space

Each Windows Store app requires a certain amount of disk space for deployment. If there isn't enough disk space to deploy the package, deployment fails.

Signature check

Each file in the app package must have its integrity checked against the already validated BlockMap.


Package applicability

After Windows 8.1 verifies that the app bundle can be deployed on the system, it then determines what resource packages should be deployed alongside the app package to enhance the user’s experience. Applicability is checked based on these three specific resource qualifiers.


User language

Any language that the user has added into the preferred languages list is counted toward the final set of applicable language resource packages to be deployed. Windows 8.1 supports many locales and languages for resource packages.

System scale

Scale values for all monitors are used to determine the final set of applicable scale resource packages to be deployed. Windows 8.1 supports three scale factors for resource packages; scale-100, scale-140 and scale-180.

DirectX feature level

All DirectX feature levels available on the system are used to determine the final set of applicable DirectX resource packages to be deployed. Windows 8.1 supports three DirectX feature levels for resource packages; DXFL-DX9, DXFL-DX10 and DXFL-DX11.


Package staging

After Windows 8.1 determines that the app bundle can be deployed on the system and which packages to deploy, the package contents are downloaded to the \WindowsApps\ directory. A new directory is created for each package downloaded and is named by using the package identity name value, like this.

<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

The staging process occurs via a set of requests made by the deployment engine to the source of the package’s location. These requests are then satisfied by the source and returned to the deployment engine where they are decompressed, validated against the BlockMap, and copied into the appropriate file.

Package registration

Package registration is the final phase in the deployment process. During this phase, two key operations occur:

  • The extensions that are declared in the app package manifest are registered with the operating system. This enables the app to integrate deeply with the operating system. For example, if you want your app to be able to open text (.txt) files, declare a FileTypeAssociation extension as XML in your app package manifest and specify ".txt" as the file type.

    At deployment time, this XML is translated into the set of system changes required to properly register the app to handle .txt files. These changes are then made by the app model on behalf of the app. The app model supports many different extensions. For more info about these extensions, see App contracts and extensions.

  • All resource packages are registered with the resource management system. which can then use them to optimize the user's experience when the app runs.



© 2015 Microsoft