Proposal: Support Windows Push Notifications for Unpackaged Apps and Non-Store Apps

[nicuparente]

Summary

Status

Customer / job-to-be-done: App developers need to keep their users informed about new information even when their app is currently open, ideally in the most battery-efficient way Problem: Non-store apps cannot use push notifications, so they must keep their app running with a socket open to their server How does our solution make things easier? All types of apps will be able to use push notifications, and setting up push will be relatively straightforward

✅ Problem validation 🔄 Docs ✅ API spec (#458) 🔄 Dev spec 🔄 Solution validation 🔄 Implementation ❌ Samples

Target customer

Packaging	App types
✅ Packaged apps ✅ Unpackaged apps	✅ WPF ✅ Win32 (C++) ✅ WinForms ✅ Console ⚠ Cross-plat (Electron, MAUI, React Native, etc) ⚠ PowerShell

While this work should be consumable by cross-platform platforms to improve experiences there, we should have a separate feature specifically for ensuring push notifications are built in "natively" and developers don't have to do additional custom work to access the Windows native layer.

Customer's job-to-be-done

Job-to-be-done	Validated?
Have my server wake up my app on-demand	✅ Validated
Inform my users of new updates	✅ Validated

Problems that exist today

Problem	Validated?
Push isn't supported by non-Store apps: Apps distributed outside of the Store, even if they're MSIX, cannot use push notifications	✅ Multiple customers blocked on this
Push isn't supported in unpackaged apps: Normal Win32 apps cannot use push notifications since they don't have a platform identity	✅ Many Win32 apps don't even consider push because of this, or they see MSIX as too difficult to adopt

Summary

Currently, only Microsoft Store distributed UWP/ MSIX packaged applications can use Windows Push Notifications due to the explicit dependency to the Microsoft Store identity. This feature's goal is to allow all Windows Applications, including unpackaged Win32 applications and non-Microsoft Store identity apps, to utilize push notifications.

Scope

Capability	Priority
Windows apps can use Windows push notifications without a non-Microsoft Store identity	Must
Developers can send push notifications from their servers to WNS using Reunion	Must
Unpackaged applications can receive Windows push notifications	Must
Visual toast push notifications are supported	Must
Windows applications can be foreground activated	Must
Unpackaged Windows applications can be background activated	Must
Visual tiles and badge push notifications are supported	Could

Important Notes

API Usage Experience

1. Getting Credentials to use Push Notifications

In order to get started using push notification you need to get an identity from the Azure Active Directory App Registration more info here.

2. Application Requesting WNS Channel

PushChannelRequest channelRequest = await PushManager.CreateChannelAsync("your-azure-application-id");

if (channelRequest.Channel != null)
{
    string channelUri = channelRequest.Channel.Uri;

    // Send the push channel to your server
    await SendChannelAsync(channelUri);// You must create this method, to send the channelURI to your application server

}
else
{
    // Creating channel failed, see error for info
    var error = channelRequest.Error;

}

Handling Channel Request Retries

PushChannelRequest channelRequest = await PushManager.CreateChannelAsync("your-azure-application-id");

int maxRetryAttempts = 3;
while(maxRetryAttemps > 0 && channelRequest.Channel != null)
{
    if (channelRequest.Channel != null)
    {
        string channelUri = channelRequest.Channel.Uri;

        // Send the push channel to your server
        await SendChannelAsync(channelUri); // You must create this method, to send the channelURI to your application server
    }
    else
    {
        // Creating channel failed, see error for info
        var error = channelRequest.Error;

        // Check if the error is retryable
        if(channelRequest.requestRetryable)
        {
            //Should we name it differently?
            await channelRequest.CreateChannelAsync();
            
        }
    }
}

3. Sending Push Notifications

This code would exist in your application server and would connect to WNS.

//Gets your credentials to send push notifications
PushServerManager.Start("your-application-secret-from-azure-app-registration");

string channelUri = "your-channel-from-step-2";

// Construct the content and send the notification!
await new NotificationBuilder()
    .SetLaunchArgs("picOfHappyCanyon")
    .AddText("Andrew sent you a picture")
    .AddText("Check this out, Happy Canyon in Utah!")
    .SendAsync(channelUri);

[mdtauk]

Will this API include support for Live Tiles or updating the App or the App's Pinned Tiles?

[andrewleader]

@mdtauk this proposal is primarily focused on visual toast notifications and raw push notifications (where your app gets woken up in the background and can execute code). You'll notice support for push tile notifications is currently listed as a "Could" priority. If you need push tile notifications can you give a specific example of your use case, and the type of app (UWP, WPF, Win32), and whether it's distributed through the Store or not?

[mdtauk]

@andrewleader With UWP there was a level of synchronicity with the Notification Channels being used to update tiles. Whilst I no longer have an app out in the store, I did have with Windows Phone 7 - and so it should probably be considered in terms of the use of payloads, and call into the Tile Update Manager.

With Apple finally adopting the concept of a Live Tile like Widget - making it easy to support the same kind of functionality which is already there in Windows, is worth doing, even if its not there in an initial first wave.

What the Windows team may have in mind for the future of Live Tiles, may play more of a role in when or if it is supported in Reunion - and Windows 8 has Live Tiles which could be supported also.

[ccauquelin]

My company have several clients that would benefits from this feature (they deploy Non-Store version of our Apps internally and can not leverage the Push Notification feature). Thanks for considering this enhancement.

[andrewleader]

Awesome! @ccauquelin are your clients building UWP apps or Win32 MSIX apps or normal Win32 apps?

[ccauquelin]

They are using our UWP app, installed via sideloading. We are signing our UWP app for sideloading with a genuine code signing certificate, but unfortunately this "breaks" the Push Notification feature in our app.

[christopher-rtf]

They are using our UWP app, installed via sideloading. We are signing our UWP app for sideloading with a genuine code signing certificate, but unfortunately this "breaks" the Push Notification feature in our app.

@ccauquelin -- one can support push notifications in sideloaded UWP apps today using WNS alternate push channels. This requires using an alternate mechanism (VAPID, etc.) to push notifications to the WNS servers...but it works outside the Store.
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/alternate-channel-vapid-webpush

@andrewleader -- we currently use APNs for push notifications on macOS (in a notarized application we distribute outside the app store). And we're currently planning to mirror that push notification support in our Windows WPF application using the new Project Reunion push notification functionality. Is there a master list of WNS-related PRs (i.e. the various prerequisites/APIs for Project Reunion push notification)? We'd be happy to test them out in both MSIx and unpackaged WPF scenarios--as each of them are developed and lit up--if that would be helpful.

[christopher-rtf]

A related bug report, in case it's helpful:
microsoft/CsWinRT#905

TL;DR:
We're migrating our existing WPF code which uses WNS raw push notifications (alternate channel) to .NET 5.0. This works under earlier versions of .NET which used Microsoft.Windows.SDK.Contracts but is broken under .NET 5+ which uses TFM.

Hopefully we can get both options for WNS push notifications working 100% under .NET 5/6 (alternate channel using sparse packages via a TFM bug fix, plus traditional channel via the cool new Windows App SDK).

[adamcosby85]

Hi, is there any update on this? I have been monitoring it for a while.

We currently have to have a UWP front end that we use desktop bridge however it causes quite a few complications. We want to be able to receive raw notifications from the Azure Notification Hub directly to our WPF application.

[hulumane]

Windows App SDK preview 1.3 should have the changes you need to consume the Push APIs for Unpackaged @vaheeshta has put that into Release notes I believe? The feature unfortunately is broken in Preview 1.2 due to a last minute bug that we identified.

[adamcosby85]

That is great and I appreciate the quick response!

Do you have any sample code or documentation yet on how we can test this?

I also appreciate this is still preview however is there any thoughts on when this would be GA? More for our planning than anything else at this point.

many thanks

[jonwis]

@hulumane did you mean WinAppSDK 1.1-preview2 / 1.1-preview3, or specifically WinAppSDK 1.3 (for which I don't think we've announced a featureset or release date...)

[hulumane]

Correct. Sorry that was my bad. Yes. I meant 1.1 - preview 3

[hulumane]

@adamcosby85 We have some documentation on the Client APIs along with sample code here:
specs/PushNotifications/PushNotifications-spec.md

Please note that Unpackaged apps won't work with Preview 2. They will work with Preview 3 which has addressed the issue at hand. But this should help you get a start on ramping up.

[vaheeshta]

Correct, unpackaged app support is coming to Windows App SDK 1.1-preview3 after a regression in Windows App SDK 1.1-preview2. Please see the official release notes for the most up-to-date information:

• https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/preview-channel for the preview releases
• https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel for the stable releases
• https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/experimental-channel for experimental releases

Keep an eye out on https://github.com/microsoft/WindowsAppSDK/discussions/categories/announcements and the stable release notes for when the feature will hit the stable release/GA!

[vaheeshta]

Proposal has been addressed with the latest Windows App SDK 1.1 APIs. See https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/notifications/push-notifications/push-quickstart for how to use the push notification APIs to support unpackaged apps. Closing the issue!

[scarabdesign]

@christopher-rtf

one can support push notifications in sideloaded UWP apps today using WNS alternate push channels. This requires using an alternate mechanism (VAPID, etc.) to push notifications to the WNS servers...but it works outside the Store.
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/alternate-channel-vapid-webpush

The referenced page is no longer available. Is there an alternate source of the steps required to use Vapid in a side-loaded UWP app, or is this no longer supported?

Again to re-iterate, in order to get notifications through WNS with a UWP app you have to distribute a certificate that is issued when uploading the app to the MS Store, whether you distribute the app through the store or not. But, if you are side-loading the app (making the app available to download outside of the store), the store certificate won't work as you need a specific side-loading certificate, but that means notifications don't authenticate.

It's not possible for us to convert our project to a Window App SDK project at this time, so I can't use the update announced in this thread.

[christopher-rtf]

@scarabdesign - the instructions on alternate channel notifications (VAPID) appear to have been moved to another page.
https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/channel-types

I am guessing that WNS is probably the recommended path forward. Of note, for alternate channel, "as of July 1, 2021 applications that want to use the web push channel or the alternate channel to send browser based notifications through WNS will need to be onboarded to the Microsoft Store."

I don't know if that applies to applications that use the alternate channel to send non-browser based notifications or not. New apps probably needs to be onboarded with the Microsoft Store (rather than in the old partner app registrations) to use VAPID push notifications.

I don't work for Microsoft, so this is largely conjecture. Hopefully someone from the push notifications team can chime in.

[nbevans]

Does anyone know what "onboarded to the Microsoft Store" means in the context of a sideloaded LOB app?