Questions

Setup: iOS app wrapped with Median, built on the Base44 platform. Sign-in uses a standard redirect-based OAuth flow (not a native SDK) — tapping "Sign in with Google" or "Sign in with Apple" navigates to accounts.google.com / appleid.apple.com, which then redirects back to our own domain (haventravel.app) with a session token appended to the URL.

What's happening: In the Median-wrapped app, this OAuth flow opens in what appears to be an isolated in-app browser sheet (has its own native "X" close button, top-left). The redirect completes successfully — we can see the app fully loaded and signed in inside that sheet (verified via screenshots: it shows our actual app content, e.g. the user's trip list). But when the user taps the "X" to close the sheet and return to the main app, the main app is signed out. Force-quitting and reopening the app also returns to a signed-out state.

Our diagnosis: the sheet Median opens for these OAuth domains is a separate browser context (e.g. ASWebAuthenticationSession or SFSafariViewController) with its own isolated storage, not the same WKWebView instance/storage as our main app. So the session token that lands in that sheet's localStorage after the OAuth redirect never reaches our main app's webview.

What we've already tried (no effect):

• Link Handling rules set to "Internal" for accounts.google.com and appleid.apple.com
• "New Windows" setting tried as both Blocked and Permitted

Our platform's (Base44) suggested fix: capture the session token from localStorage once the OAuth redirect completes inside that sheet, then use Median's native storage bridge to pass that token back into the main webview, where we'd restore the session. Their exact words: "The key question for Median.co is whether their bridge can intercept the callback URL from the sheet before it closes and extract the token there. If their bridge supports Universal App Links as the OAuth return destination rather than a custom URL scheme, the token could be delivered directly into the webview context."

Our questions:

1. Does Median's JS bridge or any native plugin support intercepting the final OAuth callback URL from that sheet before it closes — e.g. via Universal Links — so we can extract the token and hand it to our main webview's JS?
2. Is there a Median-specific mechanism (separate from general Link Handling rules) to keep this specific OAuth redirect inside the main webview, given Google actively blocks OAuth in a standard WKWebView user agent?
3. If neither is possible, is your Social Login native plugin (enabled, not yet wired up) the only way to keep this in the main webview's JS context? Does its callback fire in the main webview, or does it also open a separate native UI with the same isolation problem?

Happy to share a screen recording of the exact flow if it helps reproduce on your end.