UWP apps > “Normal” desktop apps
But only without the Microsoft AppStore. Why? How?
Android and IoS are better than Windows at dealing with applications — it’s straightforward to install or delete an app, and safer too. Traditional Desktop applications need to be replaced with a modern alternative. With Universal Apps Windows reigned in bullshit that has been going on, and after November 2017 UWP apps finally have enough APIs to address SeriousBusiness™ applications. However Windows Store policies towards background execution are too restrictive, and we look at how to get round that. If you are not interested in overview, scroll down to “Assuming Direct ” section.
Traditional Desktop Apps must die
In the old days… I mean, Today each ‘normal’ Windows app needs it’s own installer, it’s own updater, it’s own uninstaller and often admin rights to install. It will then put files wherever it feels like. And then it will stick crap in the registry and never delete any of it. Currently I have programs that decided to nest in:
\%username%\AppData\Local
Program Files (x86)
ProgramData
C:\User has basically no control over how well the app uninstalls, how often it runs, how much memory or battery it consumes. Case in point — Slack:
This Swine-house of crap is also a burden to maintain, I have never in my life seen an uninstaller that does not leave bits of the app lying around the system, which then cause problems when you update or re-install.
Universal Windows Apps come with a single packaging system that cleanly installs and removes the app. The UI performance, touch controls and font rendering have all been substantially improved. The OS also puts the user in control of the app behaviour.
Despite these advantages hardly anyone uses the platform and Microsoft Store is mostly devoid of life. Why?
Microsoft shot Store in the foot, Twice
Of the few decent apps that are on Windows Store, the majority are converted desktop apps. Learning a new platform and making an app is a lot of work, and ‘Lightweights’ such as social networks are well served by webapps already.
Desktop apps shine when it comes to SeriousBusiness™ that can’t be done on tablets and webapps — work that takes a lot of compute power, unlimited internet connection, loads of screen space, terabytes of disk space, must run for hours on end, even 24/7. The problem is that Store-based Universal Windows App can’t support SeriousBusiness™.
- Until recently the API set available to UWP developers was far too restricted, many libraries were incompatible, there was no way to accept SSL/TLS connections! With the arrival of .Net Standard 2.0 on November 2017, this is mostly a solved issue, only 2.5 years after release of Windows 10.
- Windows Store places many restrictions on the developer — things you are not allowed to do. Most of them are justifiable, but in their fight against battery-sucking pests that are background apps they went too far. As it stands, Windows 10 may decide to suspend your app whenever it’s minimised or is otherwise in the background to free up RAM or conserve battery. You can ask Windows to postpone it, but there is it no guarantee. There are background tasks, but they will get suspended too, even on a desktop machine! You as a developer and even as a user have no control over the process. And that’s idiotic.
Why suspending is such a big deal
There is an API to opt out of suspending entirely, but your app will be banned form the store. With this single decision, most apps that have a reason to exist on desktop can’t be brought to the store:
- Video Editing tools often take hours to process a video. Normally that does not stop you from using the computer for browsing / Word and other lightweight work. However if you use a UWP video editing tool and switch to a web browser, Windows will suspend the Video Editor. You would have to sit there for hours staring at the progress bar like an idiot, or use a different computer.
- 3D rendering tools like Blender3D can take days or weeks to render 3D movies.
- Torrent clients such as Torrex get interrupted during downloading and seeding.
- Bitcoin and other cryptocurrency clients — I wanted to build a cryptocurrency wallet for the store before realising that they need to constantly communicate with the network and a store based one would be rendered useless.
- Dropbox or OneDrive. The ones in the store can’t sync your files in real time.
- An Iot Dashboard app like my current Quickbird App
- Countless other applications that nobody has imagined yet
Taking back Control
You can remove constrains on your UWP application by adding following lines to the package manifest. This will make your application ineligible for store distribution.
<Package …> …
<Capabilities>
<rescap:Capability Name=”extendedExecutionUnconstrained”/>
</Capabilities>
</Package>This will allow your application to use extended execution session with
ExtendedExecutionForegroundReason.Unconstrained;Implementing this functionality will yield ‘normal’ desktop application behaviour — the app will be running until terminated by the user using the ‘X’ in the upper right corner. You can also use this method to create background tasks that are always on. See this guidance for more detail.
Distributing apps without Windows Store
Visual Studio will produce an Appxbundle that can be installed on any computer using the AppInstaller, avaliable from Windows Store. However the app must be signed with a valid certificate. Unsigned apps are not allowed at all, and In my opinion that’s a good decision — acquiring certificates is not difficult, and placing the developer name on the package at least establishes a minimal responsibility and security.
You need to buy a CodeSigning certificate, but there is no need to shell out for an EV version — I got a Comodo certificate from Leadertelecom.nl for less than £100. You might, however, need to have a registered company.
Visual Studio can be instructed d to sign the AppxBundle, but for some inexplicable reason it will not time stamp it.
Timestamping is essential — each certificate has an expiration date, typically a year or two. Without a timestamp, Certificates are validated against current date, so your application will become invalid after a year or so.
You can use SignTool, usually found with Windows 10 SDK in
C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe
There is loads of guidance, but the basic process is simple:
- Make Sure that Publisher Display Name in the Package.appxmanifest matches EXACTLY to the ‘Subject’ on the certificate. In my case both are ‘Heimdall LTD’.
- Build the app packages in Release mode. When asked “Are you building packages for the store” select “No”
- Use Powershell or Cmd and give the Signtool the right command. Signing the Appx takes about 40 seconds.
C:\Program Files (x86)\Windows Kits\10\bin\x64> .\signtool.exe sign /debug /fd sha256 /f “C:\DigitalCertificates\Heimdall_Code_Sign.pfx” /p “*password_here*”
/t http://timestamp.verisign.com/scripts/timstamp.dll C:\Releases\Quickbird_1.8.3.0\Quickbird_1.8.3.0_x86.appxbundle- Debug is makes the output more verbouse so you can see where you screwed up. Has no effect on final result
- /fd specifies hashing algorithm, it must match what was used ot create the Appx, and sha256 is default
- /f spesifies location of your signing certificate
- /t spesifies location of the timestamp server used by signtool. Without it, you will get another useless package without a timestamp
- Lastly location of the Appx
The Appx will get signed and will be ready to be distributed. When a user double-clicks it they will be greeted with a standard install screen. If they download the appx online, they might get the “do you want to open this file” dialog. A more expensive EV (extended Validation) certificate would turn that warning window green, but that’s about it. You can get the signed Appx on my github to test.
Now that you are distributing the app yourself, you could actually step outside the sandbox by calling native C++ code through P/Invoke or really do anything else a “normal” app is capable of. Be responsible, they do have your name!
Correct Output from SignTool
C:\Program Files (x86)\Windows Kits\10\bin\x64> .\signtool.exe sign /debug /fd sha256 /f “C:\DigitalCertificates\Heimdall_Code_Sign.pfx” /p “*password_here*”
/t http://timestamp.verisign.com/scripts/timstamp.dll C:\Releases\Quickbird_1.8.3.0\Quickbird_1.8.3.0_x86.appxbundleThe following certificates were considered:
Issued to: Heimdall LTD
Issued by: COMODO RSA Code Signing CA
Expires: Wed Oct 10 00:59:59 2018
SHA1 hash: ****************************************Issued to: COMODO RSA Certification Authority
Issued by: COMODO RSA Certification Authority
Expires: Tue Jan 19 00:59:59 2038
SHA1 hash: ****************************************Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Tue May 09 00:59:59 2028
SHA1 hash: ****************************************After EKU filter, 3 certs were left.
After expiry filter, 3 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
Issued to: Heimdall LTD
Issued by: COMODO RSA Code Signing CA
Expires: Wed Oct 10 00:59:59 2018
SHA1 hash: ****************************************The following additional certificates will be attached:
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Tue May 09 00:59:59 2028
SHA1 hash: ****************************************Done Adding Additional Store
Successfully signed: C:\Releases\Quickbird_1.8.3.0\Quickbird_1.8.3.0_x86.appxbundleNumber of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Rant Here
This idiotic ‘Background Suspend’ decision is my single biggest beef with the entire UWP system. No matter how you spin it is plain idiotic to the point of being offensive. This issue has been at the top of UserVoice for two years and is still not addressed. Android allows you to run apps in the background. Web apps can now run in the background. What’s the point of developing native applications for windows if you can’t use the power of the platform?
Microsoft provides API to compensate for some shortcoming, the is an API that allows limited network communication. That’s dumb — most developers don’t write their own networking at the socket level — they rely on libraries to do it. Even if you do, that API only makes sense for applications that receive few messages a minute at most, like a texting app or something.
Converted Desktop apps are allowed on the Microsoft Store and don’t have to deal with being suspended — are we to develop those instead?
Instead of restricting your developers, give users the power to see which apps drain battery life, provide them with proper tools to control what runs in the background. Put a hard on the number of background processes if you have to. Limit them in terms of CPU/Memory/Netwrok traffic / whatever.
