On iOS 13.1, CNCopyCurrentNetworkInfo occasionally doesn't work.

Altough we are using NEHotspotConfiguration API to configure the current Wi-Fi network, occasionally CNCopyCurrentNetworkInfo returns NULL. The only way to recover was rebooting the phone (I haven't tried resetting the network settings as was suggested else where). Regardless ,this sounds like a bug in the API and I was wondering if others see the same problem and/or if it's a known issue and is getting addressed.

Thanks!

I’ve seen reports from a number of different developers about weird problems with

CNCopyCurrentNetworkInfo
. Some of these were reported as fixed in 13.1, but that’s clearly not the case here. I haven’t managed to drive any of the other reports to a conclusion yet.

Still, I agree with your conclusion that having a restart fixes the problem is strong evidence that you’re hitting a bug. Please file a bug report about this, then post your bug number here, just for the record.

When crafting your bug report:

  1. Install the Wi-Fi for iOS profile from our Bug Reporting > Profiles and Logs page.

  2. Reproduce the problem.

  3. Make a note of the time.

  4. Trigger a sysdiagnose log.

  5. When that’s done, attach the log and your timestamp from step 3, to your bug report.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks! I submitted the feedback (FB7339809) with WiFi and device logs. Hope it helps

I'm having the same issue as Glauco, sent in my bug report here FB7348292


https://feedbackassistant.apple.com/feedback/7348292

I just had the same issue this morning using our app and my personal phone (iPhone 11 Pro) as some of our beta testers reported it.

I attached a debugger to my phone and confirmed that CNCopyCurrentNetworkInfo returns nil even if we have appopriate permissions due to new iOS 13 privacy enforcements. I confirm that a reboot fixed the issue.


Do we have any idea if iOS 13.2 resolves this ? I did not installed a beta yet.

Once iOS 13 went GM, I ended up with a bunch of DTS tech support incidents about this. It’s hard to be 100% sure because there are a lot of moving parts here, but at least one bug that can cause this issue (r. 55526060) is supposed to be fixed in the just-released 13.2b2 (17B5068e).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,

iOS 13.2 has been released. Any update on this? Is it working as expected or do we need to make something on our part?


Thank You very much.

Is it working as expected … ?

I think that’s for you to tell us, right? (-:

As I wrote in my 15 Oct post, 13.2 contains at least one fix for this issue. Whether that’s the only fix required is uncertain. If you continue to have this problem on 13.2, you should file your own bug about it per my 30 Sep post (or, if you’ve already filed a bug, update it with your latest test results).

Oh, one slight amendment to that post: In addition to installing the Wi-Fi for iOS profile, you should also install the Location Services for iOS profile. If there’s one concrete thing we’ve learnt in this process, is that these bugs live at the boundary between Wi-Fi and location.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Ok so I confirm that the issue is still present in iOS 13.2.

It happens less often because I did not reproduce the bug myself on my debug devices, however some of our clients using iOS 13.2 still see a specific screen we made in our app that pops up whenever the returned SSID is nil (and again, even though we are appropriate permissions).

Unfortunately, I don't have those profiles installed so I'll install those right now and if the issue happens, I'll file a sysdiagnose.


Thanks for keeping us informed!

We are also having customers report issues around this area in iOS 13.2.


We're not using NEHotspotConfiguration, but are instead getting location permission in order to read the SSID.


We were able to replicate the issue on one device when it was running iOS 13.1.3 (17A878), however it appeared to fix itself after the device had its "Location & Privacy" reset via Settings.app

Our users have the same problem, but restarting the phone has not been resolved. How can I fix this?

Same here as reported above. Can confirm it still happens in app linked against 13.2 SDK (Xcode 11.2 (11B52)). Randomly happens on some phones and reboot is required to temporarily work around it. After reboot, app works normally for some time then it starts failing to get SSID via CNCopyCurrentNetworkInfo().


if let interfaceInfo = CNCopyCurrentNetworkInfo(interface as! CFString) as NSDictionary? {
    ssid = interfaceInfo[kCNNetworkInfoKeySSID as String] as? String
} else {
    print("Getting InterfaceInfo (is nil) failed for \(interface)")
}


Also turning location access permissions to Ask Next Time in Settings.app and then restarting the app doesn't fix it either. Setting to Never and restarting app doesn't fix it either. Reboot is only way (I've found) to make it work again (temporarily).

Can confirm it still happens in app linked against 13.2 SDK (Xcode 11.2 (11B52)).

Hmmm, it’s not the SDK linkage that the issue here, but the OS version.

If you continue to see problems when running on iOS 13.2 (and that seems likely given the reports from others on this thread), please see me 31 Oct post.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I confirm that some users are occasionally reporting this to me too. One has fixed by reinstalling. Another one by rebooting. Experience is definitely crazy and randomic.


Funny enough, I had just started charging people for an app feature based on that, and Apple decides to break it. Room for bad ratings and more time wasted to update the FAQ on my website. The time and patience we developers wasted on iOS 13 bugs -which remain unfixed for months- have become very, very hard to calculate.


I'll file the umpteenth, useless report anyway. Useless because I got no fix nor relevant help from Apple about any of my multiple reports. Instead, the overall developer community helped a lot during this disgraceful 2019.


Somebody may not like the rant but man, this is a job for many of us and you're making it a constant challenge. The text view bug in Xcode is like... gosh, I won't even start with what it took me to sort out my Catalina/Xcode work environment.


Apple must stop rushing all these awful releases. The quality bar has gotten so unbearably low with iOS 13 and Catalina. Come on, you used to be much better than this.

Our customers report this issue in 13.2 (up to 13.2.2 still exists).

Because in their devices, there are no such iOS profiles installed, so that they/we cannot report the bug with the logs.

However, getting the current wifi SSID is a very key feature for some apps.

So I hope you and your teams can fix this issue as soon as possible.

Thanks a lot.

Note, rebooting the device did resolve this issue temporarily.

It is even worse, as it affects apps that don't use the WiFi interface on it's own.


I have an app which uses location service in background mode which used to run for days without trouble pre 13.2.


Now it terminates after a variable number of hours. Reason I figured is the WiFi interface implicitly used by the location service.

I get about every second the message: "

nehelper sent invalid result code [1] for Wi-Fi information request" in the console log.


Using Instruments I noticed that those calls to CNCopyCurrentNetworkInfo have a memory leak - with foreseeable consequences for the app.


Switching off WiFi on the device settings solved that particular problem, though turning off WFi seems to be a bit radical solution 😉


Is there anyway to use location services without it using WiFi ?

On iOS 13.1, CNCopyCurrentNetworkInfo occasionally doesn't work.
 
 
Q