Questions

Hi, I'm hoping for some help diagnosing an issue that appeared between our TestFlight build and our App Store release.

Summary: Push notifications using targetUrl in Additional Data (per your docs: median.co/docs/open-url-from-notification) correctly deep-link into the app on warm start (app already open/backgrounded), but on cold start (app not running), tapping the notification opens the app at the homepage instead of the target URL.
What changed: This worked correctly in our TestFlight build (tested prior to release). After submitting to the App Store in mid-May, cold-start deep linking broke. We also noticed a new "Powered by Median" native launch screen appeared around this time, suggesting our App Store build was running a newer/different native wrapper version than our working TestFlight build.
We've since rebuilt and resubmitted (approved and live on our test devices as of yesterday -6th July 2026) with no other changes - the issue persists identically. So this isn't a stale-build issue; the current build has the same problem.

Diagnostics we've gathered (via our own telemetry logging before/during app load):

The push payload is confirmed correct — targetUrl is present and correctly formatted in Additional Data.
On cold start, the very first URL the WebView loads is our app's root, not the target URL. This is logged before any of our own JavaScript runs.

None of the three documented JS callbacks (median_onesignal_push_opened, median_onesignal_data, median_notification_callback) ever fire on cold start. They do fire correctly on warm start.
window.median.onesignal is present on cold start (bridge exists), but exposes no method to retrieve a pending/launch notification - only device/subscription info methods (onesignalInfo, register, tags, etc.).

We tested OneSignal's native url (Launch URL) field as an alternative — this opens in an external Safari-style flow instead of the in-app WebView, consistent with your own docs' warning that Launch URL doesn't support the JS bridge. So this isn't a usable workaround for us.

What we've ruled out:

Our Universal Links / apple-app-site-association file is live, valid, and matches our app's Team ID + Bundle ID.
Our web app's callback registration code is unchanged since the working TestFlight period, and is registered before any bundle/React code runs.
Push delivery itself works fine - notifications arrive correctly every time.

What we can't inspect ourselves: We exported the native iOS source via App Studio and reviewed it, but the core notification/bridge handling logic (GNBridge, referenced in the app delegate) appears to be part of your compiled GoNativeCore Swift package dependency, not visible source - so we can't go further ourselves.

How can I fix this? Given targetUrl is supposed to navigate the app directly per your own docs (independent of the JS callback), what's the correct way to get this working again on cold start - is there a setting we're missing, a specific build/SDK version we should pin to, or a known fix? Thanks for any help - this is a live production issue for our launched app.