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.