GIDSignInCompletion block not called when ASWebAuthenticationSession is interrupted by device locking

[tanmayj1998]

Describe the bug
When using Google Sign-In SDK on iOS, if the user locks their device or the app transitions to background during the authentication flow (while ASWebAuthenticationSession is active), the GIDSignInCompletion block is never called. This leaves the app in an indefinite loading/blocked state with no way to detect that the session was interrupted or cancelled by the OS.

To Reproduce

1. Initiate Google Sign-In flow in an iOS app
2. Wait for the ASWebAuthenticationSession system prompt to appear
3. Lock the device before completing authentication
4. Unlock the device and return to the app
5. Observe that the GIDSignInCompletion block is never called (no success, no error, no cancellation callback) and the ASWebAuthenticationSession alert is dismissed.

Expected behavior
The GIDSignInCompletion block should be invoked with either:

1. A cancellation result/error indicating the session was interrupted, OR
2. A property that allows detection of this interrupted state

This would allow the host app to reset its UI state (e.g., hide loading indicators, re-enable the sign-in button).

Screenshots
N/A.

Environment

• Device: iPhone (various models)
• OS: iOS (tested on iOS26, iOS18)
• SDK: Google Sign-In SDK for iOS

Additional context
This issue stems from how iOS handles ASWebAuthenticationSession interruptions. When the device is locked or the app goes to background, iOS may dismiss the authentication prompt without reliably delivering a cancellation callback to the SDK.
A similar issue has been reported by multiple users in the AppAuth-iOS repository: openid/AppAuth-iOS#468. A fix for the SDK is observing the app's background/foreground state transitions and invoking the completion block if a previously active session was found. We recommend Google Sign-In SDK implement a similar mechanism to detect interrupted sessions and return an appropriate callback to the host application.

[brnnmrls]

Thanks for reporting this issue! I was able to reproduce the behavior you described on our end.

Unfortunately, we're not able to prioritize a fix for this issue at this time, but I've kept a note of this. However, we would be happy to review and accept a PR from the community to address this. The suggestion to observe app background/foreground state transitions, similar to the approach taken in AppAuth-iOS (as mentioned in openid/AppAuth-iOS#468), seems like a promising direction.

In the meantime, have you found any potential workarounds to mitigate this issue in your app?

We appreciate your understanding and any potential contributions!