feat(notifications): open the chatbox on iOS push notification tap

[aramslegit]

Summary

Open the Crisp chatbox when the user taps a Crisp push notification on iOS.

Today on iOS, tapping a Crisp notification brings the app to the foreground but leaves the message hidden in the closed chatbox. The wrapper's notification-tap delegate (userNotificationCenter(_:didReceive:withCompletionHandler:)) calls CrispSDK.handlePushNotification(...) (SDK bookkeeping only — the foreground willPresent path also calls it and then just shows a banner) and never presents the chat.

This is the natural counterpart to #29, which wired the foreground onPushNotificationReceived event: #29 handled received-while-open; this handles tapped-while-closed.

Android needs no change. I checked the Android SDK (crisp-sdk 2.0.18): both notification modes call CrispNotificationClient.handleNotification(ctx, msg) (openChatbox=true), whose content PendingIntent is a TaskStackBuilder of [launcher activity, ChatActivity(sender=crisp)] — so a tap already opens ChatActivity directly via the SDK. The gap is iOS-only.

Changes (iOS only)

ios/CrispAppDelegateSubscriber.swift — after handlePushNotification in the tap delegate, present ChatViewController on the top-most view controller (mirroring the module's existing show()). A small helper:

• walks the presentedViewController chain and no-ops if a chatbox is anywhere in it (the chat can itself present a child VC, e.g. an image/attachment preview, so checking only the top-most node would double-present);
• bails if a transition is in flight (isBeingPresented / isBeingDismissed), which UIKit would otherwise drop with a warning.

This runs in both notification modes (the Crisp-notification branch precedes the coexistence check), which is intended — handlePushNotification is bookkeeping-only in both modes, so the explicit present is always needed on iOS.

README.md + .changeset/ — document the behavior (iOS opens chat on tap; Android already does via the SDK).

Design note

This auto-presents the chatbox on tap (what most apps want, and what the SDK's bookkeeping call implies). If you'd prefer the wrapper to instead emit a JS event (e.g. onPushNotificationTapped) and let the host navigate, I'm happy to switch — just say which you prefer.

Testing

Running in production in a shipping app (1fifty), verified end-to-end on a physical iOS device in both notification modes: operator message → background the app → tap the notification → the chatbox opens to the conversation.

Backward compatibility

Additive, iOS-only. No public API or config changes; notification receipt and the existing show() are unchanged — only the previously-no-op tap path now presents the chat.

Notes for reviewers

• The new key-window lookup mirrors the one in findRootViewController() (ExpoCrispSdkModule.swift); kept inline to avoid pulling in a shared util in this small PR — happy to extract a shared helper if you prefer.
• presentChatbox() is actually more robust than the existing show() (which presents off the root VC and can fail when a modal is already up). Unifying show() onto the same logic is a sensible follow-up; left out here to keep the PR focused. (I also have a couple of small standalone registerPushToken robustness fixes I can send separately.)