First look at the future of application deployment on Windows 8: AppX

In an app-centric world, Windows 8 will be adopting the trend full-on with a Swiss Army Knife of new tricks. One of which is a new universal application deployment system called AppX which I’ve been recently been able to take a first look at.

Although Windows 8 will disrupt many components of applications, including how they are written (Immersive) and distributed (application store), AppX concerns only the deployment aspect of applications. More precisely, it’s a tight specification that describes how applications are packaged and installed.

Clearly inspired by XAPs for Silverlight, the critical aspect of AppX packages is an XML manifest file appropriately named the “AppXManifest.xml”. In this file, developers will have to specify many compulsory and optional attributes of their application, in fact, much more than what’s required from Windows Phone developers.

From a specifications document it’s revealed attributes include but are not limited to:

  • Application identity – name, publisher, version
  • Application architecture – processor architecture, type of application, framework required, operating system version
  • Dependencies – name, publisher and minimum version of other required applications
  • Capabilities – networking, file system and profile capabilities requested by the application
  • OS extensions – associated filetypes and protocols, AutoPlay, “Charms”, notifications, splash screen
  • Tile customization – logo, name, description and colors for the tile-based user interface

The extensive list of properties signifies the comprehensive scope of this system to be the ideal deployment strategy for “applications”, in all essence of the word. In fact, the AppX format is universal enough so it appears to work for everything from native Win32 applications to framework-based applications (WPF, Silverlight) and even *gasp* web applications. Games are also supported.

Not only will this help developers improve the application experience, but also for end-users. It’s undeniable AppX will tie into the Windows 8 application store to deliver a more consistent experience to download and install apps, including the ability to review the security-based capabilities the application will request.

As both a developer and end-user, this is exactly what Windows needs to streamline the application experience for the platform whose current laissez-faire strategy is no longer suitable for the times.

85 insightful thoughts

  1. Interesting. Thanks.

    Strange to see an ‘exe’ as the main entry point. I would have thought it would have been glcnd.html (with a silent 5).

  2. How will the updating process work? Does the system need to download the whole package? That could be a drawback, maybe?

      1. This is really interesting. I’m wondering what that PDF extension could mean. That may be the reason why Microsoft is working on an build-in PDF reader.

  3. the appX file provided looks as similar to a clickonce manifest as it does to a .XAP file (and is just as close to a .XAP file as it is to a WiX file, which is a roundabout way of saying not very much). I think the comparison to silverlight is drawing a bit of a long bow.

    1. I drew the comparison to XAP because the ClickOnce manifest doesn’t include capabilities or OS extensions like notifications like Silverlight on Windows Phone does.

  4. Cool! They are reinventing ClickOnce! I’m sure this time it will catch on. Come on, what’s the point of using eXtensible Markup Language if it’s going to be redone instead of extended?

  5. This seems a bit like a reincarnation of Mesh-Enabled Web Applications from the now-defunct Live Framework. The original vision included the ability to deploy EXEs, offline HTML/Javascript apps, Silverlight, and more, with an app store and the ability to buy once and deploy to all devices in your mesh, including cross-platform.

  6. Is it just me or there’s really nothing NEW and exciting so far on the desktop front? Windows 8 seems all about tablets and changing user interfaces AGAIN.

    1. Speak for yourself. I for one am pretty excited to see some of these changes in Win 8, which I’ve thought they should have made years ago.

  7. Ultimately though it’s all about the user experience when installing/updating applications. Feature set and xml structure doesn’t matter at all if the user experience isn’t good.

  8. I love the idea of packaging system for desktop applications that handles install, uninstall, and updating in a standardized system-wide way. I am concerned about Microsoft trying to route everything through a single app store though — that’d be totally unworkable for vertical market applications.

    1. This kind of functionality exists for at least 20 years on other operating systems. It’s really only new on Windows and Macintosh.

  9. > Clearly inspired by XAPs for Silverlight, the critical aspect of AppX packages is an XML manifest file

    They are clearly inspired by OS X app packages, which predate Silverlight.

  10. The AppX model is the merging of current Silverlight OOB and FTI scenarios along with .NET ClickOnce and what MeshApps were once supposed to be. Just governed and integrated to Windows via Windows Update and a Windows App Catalog.

    Things promise to be quite interesting for sure.

  11. Excellent! I hope that AppX will be the unique format to distribute applications for Windows.

    Actually this can improve security, disabling the execution of “exe-files” and preventing them to modify system-settings from not-safe locations.

  12. This sucks… When you said AppX, I was logically thinking that was the next version of AppV baked into the OS…. Sadly it’s not!

  13. Wonder if AppX is supported by Microsoft’ WiX project (wix.sf.net) – from the above, it looks like WiX is at the very least the predecessor to AppX if not the actual backend for it.

  14. Seems like Microsoft may finally be wising up to the advantages of standardizing package installation, just like the Linux world realized 15 years ago. Pick a format (doesn’t matter what) and a mechanism for specifying name, version, dependencies, etc.. Put together a ‘repository’ system (so far represented here by MS’s app store) and let developers do the rest. Make the package for your program and the system knows how to install it, uninstall it, and update it. Windows has been in desperate need of something like that for years and MSI was no solution, given all of its problems. This seems a lot closer to a mid-90s Linux package format: just the basics, plus internet updating.

Leave a Reply