Why

Fixes #49749.

WebBrowserSession.open() presents through an optional chain:

currentViewController?.present(viewController, animated: true) {
  self.didPresent()
}

When UIApplication.shared.keyWindow?.rootViewController is nil — which keyWindow returns readily in a multi-scene app, since it has been deprecated since iOS 13 — the whole statement is a no-op. Nothing is presented and, more importantly, nothing reports that: didPresent never runs, and neither SFSafariViewControllerDelegate nor UIAdaptivePresentationControllerDelegate can fire for a controller that was never presented.

The module is then holding currentWebBrowserSession != nil with vcDidPresent == false, and that is exactly the state its guard reads as "locked":

if vcDidPresent {
  self.currentWebBrowserSession = nil
  vcDidPresent = false
}
guard self.currentWebBrowserSession == nil else {
  promise.resolve(["type": "locked"])   // nothing presented, nothing thrown
  return
}

Nothing can clear it afterwards — the flag can only be set from the completion block that never ran, the delegates belong to an unpresented controller, and dismissBrowser() calls dismiss() on a controller that is not presented, which is a no-op. So every later openBrowserAsync resolves { type: 'locked' } until the app restarts, and because it resolves rather than throws it reaches users as "links silently stopped opening".

How

Two changes, both aimed at the same invariant: the module must never be left holding a session that nothing can release.

1. WebBrowserSession.open() reports failure when there is no presenter. guard let currentViewController else { onDismiss("cancel"); return }. onDismiss is what resolves the promise and clears the module's session, so the call now ends instead of leaking. Unwrapping once also removes the four ?/?? 0 fallbacks in the iPad popover block.

2. The module drops a session whose browser never reached the screen. A new isPresented (viewController.presentingViewController != nil) lets openBrowserAsync recognise a session that is not on screen and replace it, rather than answering locked forever.

(2) is deliberately additive rather than a rewrite of the vcDidPresent heuristic: it runs only in the else branch, so a browser that is currently up still answers exactly as before, and no working path changes behaviour.

Scope, stated plainly. The issue also suggests waiting on the presenter's transitionCoordinator so a call landing mid-dismissal succeeds instead of being dropped. That is not in this PR. It depends on UIKit presentation timing I could not reproduce on a device, and getting it wrong would trade a recoverable failure for a subtler one. What this PR guarantees is the part the issue title is about: the module can no longer be wedged for the lifetime of the process. A call that races a dismissal may still come back cancel or locked once — the next one works.

Test Plan

expo-web-browser ships no iOS unit tests, so this is a build-level check plus source reasoning.

Compiled against the real ExpoModulesCore through apps/minimal-tester with precompiled modules disabled, so the pod is built from source rather than a shipped xcframework:

EXPO_USE_PRECOMPILED_MODULES=0 pod install
xcodebuild -workspace minimaltester.xcworkspace -scheme ExpoWebBrowser \
  -destination 'generic/platform=iOS Simulator' -configuration Debug build

** BUILD SUCCEEDED **

Confirmed the edited files were the ones compiled, not a prebuilt binary — from the build log:

SwiftCompile normal arm64 Compiling WebAuthSession.swift, WebBrowserExceptions.swift,
  WebBrowserModule.swift, WebBrowserOptions.swift, WebBrowserSession.swift
  …/expo/packages/expo-web-browser/ios/WebBrowserModule.swift
  …/expo/packages/expo-web-browser/ios/WebBrowserSession.swift

Zero errors. (expo-web-browser is not a dependency of minimal-tester; I added it locally to get the pod into that workspace and reverted the change — the diff here does not touch any app.)

The macOS WebBrowserSession gets the matching isPresented (window?.isVisible == true) so the shared module compiles on that platform too.

Reviewer note on what is and is not proven: the no-presenter path is provable from the source — an optional chain on nil cannot call present, so didPresent cannot run. The recovery half rests on presentingViewController being nil for a controller that was never presented, which is documented UIKit behaviour. Neither claim needs the timing repro from the issue. I did not reproduce the mid-dismissal race on a device, and have not claimed to fix it.