Discussion: Unifying app delivery methods: Store vs other

[benstevens48]

Discussion: Unifying app delivery methods: Store vs other

I don't know if this is in scope, but I hope so. This issue is to discuss how the Windows Dev Center and Store can be improved to offer functionality you could get by delivery your app by another means, and, conversely, how people delivering their app via other means could still make use of some of the features of the Store. Hopefully some of this disussion can result in features that are implemented in the Windows Dev Center, Microsoft Store and related SDKs.

To start the discussion, I'm copying in an issue which I originally posted to the WinUI repository for lack of a better place to post it (microsoft/microsoft-ui-xaml#2300). It suggests some possible solutions that Microsoft could implement in order for apps delivered via the Store to offer different versions, such as LTS and beta. Some of the suggestions are more widely applicable in terms of allowing the developer to distribute the same app both via the Store and outside the Store, when that app contains add-on purchases.

[benstevens48]

Enable users to download different versions of an app from the Store (especially LTS and beta)

The problem

It has become increasingly clear to me that I need to be able to offer some sort of ‘long term support’ version, or at least selected previous versions, of my app to users. This is because new releases sometimes contain bugs and occasionally feature changes that would disrupt some users’ workflow, and if they are using it as part of serious work then they need to be able to guard against that. It would also be nice to be able to offer a beta version of the app as a way of testing new features.

An important feature of my app is that is it free to download but offers a ‘Pro’ upgrade as an in-app purchase, which is how it makes money. This addon is managed by the Store. All versions of the app need to know whether or not the user has the addon and allow the user to purchase the addon.

Why this problem is currently impossible to solve

The Store currently has the concept of ‘package flights’, which correspond nicely with the ‘app versions’ that I’ve been talking about. However, the only way to make different users get different package flights is to add the email address of the user’s Microsoft account to a list associated with the package flight. This is OK for closed beta testing, but is not practical to do on a large scale, there are privacy issues with managing the email addresses, and it is limited to 10,000 users anyway. The gradual rollout feature is a very nice feature for picking up any major bugs, but obviously the users who get the updated buggy version are stuck with it, and this won't cater for users who don't like certain feature changes etc.

The other way you could think of solving the issue is distributing the app outside the Store. However, to do that you need to sign it, and in order to sign it you need an app signing certificate which is tied to a particular publisher Id. Now when you sign up for a Store developer account, you get assigned a random publisher Id (at least you do for a non-organisation account and I assume it’s the same for an organisation account – please correct me if I’m wrong). Obviously you can’t use this random Id as the publisher Id when purchasing a code signing certificate – you have to use your name or company name. So the signed app package has to have a different publisher Id. The app signed with this publisher Id is then not allowed to query for or purchase addons for the app signed with the publisher Id that the Store gave you. Now, it is possible to generate a self-signed certificate with the publisher Id that the Store gave you, but then you have to instruct the end-user to install your self-signed certificate, which is quite unprofessional and there are issues when the certificate expires. Also, there is the problem (which can be worked around via awkward package versioning) that the Store will automatically upgrade the app to the most recent version even if it was not installed via the Store (if the app has the same publisher and app Id).

Possible solutions

Here are a number of possible solutions, some of which also enable other scenarios. I really hope Microsoft can consider implementing at least one of them.

Solution 1

It turns out the Microsoft have already identified this is a serious issue which needs a solution, but they have also decided that they (along with selected partners) are the only ones who need it. This page - https://docs.microsoft.com/en-us/windows/uwp/monetize/send-requests-to-the-store - actually shows that there is a Store API for moving users between package flights and querying which package flight they are in, which would be one way to solve the version problem (users can choose to change versions from within the app). However, ‘This request is currently not available to most developer accounts. This request will fail unless your developer account is specially provisioned by Microsoft’. So the first solution is simply to allow this API for all developer accounts. (Although one thing that might need adding is an easy way for the user to reset themselves to the default package flight in case the app stops working).

Solution 2

This is probably my preferred solution. The user should be able to choose the package flight that they install on the Store page for the app. The developer would mark package flights as being available for the user to select, including a default (which it should be possible to give a name to). There should be a drop-down or similar on the Store page for the app with the default package flight auto-selected.

Optional extras to consider with this solution are as follows.

When the developer uploads an app package, they can specify a minimum compatible package version (which could be 0.0.0). This means that if the user changes flight that results in a downgrade from one package to another, no warning needs to be shown if the package is at least this version. Otherwise, downgrades should show a warning saying that the app may need to be reinstalled.

The app can query which package flight the user is currently in (this is almost essential). The app can list the available package flights. The app can prompt the user to change package flight. It might be that this requires an OS dialog or OAuth flow or something.

Nice to have: when the user right-clicks on the app tile, there is an option (maybe under more) to change the version of the app. Maybe when the user uninstalls the app, the system might ask whether they want to install another version (although this might be annoying) – I’m thinking of a buggy beta for example where the user might want to downgrade.

Solution 3

This is a less good version of solution 2. Instead of offering different package flights, just offer the option to install previous app packages. The developer can choose not to delete old app packages when uploading a new one (like now), and also mark old app packages as being available for install. The user can choose from a drop-down on the Store page to install an old version. Perhaps at the point that the developer removes the old version from the Store dev center, the user will be upgraded to the next highest one. To be honest, solution 2 is better.

Solution 4

This requires very little work from Microsoft. Allow the developer to download the signed app packages (along with any necessary dependencies) from the Store after certification. This should include app packages submitted to different package flights. The developer can then offer these for download on their own website as they wish.

App packages installed outside the Store should not automatically be updated by the Store.

Nice to have – a wizard that creates an app installer and offers the necessary files with the installer to download as a zip file. This is not essential but would be a nice addition.

Solution 5

In the Store, allow the developer to set a list of publisher/app Id pairs (or maybe just authenticate on publisher) associated with an addon (or perhaps the parent app itself), such that any app with a publisher and app Id in the list can query for and purchase the addon for a user. This would allow the developer to publish the app outside the Store with a different publisher Id but keep everything else the same and it would just work.

App packages installed outside the Store should not automatically be updated by the Store.

Solution 6

This generalises solution 5 and allows cross-platform scenarios (subject to terms and conditions of the other platform distribution methods). Allow querying the Store for addons the user has purchased. This is already possible except that it’s only possible to authenticate using a UWP API and is tied to the current publisher (I think). This could be expanded to some sort of OAuth scenario (like a standard 3rd-party login using a browser popup or similar, where the app asks for access to the list of addons the user has purchased for a given app and the user has to agree this - perhaps it could be possible to streamline this slightly using client or server secrets etc but I’m not sure…). Also, allow the user to purchase the addon via the browser. Effectively, this is asking to be able to use the Store as a way to securely purchase and manage addon licences without necessarily having installed the app from the Store.

That’s all I have for now – thanks for reading.

[mdtauk]

I think in the future all apps should be downloadable from the store, downloadable from the web, and downloadable via WinGet.

The Store should be open to all WinUI 3 apps, or packaged WPF, Winforms apps. These are the open sourced and preferred frameworks for app development. They should also all support the clean install/uninstall, and virtualised Windows and System32 folders, as well as Registry access.

The Store would be for most users;
Web MSIX Downloads for Enterprise and Pro users;
WinGet ideal for developers and those who are comfortable in the command line;

But they use a shared repository.

[TitleOS]

Enable users to download different versions of an app from the Store (especially LTS and beta)

The problem

This is possible using third party clients as the Store still stores (and delivers when requested) older packages. See https://github.com/TitleOS/StoreLib and https://github.com/TitleOS/StoreBot. Flighted packages can be filtered via a MSA ticket or XBL3.0 Xbox Live Token.

[mdtauk]

Enable users to download different versions of an app from the Store (especially LTS and beta)

The problem

This is possible using third party clients as the Store still stores (and delivers when requested) older packages. See https://github.com/TitleOS/StoreLib and https://github.com/TitleOS/StoreBot

One case in point for me, I have the Windows 10 version of Minecraft installed, but I can't run it alongside the beta channel.

There needs to be some kind of SXS (Side by side) mechanism for store and WinUI Desktop apps.

[benstevens48]

This is possible using third party clients as the Store still stores (and delivers when requested) older packages. See https://github.com/TitleOS/StoreLib and https://github.com/TitleOS/StoreBot. Flighted packages can be filtered via a MSA ticket or XBL3.0 Xbox Live Token.

Thanks for that info. But is that officially supported by Microsoft, or is it something that just happens to work for now?

This seems to enable what I called 'Solution 4' above. If this is already possible by doing some detective work, then I see no reason for Microsoft not to add a simple 'Download signed package' button to the Dev Center and make this officially supported. It would seem to require very little effort to enable this. Maybe also add an official API in case the developer wants to automate the process.

[TitleOS]

This is possible using third party clients as the Store still stores (and delivers when requested) older packages. See https://github.com/TitleOS/StoreLib and https://github.com/TitleOS/StoreBot. Flighted packages can be filtered via a MSA ticket or XBL3.0 Xbox Live Token.

Thanks for that info. But is that officially supported by Microsoft, or is it something that just happens to work for now?

This seems to enable what I called 'Solution 4' above. If this is already possible by doing some detective work, then I see no reason for Microsoft not to add a simple 'Download signed package' button to the Dev Center and make this officially supported. It would seem to require very little effort to enable this. Maybe also add an official API in case the developer wants to automate the process.

It's not officially supported by Microsoft but it's not considered an exploit or something to fix according to email communications with them, so it should be usable for the foreseeable future. I created it by reverse engineering the Store Client, it copies the same calls, etc.

[stevewri]

Not a ProjectReunion ask per se, but I'm working to find the right owner and channel.