Thanks for the reply! Just to clarify, the issue occurs while the app is actively being used — it’s not in the when the problem happens. I only mentioned and other system conditions as speculative possibilities, not confirmed behavior. Also, the error I’m receiving is code 7, which I understand maps to NEHotspotConfigurationError.userDenied. According to the documentation, this should only occur if the user explicitly cancels the system Wi-Fi join . However, based on logs collected from multiple affected users, there seem to be two possible scenarios: • In some cases, the system never appears, and the error is returned without any user interaction. • In other cases, the user taps “Join” on the , but the system still returns userDenied, which contradicts the behavior. Unfortunately, I haven’t been able to reproduce this issue consistently on my end — it mostly shows up in the field and only comes to light after reviewing logs from user . Have you seen this happen before? Is it possible that under certain system-level conditions (e.g. unstable network state, permissions edge case, or internal connection rejection), iOS might still return userDenied even when the user confirms? Appreciate any insights — thanks again!

Thanks for the follow-up! Yes, it’s definitely strange. We’ve also seen some cases where .internal (8) errors occur, but what stands out is that most of the reports are actually .userDenied (7), which is why it caught our attention. Interestingly, I made a change in the code recently to use the ssidPrefix initializer when available: var config = NEHotspotConfiguration(ssid: ssid, passphrase: passphrase, isWEP: false) if #available(iOS 13.0, *) { config = NEHotspotConfiguration(ssidPrefix: ssid, passphrase: passphrase, isWEP: false) } config.joinOnce = false let timeStart = Date().stampSec After this change, we’ve started seeing a noticeable increase in . (11) errors instead — which again, is hard to down. As for your question: the .userDenied issue doesn’t seem to “stick.” Most users report that retrying the connection often works fine afterward. So it’s transient, but still confusing — especially when it gives the impression the user canceled something they didn’t. Let me know if you’ve seen any similar behavior with . or ssidPrefix, and thanks again for all the insight!