We can add reproduction data from another app, HTN, on iPhone 17e (iPhone18,5), iOS 27.0.1 (24A446). The domain-bound symptom matches this thread, but our unbound-message results differ, so we are not assuming the same root cause. Environment: Flutter 3.35.6 (engine d2913632a4), Dart 3.9.2, Xcode 26.5 (17F42). App version 2.2.6; the instrumented local builds are development-signed profile builds. The user also reports that an older published version, previously working, now fails on the same phone; we have not established that older build number or tested a different iOS version/device. Domain-bound case Our SMS has this format (123456 is a dummy example, not a real login code): codice di accesso: 123456 @e-htn.it #123456The installed app contains application-identifier Q9SKMCAYZY.it.e-htn.htnsalute and webcredentials:e-htn.it. Both origin AASA URLs return 200 without redirects: https://e-htn.it/.well-known/apple-app-site-association https://www.e-htn.it/.well-known/apple-app-site-association Both corresponding Apple CDN URLs return 200, Content-Type: application/json and include Q9SKMCAYZY.it.e-htn.htnsalute in webcredentials.apps; all four response bodies match. One qualification: the captured origin headers did not contain Content-Type, while the CDN serves application/json. We have not independently verified the phone's internal swcd approval record. The focused native Flutter input has textContentType = one-time-code, first responder true, attached window, nonempty frame, secure entry false, and keyboard type default. Selected Console lines from 4 November 2026, UTC+01:00 (manually transcribed, with the system-masked hashes further redacted; not a raw logarchive): 18:03:37.181148 kbd Current verification code is domain-bound to [redacted]. 18:03:37.182122 kbd Domain-bound verification code is NOT valid for app [redacted]. 18:03:53.545938 kbd Current verification code is domain-bound to [redacted]. 18:03:53.552573 kbd Domain-bound verification code is NOT valid for app [redacted].Unbound SMS and same-app native comparison We then sent fresh, six-digit dummy codes from another phone without the @domain #code line. The user confirmed that the initial unbound message is recognized in Messages: its code is underlined and tapping offers Copy Code. It was still not suggested in the app. To compare inputs, local build 2.2.6 (13) opens an isolated diagnostic screen, without starting the normal Dart login/Health-sync flow. It does not submit the dummy codes to a backend. Only one test input is mounted at a time. We tested both: Flutter TextField: oneTimeCode hint, default system keyboard, secure false, autocorrect true. UIKit UITextField: .oneTimeCode, .default keyboard, secure false, autocorrection/spellchecking .default. Important scope limitation: the UITextField is hosted in a Flutter platform view in the SAME app/bundle, not a separately built all-native app. .default is not forced .yes. The user reports no suggestion in either tested case. We did not separately complete the two OFF variants in this diagnostic screen. The focused UIKit field and its UIFieldEditor were confirmed on-device as first responders, attached to a window, nonempty frame, one-time-code content type, keyboard type 0, secure false, autocorrection type 0 and spellchecking type 0. The Flutter ON case was subsequently confirmed with the same relevant traits. The native negative observation is persisted as a boolean; the Flutter ON negative observation is user-reported. We did not capture a corresponding system candidate result for the Flutter ON case. In the native test session, kbd logged: 18:39:00.530838 Notifying observer [redacted] of one-time code changes 18:39:00.566670 Returning 0 available one-time codes 18:40:11.742700 One Time Code field has been entered. 18:40:11.765311 Returning 0 available one-time codes 18:40:11.857155 One Time Code field has been entered. 18:40:11.866280 Returning 0 available one-time codesPassword/passkey AutoFill is enabled in Settings. The user sees the native Apple keyboard. No cross-device/iOS-version comparison or controlled Safari/WKWebView test has been performed for our app, and we have not collected a sysdiagnose yet. Therefore, unlike the unbound workaround described above, simply dropping the domain line has NOT been demonstrated to resolve our case. Could Apple advise which targeted logging/profile would help explain the zero candidates and distinguish association state from another eligibility issue? Is there a changed requirement for app-associated domain-bound OTPs on iOS 27? Also, has anyone tested ASWebAuthenticationSession or SFSafariViewController as a controlled browser-based comparison/potential workaround, rather than WKWebView? We would test a genuine HTTPS authentication flow with a matching SMS/page domain and preserve the normal OAuth callback/PKCE, not attempt to extract an OTP from Safari. No real OTPs, credentials, phone numbers or patient data are included here. We can provide additional sanitized input-trait snapshots and reproduction configuration if useful.