iOS push notifications require an app restart because the initial FCM token is not uploaded #39

Description

On a fresh iOS installation, the console registers with the backend before Firebase provides an FCM token. When the token arrives, it is stored locally but the backend registration is not updated. Push notifications therefore remain unavailable until the app is restarted.

Steps to reproduce

1. Launch a fresh installation and allow notifications.
2. Complete console registration.
3. Observe the FCM token arriving in the Xcode logs.
4. Check the backend console asset: the token is absent.
5. Send a Firebase Console test notification directly to the logged token: delivery succeeds.
6. Terminate and relaunch the app.
7. The cached token is now uploaded to the backend, and backend notifications work.

Expected behaviour

The backend console registration is updated when the FCM token becomes available, without requiring an app restart.

Code responsible

• PushNotificationProvider.enable() in console-ios-lib 0.5.2: after permission is granted, it schedules registerForRemoteNotifications() and immediately returns a successful PROVIDER_ENABLE response containing the token currently in UserDefaults. On first launch, that token is not yet available. The already-authorized branch has the same behaviour.
• [Console.enableProvider()](https://github.com/openremote/openremote/blob/1.28.1/ui/component/core/src/console.ts#L228): the web app copies this response into its registration and sends POST /api/{realm}/console/register.
• OurGrid’s AppDelegate.messaging(_:didReceiveRegistrationToken:): the subsequent Firebase callback only writes the token to UserDefaults. It does not notify the web app or trigger another console registration.

On relaunch, the provider finds the cached token and includes it in registration, explaining the workaround.

Required fix

Propagate token availability and subsequent token changes to the web app, update providers.push.data.token, and resend the console registration. Verify first-launch delivery with delayed token generation, without restarting the app.

The first-launch race is in ORLib’s push provider, but a complete fix needs coordination with the app.

• ORLib starts APNs registration and immediately reports successful provider enablement using the cached token—even when no token exists. It has no handling for a token arriving later.
• The app owns Firebase’s didReceiveRegistrationToken callback. Currently, it only saves the token locally; it doesn’t notify ORLib.

The reusable fix would be:

1. ORLib exposes a method to receive new or refreshed FCM tokens.
2. The app calls that method from its Firebase callback.
3. ORLib propagates the token to the web app, which updates the backend registration.

The app would need a small integration change to use that API. The backend registration endpoint already works, as your relaunch test demonstrates.