Designing a simple and secure app package – APPX

When we started working on the new Windows 8 development platform one of the first questions we had was “how do you package an app into a simple yet secure format?” Before Windows 8 there were two primary installation technologies: Windows Installer and ClickOnce. As discussed in the Delivering reliable and trustworthy apps blog post, many products help developers manage the complexities of installing and updating apps. However, app packaging, installation, and updating continue to frustrate developers and end-users. A main goal for packaging and deploying apps was to eliminate the need for installation scripts altogether, making the process more straightforward.

Windows Store apps were additionally challenged to support both existing technologies for native-code and managed-code, plus new technology delivered through the Windows Runtime. More importantly, we wanted to open app building to a new group of developers – developers who had great new ideas but were just learning to create apps for the first time. We needed something easy for developers to use; something to support a range of app technologies; something efficient to package, install, and update. Something secure, and ideally, simple – quite a wish list! The result is the Windows 8 APPX (“.appx”) app package format.


Our focus was to keep it simple. Previous installer technologies required you learn to write install scripts or use special tools to build the app into a specialized binary format. For Windows Store apps, we stepped back and looked to build upon existing standards rather than invent yet another. We created summaries of all known app packaging technologies that we found, scoured each, and weighed the tradeoffs of various features. After many discussions we resolved on a simple but popular starting base – ZIP.

As popular as ZIP is, it’s an older technology that’s been around since 1989. This is both good and bad. Good in that ZIP is widely known and supported, but not so good in that it also predates many newer technology advancements such as the modern Web and XML. Also the ZIP format specification includes requirements for many older features (such as for spanning multiple floppy disks – remember those?) that aren’t relevant for today’s technologies. One of the biggest challenges, however, was that while the ZIP is a de-facto standard, it wasn’t truly an open international standard. Enter OPC.

Building on Standards: ZIP + Web + XML = OPC

In 2006 the Office team working with other Microsoft groups proposed a new Open Packaging Conventions (OPC) standard to be released to the public as an open International standard. OPC was initially released in 2006 as an ECMA International standard in ECMA 376-2 and in 2008 was adopted by the International Standards Organization in ISO/IEC 29500-2.

Building on Standards

Figure 1: Building on Standards

ECMA 376-2 and ISO 29500-2 OPC standards make reference to the APPNOTE.TXT – .ZIP File Format Specification, but a power of OPC is in the specific qualifications that it places on ZIP functionality. OPC also integrates concepts of Web technologies (for example, URI-compliant names) and standardizes on XML as its machine- and human-readable declarative technology. A key point is that OPC is not just a file format; rather, it’s also a ZIP-based container-file technology for defining and creating new file formats. In addition to its origin for the Office 10 Word (.docx), Excel (.xlsx), and PowerPoint (.pptx) formats, OPC is is becoming more popular with many new Microsoft and third-party file formats (Wikipedia: File Formats using OPC).

Another benefit of OPC is that there were existing public OPC APIs available, tested, and ready to use for both managed-code (Sytem.IO.Packaging) and native-code (Data Access and Storage | Packaging). Using the public OPC APIs as a foundation, we created public App Packaging and Deployment APIs specific for APPX. The APPX APIs in turn are used to build associated App Packaging Tools. All APPX tools and APIs are publically available as part of the Windows 8 SDK.

App Building Basics

Windows Store apps can be built using either an IDE provided by Visual Studio Express 2012, or “standalone” using tools like a simple text editor along with the app packaging tool MakeAppx.exe provided with the Windows 8 SDK. Simple web apps, for example, can be written with just a text editor or your favorite HTML editor and then packaged with MakeAppx utility that works similar to a ZIP tool.

A key feature of APPX packages is declarative XML used to define the app’s system requirements needed to deploy, display, and update an app. Rather than use a binary database that requires special tools and often custom scripting, the application package manifest, defined in “AppxManifest.xml”, specifies the application details for identity, dependencies, capabilities, visual elements, and contracts that the app uses. Every Windows Store app contains a package manifest file. Visual Studio will automatically create one for you or you can use your favorite text editor to create a package manifest manually. This code example shows a sample AppxManifest.xml file.

<Package xmlns="">
<Identity Name="MyCompany.MyAppSuite.MyApp" Version=""
Publisher="CN=C58FDA15-2FCE-4CFB-ACA0-3981ED7222D7" />
<Resource Language="en-US" />
<Application Id="App" StartPage="default.html">
<VisualElements DisplayName="Postcards App" Description="Postcards App ..."
Logo="images\postcards-logo-lg.png" SmallLogo="images\postcards-logo-sm.png"
ForegroundText="light" BackgroundColor="#0084FF" ToastCapable="true">
<DefaultTile ShowName="true" />
<SplashScreen BackgroundColor="" Image="images\postcards-splash.png" />
<Extension Category="" StartPage="default.html" />

For security, all APPX packages must be digitally signed. As a first step to secure the app, Visual Studio 2012 and the MakeAppx utility create and insert an AppxBlockMap.xml file when building each APPX ZIP package. The blockmap file stores the cryptographic block hashes for every file in the package, and the blockmap file itself is verified and secured with a digital signature when the package is signed. The blockmap file allows APPX packages to be downloaded and validated incrementally, and also works to support diff updates to the app files after they’re installed.

The next image shows the process using Visual Studio 11 Express or the MakeAppx.exe utility to organize your app files into an APPX package.

Creating an APPX package using Visual Studio 11 Express or MakeAppx utility

Figure 2: Creating an APPX package using

Visual Studio 11 Express or MakeAppx utility

Making it easy to package your app is one step. Making it easy to secure the app is the next step.


Of course application security is a critical concern, especially for consumers. As with many other packaging technologies, APPX packages use digital signatures to guard app security. A digital signature doesn’t prevent the signed app content from being altered, but a signature check will fail if any item in the signed content has changed.

For developers creating apps to distribute through the Windows Store, signing is simple – the store takes care of it for you. After you’ve created your app, you log into the Windows Store developer portal and upload (https) your .appx file. The Windows Store performs a series of checks and then signs your app with a certificate containing your registered developer name. Once signed, the app is posted to the Windows Store and can be downloaded to deploy – it doesn’t get much simpler than that!

If you’re building apps for enterprise or for test use, you can also sign your APPX package on your own. Visual Studio Express 2012 helps do this for you, or you can use the standard Windows SignTool utility to add an Authenticode signature to your package. Figure 3 shows the signing process for an APPX package using either Visual Studio Express or Windows SignTool.

Signing an APPX package using Visual Studio 11 Express or standalone using SignTool

Figure 3: Signing an APPX package using

Visual Studio 11 Express or standalone using SignTool

Digital signatures provide two key functionalities:

  • Securely identify the originator of the signature ( “who is signing”)
  • Verify that the signed content hasn’t been changed

APPX packages set a strict high bar for security – all APPX packages must be signed and the signature validated before they can be installed. Signing provides users confidence in the apps they’re running, and provides a means to periodically verify that the original app files haven’t been modified by a malicious user or third-party software. For consumers downloading packages from the Windows Store, apps must pass Windows Store quality and anti-virus checks, and then be signed by the Windows Store before they’re made available for downloading.

App Security

APPX digital signatures serve multiple uses, and several design aspects are helpful for enterprise IT admins and third-party developers to understand. Windows Store apps employ a three-part security model:

  • Packaged app security
  • Deployed app security
  • Runtime app security

Packaged App Security

Typically most installer technologies sign the deployment container as a unit. APPX packages digital signatures are designed to provide validation as a package unit or incrementally.

Package Validation

Signing the APPX ZIP file as a unit provides an initial level of protection over the entire package. In addition to the app content files stored within the ZIP, a ZIP file also contains internal structures (for example, local file headers, data descriptors, and central directory) that must be protected. Signing the APPX as a unit ensures that all content, including internal structures, can be validated by the digital signature when checking for any alterations.

Incremental Validation

Signed as a unit, the entire file must be present to validate the package. When transferring a package over the web, however, it’s preferable to detect content failures quick and early. To do this, every APPX package contains an AppxBlockmap.xml file that specifies the cryptographic hashes for every block contained in every app content file. Using the hash values contained in the AppxBlockmap.xml file, the contents of each application file can be validated incrementally as it’s downloaded over the web.

Deployed App Security

While previous technologies allowed certain files to be signed individually (.exe’s and .dll’s), unless a particular file type itself supported digital signatures, there was no way to validate many types of application files after they were installed.

Text, JavaScript, XML and many other common file types don’t natively support digital signatures. A feature of the APPX digital signature design is that by deploying the packaged APPX signature files (AppxSignature.p7x and AppxBlockmap.xml) together with the other application content files copied to the client, any or all the application files can be re-validated later.

Important: APPX digital signatures effectively sign every file contained in the app package and can also be used to validate the app files after they’re extracted and installed on disk!


Figure 4: Deploying a signed APPX package

Runtime App Security

Windows Store apps already have improved runtime security by executing within a special protected app container environment. If an app executes within its container, it can’t directly interact or affect other apps. Also, the app has limited gated access to hardware and system resources. The Delivering reliable and trustworthy apps blog post highlights features of the app container environment.


The new APPX package format for Windows Store apps employs innovative technologies to make app packaging simple and secure. These packages take advantage of the standards based OPC format and are easy to create using either Visual Studio Express 2012 or the standalone MakeAppx tool to make packaging your app simple. By using digital signatures we can ensure that each package is valid and your end-users are secure.

Have fun building apps using APPX packages!

–Jack Davis, Program Manager – Windows

Comments (5)

  1. Matt says:

    Good info. Is this why store apps' startups are very slow? Because it's validating the hashes? Many reviews on the internet complained about slow app startup. I sure hope you guys will address the startup speed issue in next release or patches. Otherwise, great job guys!

  2. Pamelia Hopes says:


    I can’t stop my hand to write something, after reviewing your Blog. Really you have initiated the update things that every people will love to read. Hope you will keep continues to post more updated Blogs in your next post. Keep It Up!

    @Orimark Tech

  3. Lukas says:

    Currently it is easily possible to alter the deployed XAML files e.g. to remove ad elements from the App UI. There is even a tool available wich does this automatically for all installed Apps. Why does Windows not automatically check the signature of all files upon startup (perhaps in the background to improve speed)?

    Is there a way for the App to trigger this validation manually? Under "Deployed App Security" you say that this is possible, but without telling us how this can be achieved.

  4. anyone who refers to a windows program as an "app" should be banned from using windows for life. ms needs to STOP COPYING APPLE. its a surefire way to fail.

  5. Thanks for sharing the knowledge on this architecture. Excelent info and very interesting, I will hope the next post .