When it comes to installing Windows applications, there are definitely some improvements that could be made from a user perspective.
Those are exactly the kinds of improvements that MSiX aims to address. When a user installs an application, and then decides that they no longer want the application, it can be messy to get it removed, particularly if it is a third-party application that has its own rules. The same goes for automatic updates to the app.
The first thing that MSiX tries to address is what is left behind by these applications once they are uninstalled. Often, users have to restart their device – or worse – actually go hunting for components to make sure that they are removed completely. This is really tough for people who like to try out various applications that are for a single purpose to figure out which one fits their needs best. One such example is a time management or task completion app.
Some of the goals of MSiX include:
- Apps are always up-to-date
- Data is protected
- Assets may be reused
- Security and reliability is much improved
- App deployment is simplified
There are two ways that these goals are aimed; the first is towards app developers and the second is for the users themselves. App developers want all of this to happen with all of their applications, but it is not possible unless you build that functionality right into the app, and even then, you don’t get the same benefits that you can get when using the functions of MSIX.
As for the users themselves, they want their data to be protected, they want their applications to always be up-to-date and most of all, they want their apps to simply deploy fast and be ready to go.
For app developers, app packaging like MSiX is absolutely vital to all Enterprise IT, because it is designed for the
XP-era lifecycle that we are currently in and because the packaging is done by IT pros that are looking at the big picture instead of from the limited perspective of an app developer. This is vital. Packaging today is either MSI/EXE or some App-V, but repackaging applies to both internal LOB and third-party applications.
The entire goal of MSiX and the entire Microsoft team (as well as other open-source contributors) working on the packaging is to avoid what they are calling 'packaging paralysis.' Packaging paralysis happens when a developer is simply unable to keep up with much needed updates because of how much work goes into packaging. That means that their apps may have one, two or half a dozen app updates that haven’t been rolled out because they are still working on the packaging for a past update. This obviously has very serious security risks, makes the user experience bad and has a lot of other downsides as well.
That’s why the release of MSiX is so exciting.
If you want to try out the future of repacking, I went a head and made a sample app for deployment.
If you see me giggling in the corner, it may be due to the choice of sample app 😉 (sorry, but the msi file was already in my download folder)
Enjoy Orca MSI Editor now wrapped as MSiX 😉