[Miggets7]

Fixes #21. Refs #39 (first-launch race only, see Behaviour notes). Root cause of openremote/ourgrid#227.

Problem

On a fresh iOS install the push provider answered PROVIDER_ENABLE with the FCM token cached in UserDefaults. Firebase had not delivered one yet, so the console registered without a token and push only worked after an app restart.

Changes

• PushNotificationProvider.enable() now does what the Android console does: it registers for remote notifications right away and waits for the token before replying. The permission prompt runs in parallel, so a slow tap on the prompt no longer counts against the web console's 5 s provider timeout. The wait is capped at 4.5 s.
• New ORNotificationHandler takes over the notification and Firebase token handling every app duplicated in its AppDelegate. Apps forward three callbacks to it (snippet in the README). It stores the token and wakes a waiting push provider.
• The handler finds the console view controller through the connected scenes, so "open in app" from a notification now works in scene based apps such as OurGrid.
• ORLib still has no Firebase dependency.
• README lists the Firebase setup the app must do: FirebaseApp.configure() and the messaging delegate on every launch path, and forwarding apnsToken when swizzling is off.

Behaviour notes

• A rotated token is stored and reaches the backend the next time the console enables push, which iOS does on every page load. Android behaves the same.
• If Firebase needs more than 4.5 s, the reply goes out without a token and the next launch sends it. Closing that gap would need a change in console.ts.
• When no token is cached (first launch), the enable reply can take up to 4.5 s. console.ts enables providers one after another, so the geofence enable and the registration POST wait as well. Android waits on getToken() with no cap, so a reply after 5 s is dropped by console.ts and no registration is sent. The 4.5 s cap avoids that on iOS.
• If the token arrives before the user answers the permission prompt, the reply carries hasPermission: true. Android always reports true, and the backend does not read the field.
• When the user denies the first prompt, the token is still registered. Enabling notifications later in iOS Settings then works without a new registration. The .denied branch still skips remote registration.
• ORViewcontroller holds the enable callback weakly, so the wait doesn't keep it alive.

Testing

• New suites PushNotificationProviderTest and ORNotificationHandlerTest. Full suite passes on the simulator (118 tests).
• Tested end to end with OurGrid on a device against this branch.

Follow-up

A release is needed after merge. openremote/console-ios-app and openremote/ourgrid PRs bump to it.

#39 stays open: tokens that arrive after 4.5 s, and rotated tokens, only reach the backend on the next page load. Closing that needs console.ts to accept a token update from the provider.

[MartinaeyNL]

Initial AI assisted Review

Verdict: the approach is right — waiting in enable() is the only hook ORLib owns (console.ts
drops late replies and has no token-update channel), and ORNotificationHandler as a forwarding
helper matches #21.

Before merge

1. hasPermission: granted ?? true (PushNotificationProvider.swift:122) is an optimistic
   guess when the token beats the user's tap. Registering for remote notifications before
   requestAuthorization makes this more likely. Wait for both signals within the budget (or
   document the trade-off in "Behaviour notes").
2. README prerequisites are incomplete — the fix only works if the app also forwards the APNs
   token (Messaging.messaging().apnsToken = deviceToken) and configures Firebase on every launch
   path (console-ios-app#46 does both). Same gap in the ORNotificationHandler doc comment.
3. Fixes #39 is partial — first-launch race is fixed (≤4.5 s); late (>4.5 s) and rotated
   tokens still only reach the backend on the next page load. Keep #39 open or file a follow-up for
   the console.ts change.

Behaviour changes / side effects

4. PROVIDER_ENABLE now takes up to 4.5 s when no cached token (every first enable per launch,
   and any launch where the cache is empty, e.g. changed app group). console.ts awaits providers
   sequentially, so this also delays the geofence enable, the registration POST and the app's
   enableComplete callback.
5. Remote registration now happens even when permission is denied → backend can hold tokens for
   devices that can't show notifications (delivery/ack stats get holes). Upside: enabling later in
   iOS Settings works without re-registering.
6. No early exit when registration fails — nothing observes
   didFailToRegisterForRemoteNotifications; a device without APNs/Firebase (incl. simulator)
   always burns the full 4.5 s then replies token: null. Consider forwarding that failure to the
   handler.
7. Pending callback retains ORViewcontroller up to 4.5 s (ORViewController wires
   self.sendData strongly) — was ~instant before; [weak self] would fix.
8. console.ts "Message already pending" collision window grew from ms to 4.5 s — manual
   enableProvider("push") during auto-enable now throws easily.
9. API break for subclasses: init() became convenience init() and the designated init is
   internal — external subclasses of PushNotificationProvider are no longer writable. Release
   notes should mention it.

Smaller items

10. The 4.5 s ↔ console.ts 5000 ms coupling is an undocumented cross-repo constant — comment both
    ends, consider making it tunable.
11. didReceiveRegistrationToken(nil) doesn't clear the stored token (deleteToken case) — stale
    token is re-sent.
12. activeORViewController() only walks presentedViewController (no child containment → nav/tab
    hosts silently no-op) and is internal; apps still using window?.topController (e.g. geofence
    deep links) can't reuse it. Make it public, consider a containment walk.
13. enable() itself is untested (UNUserNotificationCenter not injectable) — the new
    permission/hasPermission branches are only covered via waitForToken. Small injection seam
    would fix.

[MartinaeyNL]

Did a thorough review to understand what was going on here, because I'd like to prevent any unwanted bugs.
It was helpful getting the code explained to me, especially since I am not a Swift expert haha
Happy with the changes overall.