We have been searching for almost one year for answers as to why wkWebView using an Entitled Domain will allow Autofill with KeyChain to fill credentials, but will not trigger Autofill to store/save them. In other words, if users have previously stored credentials in Safari while visiting domain X, subsequent visited to wkWebView with entitled domain X will allow use of those credentials in wkWebView through the Autofill/Keychain dialogue. However, users cannot save/store credentials within wkWebView in Trusted domain X because the save dialogue is never triggered.

In developing OPENID / OAuth type web authentication for native apps, I am looking for confirmation that Apple iOS supports Save Password dialogue on the sign-in that occurs in the browser within the ASWebAuthenticationSession webview. Noting that both ASWebAuthentication Session and SFSafariViewController support isolated browser privacy with regards to the app, it should not (theoretically) necessitate domain trust between the App and the domain of the current AS/SF webview as it once did with wkWebViews. Can anyone confirm that Keychain's Save Password dialogue DOES fire on either/both ASWebAuthenticationSession and SFSafariViewController?

Can a wkWebView login form, with proper domain associations, be used with keychain? Moreover, I have discovered that it can use (domain associated) entries, but the save password dialogue does not seem to trigger for new entries. Ideas?

The Save Password / KeyChain dialogue is not presented upon entry of credentials in a wkWebView authorization view. While the domain is properly entitled and the KeyChain auto-fill does appear to FILL credentials that may already exist from Safari, the save user/password dialogue never displays on a change or if no prior credentials exist in Safari. Is this expected behavior? Clearly the entitlement of the domain allows the auto-fill to function properly.