Automated app updates with .appinstaller file

This blog covers updates for UWP apps that are not distributed through the Windows Store. This is a great solution for enterprises that need to install their apps from internal network locations like http or unc paths.

Let’s say you’re a developer who wants to build a Windows 10 app, called MyHRApp, and you’d like to share it on the internal company website.

Before build 16291 Windows 10 app updates outside the store were very difficult, because they required both user action and you, the developer, had to handle app update logistics or IT Pros had to write complex scripts to do update logisitics. You had to manage system resources; manage app workflow during an update; handle app update logistics through more than 1 app version; handle behavior when updates are in a different location, and a lot more.

Introducing the .appinstaller file

To help streamline the update process, starting in Windows 10 Fall Creators Update (insider build 16291 or later), we introduced the .appinstaller file. This file contains a standardized description of the components of the app, the location of potential updates, and specifies an update policy as shown in the example below:

The .appinstaller file contains sections for the main bundle as well as optional packages, dependencies, and update settings. The Uri in each section of the .appinstaller file is the location of the updates for that package. Notice that packages in the same .appinstaller file can have different versions. This is because versioning of each package is independent and is based on the number of updates that package had.

During deployment, the App Installer file is validated against the app packages referenced in the Uri element. So the Name, Publisher and Version should match the Package/Identity element in the app package manifest.

Note: The .appinstaller file is consumable through App Installer app and Powershell. Currently the App Installer app in Windows 10 Fall Creators Update only supports .appInstaller files that are located on a webserver. PowerShell (or the native PackageManager API) supports both http and unc locations doesn’t have these restrictions.

New workflow with .appinstaller

With the new workflow introduced in Build 16291 and later, when developing your MyHRApp you would also create a MyHRApp.appinstaller file and you’d upload it to the same webserver as the app.

Along with the app MyHRApp, the user's device downloads the MyHRApp.appinstaller file and uses it to check for updates. If an update is found, it gets downloaded in the background, without interfering with the app launch. The update gets applied by the system and the next time the user launches MyHRApp - the update is applied to the app. Then, the system informs you, the developer, of the updates so you can surface the information to the user as appropriate. For details on update status see this blog.

Note: When MyHRApp v2 update gets downloaded, the updated MyHRApp.appinstaller v2 file gets downloaded along with it.

Note: If you choose to change MyHRApp v2's location from webserver1 to webserver2, you only update MyHRApp.appinstaller in webserver1 to point to the new location of MyHRApp's v2 in webserver2. In webserver2 you would add MyHRApp.appxbundle's v2 along with a new MyHRApp.appinstaller for v2. In this case, when the user's device checks for an update in webserver1, it finds the pointer to webserver2 and downloads the v2 of MyHRApp along with the latest appinstaller file from webserver2.

With the .appinstaller file, your app is kept updated through the following process:

In summary, the .appinstaller file removes the need for the developer to handle update intricacies in their app, and allows apps to update without disturbing the user. This adds up to an easier app deployment lifecycle, and a better app experience for users.

We are very interested in hearing your feedback. Please post your comments and questions below.

Thanks,

Nona Sirakova, Program Manager – Windows Developer Platform