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:

Sample AppInstaller file

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.

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:

Developer/User work flow auto-updates

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


Comments (17)

  1. Please make the Store -> Create App Packages -> Upload to Store (No) => Generate .appinstaller and index.html file on Output Directory.

    See
    https://twitter.com/tonyvca/status/921693502722990082

  2. Where can I download a sample App Installer File?

      1. Can you help on this? I created the file, but it does not work. See http://www.tonysistemas.com.br/sistema/uwp/

  3. This is looking good. Finally. I am very happy with this.

  4. Is there a way to also have na option to Opt-In to require que App to only start after it is Updated. Else, wait to update then start.

  5. Marvin says:

    Do I need to check if an update is available in my app or is this done automatically?

    1. John.V says:

      Updates will happen automatically in the background and should update at next launch after download. There are APIs available to offer an improved user experience letting a user know an update is available.

      1. Marvin says:

        I have not been able to get the updater working yet. The installer is great, though.

        To test this I have uploaded a .appx file (properly signed) to S3 and created an .appinstaller file.
        Installing with the .appinstaller file works. I then uploaded an other appx (with version incremented) and updated the .appinstaller file.
        And nothing happens. I launched the app 100 times, restarted the PC and waited.
        I tried catching the update request with fiddler, but no success.
        Any ideas?

  6. jhealy says:

    If the package is initially dropped via SCCM, could app update then be used to drop in incremental updates and avoid a full redeploy?

    1. John.V says:

      The feature is not designed to mix and match with SCCM. SCCM has its own updating system and download technology.

  7. Ciufolo says:

    how do i create the .appinstaller file?

  8. Tony Henrique says:

    Does Visual Studio generate automatically this App Installer file?

    1. Nona S says:

      No, you have to generate it manually.

  9. Tony Henrique says:

    Very nice! This is what I expected. Very practical, just like ClickOnce was.

Skip to main content