ios: Initialize notifications (token retrieval, authorization) with our own code, not Firebase

[chrisbobbe]

On iOS, Firebase isn't involved in delivering notifications, but we've still been using firebase_messaging and firebase_core in some setup that involves communicating with the iOS platform:

1. Telling APNs servers that we want notifications (NSApplication.registerForRemoteNotifications), and then:
   • On success, grabbing the resulting token, to register the device with the Zulip server (POST /users/me/apns_device_token, and soon POST /api/v1/mobile_push/register for E2EE)
   • On failure…doing nothing currently, I think, but ideally retrying if we couldn't reach Apple because of network issues
2. Telling the platform to show a permissions prompt (UNUserNotificationCenter.requestAuthorization(options:completionHandler:))

This seems to have worked OK so far, but there are a few issues:

• We're supposed to request permission (2) before registering with APNs (1) (doc)——and we do that out of order.
• The platform tells the APNs token to the app by calling a method on AppDelegate (UIApplicationDelegate.application(_:didRegisterForRemoteNotificationsWithDeviceToken:)). The firebase_messaging API doesn't seem to support adding a listener for that; instead it looks like it just has a method to query a stateful field which is populated when that AppDelegate method is called. (implementation)
  • So it seems vulnerable to races between success of the APNs registration and our querying for the token, which we do just once.
• The libraries have a lot of unrelated code to sift through, including for FCM delivery of iOS notifications, and it's in Objective-C instead of Swift.

---

If we were writing all of this ourselves, here's a sketch of what it could look like with our current Pigeon architecture (using Swift! 🙂):

• New Pigeon enum IosNotificationAuthorizationStatus with values authorized, denied, provisional.
• New Pigeon sealed class IosApnsRegistrationEvent with subclasses:
  • IosApnsRegistrationSucceeded — carries a String token (the APNs device token as a hex-encoded string, converted from the raw Data on the Swift side)
  • IosApnsRegistrationFailed — carries a String error
• New methods on NotificationHostApi:
  • iosRequestAuthorization({required bool provisional}), which is async and returns IosNotificationAuthorizationStatus. On the Swift side, this calls UNUserNotificationCenter.requestAuthorization(options:completionHandler:), then UNUserNotificationCenter.getNotificationSettings to distinguish authorized from provisional (since the requestAuthorization completion handler only gives a boolean).
    • Call this in NotificationService.start.
      • If you haven't logged into any accounts yet (which we can check using ZulipBinding.instance.getGlobalStore()), include "provisional" in the authorization request so it doesn't kick up a permissions prompt (for Defer setting up notifications until user has logged in #324).
      • (Also call it here if you have logged into an account, so that if permissions are still granted, we still call iosRegisterApns, described below. That's how we'll respond to the token changing between app sessions, which can happen. In this case "provisional" isn't needed, I think.)
    • Also call it when you log into an account, without "provisional". This will kick up the permissions prompt for Defer setting up notifications until user has logged in #324.
  • iosRegisterApns(), which calls UIApplication.shared.registerForRemoteNotifications() (on the main thread via DispatchQueue.main.async). Call this whenever we get a non-denied result from iosRequestAuthorization. (The ios prefix is because NotificationHostApi is shared in the Pigeon definition and generates Kotlin code for Android too.)
• New event stream iosApnsRegistrationEvents in NotificationEventChannelApi, emitting IosApnsRegistrationEvent. A single stream for both success and failure, matching the existing notificationTapEvents pattern. The Dart side pattern-matches on the event type.
  • NotificationService.start adds a listener for this stream before iosRegisterApns is ever called, to avoid missing events.
  • On IosApnsRegistrationSucceeded: update NotificationService.token.
  • On IosApnsRegistrationFailed: log, and consider retrying iosRegisterApns if the error seems transient (like a network issue).
• Clean up: remove kFirebaseOptionsIos (no longer needed). The firebase_core/firebase_messaging deps stay in pubspec.yaml for Android; Flutter doesn't support per-platform plugin exclusion (flutter/flutter#81650).