[feat] Push Notifications

[sgammon]

Describe the problem

Several platforms supported by Tauri - macOS, iOS, and Android, to name a few - have some kind of built-in push notifications system. For Apple systems, of course there is APNS, and for Android and Firebase-enabled apps, there is FCM.

Tauri isn't yet able to support these APIs, as far as I can tell. On Apple platforms, the developer must register a method with the AppDelegate and call a method on NSApplication, which isn't easy to do from Rust. iOS uses a similar flow, but with UIApplication instead.

Push Notifications are likely to be a common need for Tauri developers, especially on mobile platforms.

Describe the solution you'd like

I think Tauri should add calls to the UIApplication and/or NSApplication to register for push notification support on behalf of the developer; or, Tauri should make available such calls so the developer can implement support themselves.

Alternatives considered

1. I looked for plugins and found none
2. I looked for easy Rust bindings to register for APNS, and found none because these APIs use {NS,UI}Application
3. I looked into alternative push systems (3rd-party), but these aren't integrated well with underlying operating systems like Android and iOS, as compared to native push infrastructure

Additional context

General support

In most cases, "registering" for these push systems consists of a few relatively simple steps:

1. "Registering" or "requesting" a token from the application, using system APIs, potentially within the app entrypoint
2. "Receiving" the token via some callback or delegate mechanism (the token is typically just some raw bytes or a string)
3. Making the received token available to the developer

• Usually the developer will want to send this token to a server
• Callbacks or even just a method to retrieve the latest push token (if any) would work fine for callers, probably

Apple Platforms

macOS

It looks like tao already sets up an AppDelegate, where we would need to call registerForRemoteNotifications, and then receive the token at the delegate method application(_:didRegisterForRemoteNotificationsWithDeviceToken:).

iOS

Nearly identical to macOS, but with UIApplication.registerForRemoteNotifications() and the equivalent delegate method.

Android

Firebase uses a Service on Android to implement messaging within an app. This service is declared in the AndroidManifest.xml and then implemented within app code; the service:

• Requests a token
• Receives the token/receives updated tokens
• Receives pushed messages directed to the app

This would be implemented in Kotlin as part of an Android mobile plugin for Tauri. Luckily there are no changes anticipated for tao or tauri itself; Android push can happen through the plugin alone.

Windows

Windows apparently has Windows Notifications System (WNS), which is accessible via the windows crate. So far it appears to function similar to Android, in that a library can obtain a push channel without special code in the app entrypoint.

Linux

I'm not aware of native push infrastructure for Linux. Other SDKs can be used on Linux which do not require instrumentation in the app entrypoint.

[osdiab]

Someone published this undocumented plugin, but no idea if it works or what, haven’t tried it and don’t know anything about how mobile platforms work really.

https://github.com/guillemcordoba/tauri-plugin-fcm-push-notifications

Hoping that this feature gets added - seems like table stakes for Tauri to be usable for serious mobile apps!

[osdiab]

Not sure the current status of this but @gordongrech claims to have made FCM work on Android and iOS, so sounds like it’s feasible with the plugin system.

#8423

[eatenpancreas]

I have managed to get FCM working on Android, attempted IOS but didn't get far for now due to time constraints

This person has worked on a FCM plugin before and it seems to be further along on IOS. Haven't tested it myself but it could be useful:

https://github.com/flapili/tauri-plugin-fcm

[sgammon]

@osdiab / @eatenpancreas

The blocker right now is iOS, which is structured differently in Tauri's internals than macOS (Mac is much more straightforward to implement). It may indeed be possible to implement some platforms with only a plugin, but Mac and iOS probably need this deeper integration for the reasons outlined in the PR (FCM does not use the same APIs as you guys probably know).

I've raised the iOS questions on Tauri's contributor Discord, but so far haven't found any expertise. I think what I will do is split off the iOS changes et. al so they can be worked on in a separate PR.

This would mean that macOS and Android, at least, can be delivered here, and then iOS and potentially WNS can follow shortly thereafter, after some advice from whoever wrote the iOS code.

[sgammon]

Also, I'd be happy to collaborate with anyone who is interested. My main hopes right now are to get this PR tree to stable, and to make this entire changeset less invasive by eliminating any changes that can be dropped.

[jd-carroll]

Nice work on all of this. As someone who is still trying to grasp the Tauri architecture, it might be nice to have a very brief write-up of the different pieces you needed to touch to make this happen (more for educational purposes). While I think all of the PR's are above, there seemed to be a lot of PR's to your personal repo too so it was a little hard to follow.

But broadly, nice work!

[jd-carroll]

Separately and why I am really here... Since this change involves accessing the AppDelegate, I'd like to make a plug for broader access or hooks into the AppDelegate.

For example, I am building a banking app and I would like to display a loading / splash screen when the app is re-opened. The documentation I've found says I should hook into the WillEnterForeground event.

To my knowledge, this is not currently exposed in Tauri. It would be great to be able to redirect to a loading screen and then redirect back when this event is triggered.

I'm not trying to suggest that this be included in these changes, but merely that as this change involves the AppDelegate some consideration to additional AppDelegate use cases would be appreciated! ❤️

[davehorner]

commenting to voice support and to watch this ticket. two repos and PRs given above. I will play around, if someone has any notes for my cycle. lmk.

[nicoburns]

@jd-carroll You should take a look at the latest winit changes for macOS. It uses an event handler registration technique which means that Winit no longer needs to own the AppDelegate and applications can register their own. I libraries can also use the same technique that Winit is now using to register their own handlers without needing the AppDelegate.

[sgammon]

@davehorner Thanks. I think we are still waiting on advice from maintainers. I'm ready to finish the PR, but I haven't been able to locate anyone from the Tauri team who can advise about iOS changes. Until then, this PR sits idle. I can easily rebase it once that advice is forthcoming (or, a decision is made to cut iOS from this PR).

[sgammon]

@nicoburns Sorry, what is Winit? Is there a reason this feature/tao change is no longer needed? That would radically simplify the attached PR

[nicoburns]

@nicoburns Sorry, what is Winit? Is there a reason this feature/tao change is no longer needed? That would radically simplify the attached PR

Winit is what Tao forked from. If Tao synced this change from Winit or Tauri switched back to using Winit then I think it would mean that this functionality could be implemented outside of Tao/Winit. At least on Apple platforms. I'm unfamiliar with how this works on windows.

[jd-carroll]

@sgammon - Did you ever hear anything more from the Tauri team? (maybe on discord?)

@nicoburns - Thanks for the information! I tried looking at the recent changes / changelog and couldn't quite pinpoint where / when this change was made. Anything you could point me to? (either documentation, blog, changelog, etc.)

[jd-carroll]

@sgammon - Apologies for @mention'ing you again, but... I think you might be interested in this repo:
https://github.com/inKibra/tauri-plugins/blob/fc145aa0463f73a1e0e6f9a86d8e365c263c7ed3/packages/tauri-plugin-notifications/ios/Sources/NotificationsPlugin.swift#L138

Seems like it is (at the very least) an example of how to integrate with the AppDelegate.

[sgammon]

@jd-carroll Thanks and no worries for the multiple mentions. I'll take a look. Yes, the Tauri team got back to me on some of the stuff I asked (in particular, whether PRs for multiple crates is seen as invasive -- it's not, it's fine, which is great).

I still have questions about iOS integration, but either I'll answer those with links like you sent, or I'll continue without iOS and include it in a followup PR.

[bradleat]

I have a version here for iOS:

https://github.com/inKibra/tauri-plugins

[sgammon]

@bradleat Would you be interested in combining our efforts? That's really helpful

[d0m1n1kr]

@sgammon We successfully use https://github.com/inKibra/tauri-plugins for iOS and also added basic support for android here: https://github.com/FreshX-GmbH/tauri-plugins/tree/main/packages/tauri-plugin-notifications . The workaround to not patch TAO (overwrite the app delegate in the plugin in proxy all calls to the original delegate) is a little bit hacky, but it works.