NEHotspotConfiguration apply returns userDenied error without user interaction

I’m encountering an unexpected issue while using NEHotspotConfigurationManager.shared.apply(...) to connect to a Wi-Fi network. Specifically, I’m receiving a userDenied error, even though the user did not interact with any system prompt.

Here’s a version of the code I’m using:

let config = NEHotspotConfiguration(ssid: ssid, passphrase: passphrase, isWEP: false)
// config.joinOnce = true
NEHotspotConfigurationManager.shared.apply(config) { error in
if let err = error {
let nsErr = err as NSError
mlog("err.code:\(nsErr.code)")
if nsErr.code == NEHotspotConfigurationError.alreadyAssociated.rawValue {
self.findWiFiListAndConnect(ssid, passphrase, overtimeSec, timeStart)
} else {
self.cmdDelegateQueue.async {
self.delegate?.wifiClose(nsErr.code)
}
}
}
}

The error returned is:

wifiClose status: 7

Which corresponds to NEHotspotConfigurationError.userDenied. According to the official Apple documentation, this error should only occur when the user explicitly cancels the system dialog. However, in my case: • No system dialog appears. • The user does nothing, yet the error is still returned. • This issue does not happen every time, but it has been observed across multiple devices.

Additional info: • iOS version: 18.5 • Device model: iPhone • joinOnce is not set (defaults to false) • Existing configuration is removed using removeConfiguration(...) before applying

Is it possible that under certain system states (e.g. backgrounded, network restrictions, or app permissions), iOS silently fails without showing the prompt?

Has anyone else encountered this issue, or does anyone know what could cause this behavior?

Any help is greatly appreciated!

Answered by DTS Engineer in 848236022

Error .unknown (11) is weird. I’m not sure why we have that and .internal (8).

Problems like this are definitely bugworthy, but there’s a wrinkle. For the bug to be actionable we really need a sysdiagnose log, and that’s hard to get for such transient errors.

If you have a set of reasonably technical beta testers then you could enlist their support in the investigation. I offer some suggestions for how to do that in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Written by Kaaaaai in 786689021
Is it possible that under certain system states … iOS silently fails without showing the prompt?

I expect so. Certainly, trying to apply a Wi-Fi configuration when your app is in the background isn’t going to end well.

Can you reproduce this? Or are you debugging problems based on reports from the field?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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!

Sorry I didn’t reply sooner. I missed your earlier 12 Jun response.

Written by Kaaaaai in 843164022
Have you seen this happen before?

No. I have seen a bunch of folks hitting weird NEHotspotConfigurationManager errors, but those are usually .internal (8). I’ve never seen reports of unexplained .userDenied (7) errors.

That doesn’t mean I don’t believe you though; this stuff is complex enough that pretty much anything can happen.

If a user experiences this problem, does it ‘stick’? That is, if they see it, do they continue to see it? Or does the user see it once and then, when they retry, things work?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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!

Error .unknown (11) is weird. I’m not sure why we have that and .internal (8).

Problems like this are definitely bugworthy, but there’s a wrinkle. For the bug to be actionable we really need a sysdiagnose log, and that’s hard to get for such transient errors.

If you have a set of reasonably technical beta testers then you could enlist their support in the investigation. I offer some suggestions for how to do that in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

NEHotspotConfiguration apply returns userDenied error without user interaction
 
 
Q