Push Notifications Stack: Tech Debt

[jleandroperez]

Description:

We need to clean and modernize our Push Notifications Stack:

1. Push Notifications have, mainly, two aspects: the API that runs when a Push arrives, and the API that runs when the user interacts with a System Alert
2. Before iOS 10, all of it was handled by PushNotificationsManager
3. Standard way to check if the user pressed on a Push Alert has always been applicationState != .background
4. In iOS 10 AAPL introduced UNUserNotificationCenter
5. We've builtInteractiveNotificationsManager to encapsulate handling of Push Notifications with multiple interactions (Like / Approve / Etc)
6. In iOS 13 point (3) stopped being accurate, and has been the source of Issue Fixing Push Authentication #14349

Details:

Tech Debt has been increasing, and we've reached a point in which both PushNotificationsManager and InteractiveNotificationsManager call each other.
We must:

• Review all the things
• Drop applicationState usage
• Definitely drop @objc
• Ideally speaking, have 3 classes to deal with the use cases we've got:
  1. Push Registration: Registering / requesting permissions
  2. Push Notification Received: The document arrived. Used by the AppDelegate
  3. Push Notification Pressed: User interaction was detected. Used by UNUserNotificationCenter
• (2) and (3) may need to run the same code in few specific scenarios such as "Push Auth Received" while the app was in foreground, or "Push Auth was pressed".

[jkmassel]

Reopening. This was closed not_planned in March 2023 by its author with no comment, after sitting untouched since 2020 — which reads as a backlog sweep, not a decision that the refactor shouldn't happen. The debt described above is still here, and it's now compounding rather than static, so it's worth keeping visible.

What's changed since this was filed

• Adopting the UIScene life cycle (Adopt the UIScene life cycle #25643) added a third site that sniffs applicationState to infer user intent. Under scenes, a notification-tap cold launch arrives while applicationState == .background (the scene has connected but the foreground transition hasn't completed), so handleInactiveNotification had to widen its guard to applicationState == .inactive || (applicationState == .background && userInteraction). That's the same applicationState/userInteraction workaround handleAuthenticationNotification has carried since 2020 (Fixing Push Authentication #14349) — three copies now.
• The original rationale here was that iOS 13 made applicationState != .background unreliable. The scene life cycle makes it less reliable, not more: every lifecycle change Apple ships adds pressure to exactly the signal this issue wants to drop.
• The correct signal is already available and ignored — a tap is a UNUserNotificationCenter didReceive response. Driving "pressed" off that (the split this issue's description already proposes: Received vs Pressed) removes the applicationState guessing entirely.
• Related and still open: handleNotification can drop the remote-notification completion handler, throttling background push delivery #25657 (the handleNotification dispatch loop can drop the remote-notification completion handler) — same stack, more evidence it's fragile rather than settled.

Scope

Unchanged — the plan in the description above still holds. The honest blocker is capacity + regression risk: push is sensitive, OCMock-tested, and multi-state, so a refactor could regress delivery. That makes this a prioritization call — but it's one we should make deliberately, not inherit from a silent close.

Surfaced while reviewing #25643.

[jleandroperez]

@jkmassel I'm afraid really don't remember the state of the WPiOS Notification Stack., TBH.

I do remember there was a big refactor after this ticket was logged, from which I wasn't part of, and perhaps it was no longer relevant (OR we didn't have the bandwidth).

In any case, great excuse to say HEY Jeremy!!