From a user experience standpoint: sideloading is just "install this app". Click a link on a website to an APK for Android or APPX for Windows and watch it install. It doesn't get much easier than that. Fewer hurdles and security concerns than installing some random EXE that may be a wrapper for an MSI and needs Administrator rights to your machine for who knows what reason. The install experience for an APPX link is really nice in Windows these days. It's a great user experience.
From a developer standpoint: those "hops" have been your job for decades. Complaining about them says more about whether or not you are good at your job than the platform itself is suitable to applications.
Windows has always encouraged executable signing, and downloading unsigned EXEs from random websites has always been a bad idea. (The SmartScreen warnings for them these days have become appropriately diresome.) Other platforms have signing requirements, too.
Containers have always existed: ZIP, CAB, MSI, etc. If I was forced to write a container by hand-formed scripts, the APPX format is much easier than MSI or most other installer packages for classic Windows desktop: it's a zip file with a pretty easy to read XML manifest.
(With the Desktop Bridge, no application developers have an excuse to use an EXE or MSI installer anymore if they are only supporting Windows 10. If you can build an EXE or MSI, you can build an APPX. Build an APPX.)
There's no special voodoo API calls needed to sideload an app on Windows. Users just double-click an APPX package and magic happens [since the Anniversary Update in November of last year], they get a simple installer dialog. (You can use PowerShell to automate installing APPX packages, but you don't have to. It's an advantage to power users, not voodoo to pass to normal users.)
As for "reproducible"? APPX installs are way more reproducible than EXE/MSI installs. It's a pretty slick system if you bother to look under the hood. It's also rather well documented in that case that you do.
I can't assuage any conspiracy theories about marketing greed, but looking at sideloading from a technical perspective, it certainly isn't "a lot of hops" and "nobody does this" is a matter of perspective; I've got several packages in development that currently are outside of the Windows Store.
The given problem is not in the UX standpoint, it's a developers' problem.
As a developer of WinAPI app, I can just click on .EXE file. I can use CreateProcess to run it. I can use command shell to run it, right? And so on. I'm free.
The UWP is a different story: as a developer, I can do exactly nothing. I cannot run .EXE. I cannot run .APPX. I cannot run from command shell. I cannot distribute .EXE. I cannot distribute .APPX.
Instead, as a developer of an UWP app, I have to use exclusively Visual Studio in order to run my app. That's all. I cannot launch my just compiled app from command line. I cannot launch automated UI test. I cannot distribute the app. I cannot use XCopy. Bummer, nothing. I'm a monkey in a dystopian walled garden.
Why would I invest in such a platform? Why should I play bureaucracy games with certificates on my own machine? Why, as a developer, I have no access to "Launch from Layout" API, but Visual Studio has? Doesn't anyone think it's not competitive, to say the least?
The list goes on and on. But yes, from a MBA or an occasional lurker standpoint the skies are blue. Really, what could go wrong.
You can distribute .APPX. You can't distribute an unsigned .APPX and guarantee users can use it, but you haven't been able to do that with .EXE in years either.
> I cannot run .APPX.
Double clicking an .APPX installs it.
> I cannot run .EXE.
You can include Win32 .EXEs in .APPX packages now. There's a bunch of tools to support just that scenario called the "Desktop Bridge".
Any app that supports protocol activation (URIs like xbox:// or my-custom-app://cool-action) can be called with PowerShell (`Start-Process xbox://`). Most apps don't publish activation URLs, but some common ones are discoverable.
The Desktop Bridge has an API to launch an .EXE from UWP, either as a background task or a foreground task. There are also APIs to transfer data between the .EXE and UWP apps.
> I have to use exclusively Visual Studio in order to run my app.
You don't have to. It's a lot easier, but it's not the only way. APPX isn't that special, it's a zip file with an XML file and your binaries and whatever else, and any IDE could put one together if it desired. I wouldn't want to hand-build .APPX packages, but that's an option if you really desire it.
> I cannot launch automated UI test.
There are automation drivers for Appium and Selenium for UWP.
> Why should I play bureaucracy games with certificates on my own machine?
You don't, Windows Developer Mode does all the security work for you for your own development/testing needs.
IF you want to let others install your app, you need a security certificate. This has been the case with .EXE and .MSIs for decades, this is not new security.
Launch from Layout is an installation method that allows you to take loose files (an unpacked appx zip) and tell the OS 'treat this as an installed app'. You can do this with a couple WinRT APIs, Device Portal, or WinAppDeployCmd which comes with the SDK.
I own dev mode for Windows 10, and can confirm that these issues have been always solved and recently received more improvements, although the documentation may be lacking. Windows has always supported third party stores and the ability to pass around an appx.
Any hints or sample for Launch from Layout? Yes, I read the docs. This question haunts me for 4 years and I still have no answer. Please please please.
Here is a sample scenario that blocks me from doing certain development actions:
--- Steps to Reproduce ---
1. Launch VS 2017
2. Create new UWP blank app
3. Build it
4. Go to project's bin\Debug folder in File Explorer.
5. Find app's .EXE file and double-click it
--- Actual Results ---
.EXE file cannot be launched. Error: "This application can only run in the context of an app container."
--- Expected Results ---
.EXE file is launched. Main app window appears and it works as usual
>Double clicking an .APPX installs it.
Just checked that. Nope, this is what I get for my freshly compiled app when I click on corresponding .APPX file: "[Window Title] How do you want to open this file? [Content] Look for an app in the Store [OK]"
Any solution to this? These files should be consumable at the OS level.
From a developer standpoint: those "hops" have been your job for decades. Complaining about them says more about whether or not you are good at your job than the platform itself is suitable to applications.
Windows has always encouraged executable signing, and downloading unsigned EXEs from random websites has always been a bad idea. (The SmartScreen warnings for them these days have become appropriately diresome.) Other platforms have signing requirements, too.
Containers have always existed: ZIP, CAB, MSI, etc. If I was forced to write a container by hand-formed scripts, the APPX format is much easier than MSI or most other installer packages for classic Windows desktop: it's a zip file with a pretty easy to read XML manifest.
(With the Desktop Bridge, no application developers have an excuse to use an EXE or MSI installer anymore if they are only supporting Windows 10. If you can build an EXE or MSI, you can build an APPX. Build an APPX.)
There's no special voodoo API calls needed to sideload an app on Windows. Users just double-click an APPX package and magic happens [since the Anniversary Update in November of last year], they get a simple installer dialog. (You can use PowerShell to automate installing APPX packages, but you don't have to. It's an advantage to power users, not voodoo to pass to normal users.)
As for "reproducible"? APPX installs are way more reproducible than EXE/MSI installs. It's a pretty slick system if you bother to look under the hood. It's also rather well documented in that case that you do.
I can't assuage any conspiracy theories about marketing greed, but looking at sideloading from a technical perspective, it certainly isn't "a lot of hops" and "nobody does this" is a matter of perspective; I've got several packages in development that currently are outside of the Windows Store.