Go the modern (app) way

Go the modern (app) way

  • Comments 2
  • Likes

Hello everyone,

This is Ashfana from the Windows Performance team. I’m here to talk about the basic philosophy behind Windows Store Apps which were introduced in Windows 8 and Windows 8.1. Windows Store apps were originally called Metro or modern apps before the RTM of the product. These are apps developed using a variety of languages like C#, C++, VB, HTML and Javascript, - which provide the modern, full screen immersive experience.

Windows has the largest software ecosystem thanks to millions of developers around the world, and Microsoft’s focus on ensuring backward compatibility for application software. This ecosystem has evolved over time and has reached a stage where – we aren’t able to fix some of the limitations and move ahead without causing existing applications to break. Some limitations are installation/uninstallation problems, Software state corruption, uncontrolled modification of important system registries and files, unreliable installer components, one app causing another one to crash, and security risks when running Apps under elevated token. This new App model was introduced to address these reliability and security issues and to develop a new ecosystem that allows Apps to run on multiple hardware platforms with minimum efforts for the developer.

Here are some of the features of Store Apps that make it very attractive for consumers and enterprises:

  • Windows Store apps do not need an installer. They are either sideloaded to the image using DISM, or installed via Add-AppxPackage PowerShell Command, or installed directly from the Store or a Azure based portal. You no longer need MSI or other installer components, Windows already has the necessary components that can extract the Appx package and install it.
  • Apps are installed per-user (unless they are sideloaded into the image before deployment). They maintain their state within folders in the user’s profile. This ensures better security.
    Apps run within a sandbox environment called an App container. This restricts an App from accessing much of the system and the users profile by default. Additional resources can be requested by an App by declaring capabilities within its manifest file. During first launch of the App, the user is prompted to allow/confirm access to these additional resources.
  • Desktop Apps run under medium integrity and are able to access full privileges granted to a user. An untrusted desktop application can pose a greater risk. Windows Store Apps on the other hand run under base privilege and hence provides a greater level of protection.
  • The Appx manifest and blockmap tell Windows how to install the App, chances of an installation going corrupt are very less. Even if an installation goes corrupt – it would not affect the system in any way.
  • Store Apps provide an immersive experience, are generally very lightweight, and are best suited for scenarios where hard core processing can be done at the server side and results can be delivered to the App over the network.
  • With the introduction of Universal Apps in Visual Studio 2013 update 2, developers can now write an App once and port it to run on multiple devices such as Xbox, Windows phones, PC, tablets and laptops. This makes application development time much shorter.

Structure of a Windows Store/Universal App:

Windows Store app are packaged into one or more files with the extension .appx. This appx package is the unit of installation for a Windows Store app. Appx packages are ZIP-based container files that contains the app’s payload files plus info needed to validate, deploy, manage, and update the app. From a high-level view, each Windows Store app package contains these items:

image

App payload
App code files and assets
Payload files are the code files and assets that you author when you create your Windows Store app.

App manifest
App manifest file (AppxManifest.xml)
The app manifest declares the identity of the app, the app's capabilities, and info for deploying and updating.

App block map
App package’s block map file (AppxBlockMap.xml)
The block map file lists all the app files contained in the package along with associated cryptographic hash values that the operating system uses to validate file integrity and to optimize an update for the app.

App signature
App package’s digital signature file (AppxSignature.p7x)
The app package signature ensures that the package and contents haven't been modified after 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.

Packaging app:

When you create an app using Visual Studio, it packages your app, it automatically adds the app block map and signature files to the package. But you can also use the standalone MakeAppx and SignTool utilities if you want to manually package your app.

The steps that are involved in Package installation:

image

The Windows Store app deployment process occurs in multiple phases.

1) In the first phase, Windows acquires and validates the app manifest, app block map, and app signature. It checks the OS version and dependencies, sees if you have sufficient disk space, and also whether this app is already installed.

2) In the second phase Windows checks the app package’s deployment criteria to ensure that the app deployment will be successful.

3) Windows stages the package’s contents on the disk in the %ProgramFiles%\WindowsApps directory in a new directory named after the package identity:

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

4) Windows registers the package into the user's account. During this phase, the extensions that are declared in the manifest are registered with the operating system.

The Future:

With this release of Visual Studio 2013, we have set out to accomplish three major goals:

1) Reach customers across phones, tablets, and PCs;

2) Deliver innovation that supports developer investments;

3) Make cross-platform technology easier and more capable.

image

Develop once for all Windows devices using a unified Windows runtime and VS tools that allow you to both support experiences unique to a device in XAML, HTML, and DirectX, and share the code that supports those experiences across all devices using C++, C#, or JavaScript. When your work is finished you can you can produce the app packages that you will submit to the Windows Store and Windows Phone Store with a single action to get your app out to customers on any Windows device. You may also just sign it and deploy this through SCCM.

More links:

Package manifest schema reference
http://msdn.microsoft.com/en-us/library/windows/apps/br211473.aspx

Capabilities of an App:
http://msdn.microsoft.com/en-us/library/windows/apps/br211422.aspx

Create an app package
http://msdn.microsoft.com/en-us/library/windows/apps/hh975357.aspx

App packager (MakeAppx.exe)
http://msdn.microsoft.com/en-us/library/windows/apps/hh446767.aspx

SignTool
http://msdn.microsoft.com/en-us/library/windows/apps/ff551778.aspx

How to create an app package signing certificate
http://msdn.microsoft.com/en-us/library/windows/apps/jj835832.aspx

Ashfana Begum
Support Engineer
Microsoft Performance Team

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great blog posting - thanks! I'm a little surprised you didn't touch on touch-centric/device reasons for modern apps, but the other points you make are very worthy. If anything, I'm surprised Microsoft hasn't done a better job of articulating them over the last few years. Both users (customers) and devs should be highly motivated to move to modern apps for these key reasons.

    p.s. It would be ideal to get an editor to do a pass of such postings. Your points would be even more clear and readable.

  • Thanks for bringing up the modern apps topic in the Core Team blog. But given the blog name, I'd love to see a deeper technical coverage. Can you elaborate on the special integrity level used for modern apps in the future blog posts?

    The last time I checked the official documentation was mum. If it's already covered elsewhere, please point in the right direction.