For content update guidance specific to the original MSIXVC format, see Content update best practices.
How MSIXVC2 content updates work
Content-based segmentation
MSIXVC2 splits file data into variable-size segments based on the actual content rather than fixed block boundaries. Each segment is identified by a hash of its contents. This approach means:- Moving a file between chunks doesn’t trigger a re-download. The file’s content hashes stay the same no matter which chunk it belongs to.
- Reordering files within a chunk doesn’t trigger a re-download. Segment boundaries are determined by content, not position.
- Reordering chunks doesn’t trigger a re-download. Chunk layout is a logical concept that doesn’t affect the physical segmentation of data.
- Inserting or removing data doesn’t cascade. Unlike fixed-block systems, a small insertion doesn’t shift all subsequent blocks and force redownloads of unchanged content.
Deduplication on upload
Every segment is hashed before upload. The upload process queries the CDN to determine which segments already exist from prior versions. Only new or changed segments are uploaded and delivered to players. This deduplication happens automatically - no developer action is required.Per-segment encryption and compression
Each segment is independently compressed and encrypted. This ensures that updating one segment doesn’t affect others.What changes from MSIXVC
The following alignment and layout constraints from MSIXVC content updates don’t apply to MSIXVC2:Update size comparison
The following data compares content update sizes between MSIXVC and MSIXVC2 for the same title builds. No changes were made to the games - same assets, same builds, different packaging format.
Game D shows a smaller improvement because the title was already hand-optimized for MSIXVC content updates (CUv3). Most titles that haven’t done this optimization work will see larger reductions. With MSIXVC2, this optimization work is no longer necessary.
Package overhead reduction
Every MSIXVC package includes a fixed minimum hash tree whose size scales with the total game size. This overhead is always fully downloaded with every update. For large titles, this overhead is significant:
MSIXVC2 overhead can also be partially downloaded, meaning players only receive the portions of metadata that are relevant to their update.
Base game size improvements
Content-based segmentation and built-in compression also reduce base game download sizes:
Titles with uncompressed content or significant duplicate data across chunks see the largest base size reductions. Titles that already compress all content and have no duplication (like Game D) see smaller but still meaningful improvements.
Evaluating MSIXVC2 for your title
To measure the content update improvement for your own title:- Take two sequential builds of your game (for example, a release build and the subsequent patch).
- Package both builds by using
makepkg.
- Compare the resulting update size against an equivalent MSIXVC (v1) build.
- Use the comparison results to plan your migration to MSIXVC2.
Upload MSIXVC2 packages to a separate branch in Partner Center (for example,
msixvc2). Don’t mix MSIXVC2 and MSIXVC packages on the same branch - reverting a branch from MSIXVC2 back to MSIXVC requires a full reupload and forces a full redownload for players on that branch. See Package branch best practices for details.