EfficientEther has published new open-access research that answers a question application delivery teams face on almost every Azure Virtual Desktop project: should an application ship as native MSIX, or through App Attach? The paper is available now on Zenodo under a Creative Commons CC BY 4.0 licence, so anyone can read it, download the full PDF, and cite it. Written by Ryan Mangan of EfficientEther Ltd and published as a preprint (v1, 17 June 2026), it carries the DOI 10.5281/zenodo.20556143.
Its full title sets the scope: "Native MSIX or App Attach for Azure Virtual Desktop? A Decision-Oriented Comparison of Package Delivery, Assignment, Image Management, and Operational Risk". The core move is to reframe a debate that usually gets stuck on raw performance. Rather than asking which model launches an application a few milliseconds faster, the research treats the choice as a capability and operational-cost decision, which is the question that actually shapes how a delivery team runs its estate.
What the paper examines
To compare the two models fairly, the study evaluates each one across the ways it is genuinely operated in production rather than in a single idealised test.
For native MSIX, it works through four deployment models:
- Current-user install, where a package is installed in the context of the signed-in user.
- Provisioned all-user availability, where a package is provisioned so it is available to every user on the machine.
- Image-baked baseline, where the package is built into the base image.
- Desired-state loops, where a configuration loop keeps the installed set aligned to an intended state.
For App Attach, it examines the image-based delivery lifecycle in both supported image formats, VHDX and CimFS, following each image-attach lifecycle from staging through to the point the application is available to a user.
Across all of these, the subtitle names the four dimensions the comparison holds in view: package delivery, assignment, image management, and operational risk. Each dimension surfaces a different kind of cost. Package delivery is about how a package actually reaches the machine and how repeatable that is. Assignment is about how an application is targeted to the right users or hosts, and how dynamic that targeting can be. Image management is about whether the application lives inside the base image or outside it, and what that means for how often the image has to be rebuilt. Operational risk is the quiet one: the failure modes, the launch-time sensitivities, and the moving parts a team has to keep healthy after go-live. Holding those four constant is what turns an opinion into a decision framework, because it forces each model to answer the same operational questions rather than being judged on whichever strength its advocates prefer to talk about.
What the paper found
The headline finding is deliberately not "one model wins". It is a routing decision. Native MSIX remains the lower-complexity choice when standard installation and provisioning already meet the requirement. App Attach is justified when the requirement becomes image externalisation and dynamic AVD assignment, the point at which you genuinely need the application to live outside the image and be attached to session hosts on demand. Put simply, the research recommends reaching for the simpler model until the problem itself calls for the more capable one.
Read against those four dimensions, the pattern is consistent. Native MSIX carries less operational risk and less image-management overhead for the common case, which is why it stays the default. App Attach earns its place when image externalisation and dynamic assignment are the actual requirement, because that is precisely where its added moving parts start paying for themselves rather than simply adding cost.
On timing, the paper is careful, and so are we. In bounded local testing, App Attach delivered lower repeated lifecycle medians than per-user native installation, while already-installed packages showed similar launch times. Ryan Mangan states plainly that this is a descriptive result from an underpowered test design, not a general benchmark. We are repeating that caveat on purpose: it would be wrong to read the timing figures as proof that App Attach is faster in your environment. The value of the paper is the decision framework, not a performance league table.
The research routes a delivery decision between native MSIX and App Attach on capability and operational cost, not on raw speed.
Why we publish research openly
This paper is part of an ongoing internal research and development programme at EfficientEther. We run it because we would rather ground our product direction and our guidance in tested evidence than in vendor folklore and repeated assumptions. When a finding is non-sensitive and useful to the wider community, we publish it in the open.
Open, in this case, means genuinely open. The paper is released under CC BY 4.0, and the Zenodo record includes a public evidence pack alongside the PDF so that others can inspect the methodology, question the design, and reproduce the thinking rather than take the conclusions on trust. We would rather the work be challenged than quietly accepted. If you disagree with the design, the framing, or the conclusions, we want to hear it, and the licence exists precisely so you can build on the work and cite it.
It is not the first paper from this programme. An earlier study looked at where the Package Support Framework adds MSIX and App Attach risk, also published openly under the same licence. More will follow, because the point of the programme is a steady body of evidence, not a single headline.
What it means for practitioners running AVD and Windows 365 estates
For the admins and delivery teams who run Azure Virtual Desktop and Windows 365 estates, the practical takeaway is a cleaner default. Do not adopt App Attach because it is newer or because a timing chart looks favourable. Adopt native MSIX where installation and provisioning already do the job, and move to App Attach when you have a real requirement for image externalisation and dynamic assignment. That keeps operational complexity proportional to the problem you are actually solving.
It also helps to write the requirement down before the tooling debate starts. If the estate genuinely needs applications to live outside the image so they can be updated and attached without rebuilding session hosts, that is an image-externalisation requirement and App Attach is on the table. If it does not, native MSIX installation and provisioning will usually be the calmer operation to run day to day.
The same discipline shows up earlier in the lifecycle, at packaging. A capture-first path to MSIX for complex Windows applications makes the point that the delivery route should follow the discovered application footprint rather than being assumed up front. The research in this new paper extends that idea to the AVD delivery decision: understand the requirement first, then pick the model that matches it, whether that is native MSIX or an App Attach image.
Where EtherApps Forge fits
EtherApps Forge is a Win32 application that runs in the customer's own environment rather than as a hosted service, and it produces both native MSIX packages and app-attach-ready outputs. That means the decision framework in the paper maps directly onto the routes the product already supports: once discovery has established what the application needs, the same tool can produce the native MSIX package or the App Attach image the requirement points to.
Its agentic application packaging workflow is designed to take the guesswork out of that step, recommending a route from the real application footprint rather than a default habit. You can put it through its paces with a free 7-day trial, which is a genuine trial of the product rather than a free licence.
Explore MSIX packaging and deployment to see how evidence-led route selection turns the paper's decision framework into a repeatable packaging and delivery operation.