If you've started an autofill authn request and then subsequently start a modal authn request, it's possible for the internal state (used by the response processing system) to desync, and causing an assertion failure.
I suspect this is from ASAuthorizationController performing some sort of internal cancellation process that (now?) runs and triggers the sendError that resets the state to .idleafter the second, user-initiated request.
Might be specific to building when targeting iOS 18, as I didn't run into this targeting iOS 17 (and generational equivalents) on XCode 15.
FWIW, I had an attempt to adopt Swift 6 semantics around data race safety (a goal regardless) and the it-at-least-compiles version still had the issue. I think there's some additional subtlety around delegate methods that will need work.
Idea: do more with the controller passed in to the delegate methods, so that controller:didCompleteWithError: calls can be situationally ignored?
If you've started an autofill authn request and then subsequently start a modal authn request, it's possible for the internal state (used by the response processing system) to desync, and causing an assertion failure.
I suspect this is from ASAuthorizationController performing some sort of internal cancellation process that (now?) runs and triggers the
sendErrorthat resets the state to.idleafter the second, user-initiated request.Might be specific to building when targeting iOS 18, as I didn't run into this targeting iOS 17 (and generational equivalents) on XCode 15.
FWIW, I had an attempt to adopt Swift 6 semantics around data race safety (a goal regardless) and the it-at-least-compiles version still had the issue. I think there's some additional subtlety around delegate methods that will need work.
Idea: do more with the
controllerpassed in to the delegate methods, so thatcontroller:didCompleteWithError:calls can be situationally ignored?