One of the key benefits of building a UWP app are the savings users see when downloading updates. With Windows 10, updating UWP apps is optimized to ensure that only the minimal, required, changed bits of the app are downloaded – netting Windows 10 users tons of savings!
At a high level, during package creation, a piece of metadata is created and stored in the .appx or .appxbundle package which allows parts of the package to be uniquely identified by Windows. Later on, during update, Windows can use this metadata file to compare the old package to the new package and determine the things that need to be downloaded to the device.
But wait, there’s more!
Given this metadata allows parts of the package to be uniquely identified, this means the differential update machinery fully functions from any version of a package to any other version of a package (assuming source package has a lower version than target package).
Long gone are the days of patch files that are crafted specifically from version x to version y of a package. With UWP app differential updates, you simply build the package and Windows takes care of the rest!
Interested in learning more? Read on!
It all starts at the AppxBlockMap.xml file (the aforementioned metadata). The AppxBlockMap.xml file is an XML document that contains a two dimensional list of information about files in the package. The first dimension lays out high level details on the file (e.g. name and size) and the second dimension provides SHA2-256 hash representations of each 64KB slice of that file (aka the “block”).
Here’s a sample of the AppxBlockMap.xml
<!--?xml version="1.0" encoding="UTF-8"?--> <blockmap hashmethod="http://www.w3.org/2001/04/xmlenc#sha256" xmlns="http://schemas.microsoft.com/appx/2010/blockmap"> <file lfhsize="66" size="101188" name="asset1.jpg"> <block hash="2bidNE0JyaO+FjaTpRe0g8HzUCblUf/cfBcTXiZR74c="/> <block hash="+jeFwKrGk5gw9wSICWsWRtEQXwcLC7af4EWS7DgrAkY="/> </file> <file lfhsize="61" size="108823" name="asset2.jpg"> <block hash="u0+5S0GOzwyAfYx54tKycZyHRBYm2ybvq27dkIKqDsQ="/> <block hash="F9h0FRMetL6BNCszAYB0bgyx2KWN+dO1bls4Q9m267c="/> </file> ... </blockmap>
Looking at the first file (asset1.jpg) we’ll see that the file has two block hashes, the first hash represents the first 64KB block of the file and the second hash represents the remaining 35KB – given the file is 101188 bytes.
During an update, if the second block of that file was modified, the hash would also be updated to reflect this fact. The download component understands this and will only pull down the second block and reuse the first unchanged block from the old package.
Up leveling this even further, if an entire file hasn’t changed (which is determined by the full set of blocks not changing) then that file can be reused from the existing package – resulting in tremendous savings for Windows 10 users, especially for larger UWP apps!
Want to get this working with your UWP apps? There are a couple of tactics that you can employ to take advantage of this delta update technology.
- Keep files in the package small – doing this will ensure that if a change is needed that would impact the full file, the update would still be small.
- Modifications to files should be additive if possible – additive changes will ensure that end-user devices only download those changed blocks
- Modifications to files should be contained to 64KB blocks if possible – if your app does have large files and requires changes to the middle of a file, containing changes to a set of blocks will go a long way
With the amount of updates that happen so regularly, we’re happy that we’ve enabled UWP app developers to build an experience that keeps users up to date with the latest and greatest without full app download every single time.
Any questions? leave them in the comments!
Jason Salameh, Senior Program Manager – Windows Developer Platform