Questions

Hi, following up on my original question on this topic as my question hasn't had a reply yet, though I can see a question submitted after mine has already been answered. I'd really appreciate a response, as this is a live issue affecting a launched app.

Please note we've already followed your documentation exactly as written, so a link back to the general setup docs won't resolve this; the issue is that the documented behavior itself isn't happening.

The issue: Push notifications using targetUrl in Additional Data work perfectly on warm start (app already open) but fail on cold start (app fully closed). On cold start, tapping the notification opens the app at the homepage instead of the target page. This is a regression - it worked correctly in TestFlight before our App Store release in mid-May.
What we've directly confirmed via our own telemetry (added before/during app load, not guesswork):

-The push payload is correct — targetUrl is present and properly formatted every time.
-On cold start, the very first URL the webview loads is our homepage, not the target URL - logged before any of our own JavaScript runs.
-median_onesignal_push_opened - the documented callback function never fires on cold start. It fires reliably on warm start, every time, using the identical function, with identical code on our end.
-Per your own docs (Handling Notification Taps): "targetUrl is a reserved key in Additional Data; including it automatically triggers in-app URL navigation when the notification is tapped." This native, automatic navigation is also not happening - it's not just the JS callback failing to fire, the underlying native mechanism itself isn't triggering either.
-window.median.onesignal is present and functional on cold start for other things (e.g. checking subscription info), so the bridge connection itself exists - it specifically fails to deliver notification-tap data on cold start only.

What we've ruled out on our end: correct payload structure, correct callback registration (verified registered before any app code runs), grace/timing windows (tested from 800ms up to 4000ms with no change - the callback never arrives at any point, however long we wait), Universal Links/AASA configuration, Xcode push capabilities, duplicate data fields, and OneSignal's Launch URL field as an alternative (opens externally, as your docs warn, so not usable in-app).

Our conclusion: Since median_onesignal_push_opened is the exact same function, with identical code, and fires reliably every time on warm start, the fault cannot be in how we've implemented or registered it. This points specifically to Median's cold-start launch/startup procedure - the native process that runs when the app is opened fresh from a notification tap, before your JavaScript bridge is available - as the point where the notification's data is being lost or not passed through correctly. We don't have visibility into this part of your system since it's part of your compiled native core, so we're unable to debug further ourselves.

Our question: Is this a known issue with your cold-start launch handling in a recent build? What's the fix, or what information can we provide to help you investigate on your end?