get current WiFi ssid

Took six days (for rejection).

I sent in the filled in request form on 7/31 received rejection on 8/4.

Tried to release a new version of my app that skips reading the SSID if iOS 9 is detected.

Got rejected due to my "What's New in This Version" information. I stated this version of the app would work under iOS 9.

You are not allowed to talked about unreleaed iOS versions. So it will be another 7 days before it can be reviewed for release.

Yes, rejection takes about a week. But seriously, will Apple kick a baby health monitor out of iOS 9? This has to melt event the coldest hearts. We keep our fingers crossed!

Are there any updates on this?

We use current SSID to provide good experience for configuring Wi-Fi for a screenless keyboardless consumer electronics device via device running its own Wi-Fi hotspot. We are trying to make as less awkward as possible and removing SSID detection seriously cripples our app's user experience. Current app version will stop working with device setup altogether.

We need, at least, to allow the app to see a subset/pattern of SSIDs or MAC address range by a particular manufacturer.

This is an absolutely terrible and ill-timed move by Apple. Seriously, no deprecation? Just yanking the API? Come on.

We currently use the SSID to differentiate between our user's home network and the network broadcast by our WiFi connected pellet grill. We perform very different actions based on this. We also use the SSID to inform our users what network they are actively trying to use because our grills are not compatible with 5.0 GHz networks broadcast by dual band routers and devices can sometimes switch networks underneath the user or switch off of the network being broadcast by our grills. We absolutely need to know if we need to revamp the code in our app to work around this before iOS 9 hits the market as we have a very small development team and need to allocate our resources appropriately. As it stands our users will have a very poor quality experience if they use iOS 9. Android is already a much better experience for our users because we can maintain socket connections in the background over long cooks, this may turn off many of our iOS users altogether.

Thanks for the update, eskimo.

I have a popular app that receives photos from wi-fi cameras / cards and I display the SSID in the statusbar so users know whether they're connected to the right device. So I'm sure there'll be a lot of sad pandas when iOS 9 hits. But oh well, best release yet. Take the good with the bad.

I absolutely see how this is a privacy concern, so I don't really expect this to get "fixed".

And please, no more settings and fine-grained control. Android is nothing to shoot for. 😉

Suggestion: If the user allows access to location services then let CNCopySupportedInterfaces() work as intended.

I'll file a Radar just to add a +1 to this issue.

Hi Eskimo,

Any updates on this? Here's another use case you can use.

We connect with WiFi cameras and one of them, that lets you go professional, requires a Wake-on-Lan packet to work. We don't keep the MAC address or use it for identification - we only need it so we can send a Wake-on-Lan magic packet, which as you know requires the MAC address. We already know the fixed IP address of the camera, which is connected via ad hoc wifi to the iPhone.

Any help or alternatives would be greatly appreciated.

Thanks Eskimo. I wanted to add my concerns and my use case for reading the connected SSID as well.

My app controls a connected-home hardware device that pairs with user's home network to let the user manage the device remotely. Knowing the SSID during this pairing process is crucial while we walk the user through the setup so we can ensure that they are connected to the correct device throughout the setup. There may be some workarounds that could potentially provide a stable way to detect and isolate these connection scenarios, but I have to restructure a lot of the setup process to even try it out. Until I am able to get a new solution in place, we have to recommend to our customers to not update to iOS 9.

I have a brilliant idea that will make history and change our ways of thinking...imagine designing an app that allows stoners to come together when they are high and find solutions about different phenomena and mysteries such as did we really land to the moon or how to stop global warming ...just texted this randomly to you...hope you smoke and see the light in it

Is the monitor already available to buy?

Did you receive a reply yet? Put mine in on the 25th August and so far nothing back. Sent a followup a few days ago to check I was actually in the system and received no reply.

Yes, you can buy the baby monitor. It's called Owlet. It's pretty cool technology. Just don't try to do the setup from an iOS 9 device. It fails. You can work around the problem with a web interface. But I wouldn't want that inelegant solution to our answer for the future.

I have not yet received a reply. That may be a good sign that I didn't get a rejection yet because they are waiting for additional information to be made public in the final release of Xcode 7/iOS 9? We will see soon.

Looks like it works again in iOS 9 GM 🙂

Thank-You eskimo

Yup, I can confirm the same. This is great, because this change broke every app that I have to connect to a camera via Wi-Fi. Ha....

Looks like it works again in iOS 9 GM

Indeed.

I also want to draw your attention to the big arse comment at the top of

<SystemConfiguration/CaptiveNetwork.h>

IMPORTANT This API is deprecated starting in iOS 9. For captive network applications, this has been completely replaced by

<NetworkExtension/NEHotspotHelper.h>

. For other applications, there is no direct replacement. Please file a bug describing your use of this API so that we can consider your requirements as this situation evolves.

If you do file a bug about this please send me, via email, your bug number. My email address is in my signature, below. For the next month or so I’m going to collect input on this issue.

You should, of course, feel free to continue discussing the issue here on DevForums.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

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

In response to my request for access to the Network Extension APIs, Apple Developer Technical Support let me know that both CNCopySupportedInterfaces and CNCopyCurrentNetworkInfo are re-enabled in the latest version of iOS9.

They also mentioned the URL to the documentation, which no longer shows CaptiveNetwork as being deprecated:

https://developer.apple.com/library/ios/documentation/SystemConfiguration/Reference/CaptiveNetworkRef/

This is really good news!

Look at the iOS 9 Documentation that is shipped with Xcode 7 GM: CaptiveNetwork API is "Deprecated in iOS 9.0." The public documentation will be updated as soon as Xcode 7 is released.

Hello Eskimo,

I am able to get the list of SSID using : [NEHotspotHelper supportedNetworkInterfaces];

BUT, now I want to block the CAN Popup also and allow it to be handled from my application itself. Prior to iOs9, I was able to do it using "CNMarkPortalOnline" but since it is depricated now, is there any other alternative method to do it using NEHotspotHelper ?

Kindly provide your reply at your earliest convenience.

Thanks.

Hello Eskimo,

I am able to get the list of SSID using : [NEHotspotHelper supportedNetworkInterfaces];

BUT, now I want to block the CAN Popup also and allow it to be handled from my application itself. Prior to iOs9, I was able to do it using "CNMarkPortalOnline" but since it is depricated now, is there any other alternative method to do it using NEHotspotHelper ?

Kindly provide your reply at your earliest convenience.

Thanks.

I have the same problem. My customers are unhappy

i'm coming in a bit late here. but even so ... with verry little activity on this thread in several weeks, it is still unclear whether or not being able to READ (only!) the SSID will be available in future without having to (attempt ... and likely be denied) be granted (how magnamamous!) a Hotspot helper entitlement.

nor is it clear if the functionality will, indeed, be gone from (some future?) IOS9.

my app can behave more efficiently (and the network it is on can be more efficient) if it is aware that it is on the "local" network v. accessing the same resources over some other, non-local network.

sure .. i could come up with a rather kludgey method of attempting to determine if i was on the "target" network or not ... but seriously!?!

readability of the current SSID is NOT a "security" issue.

I can see the privacy issues with reading SSIDs, however CNCopySupportedInterfaces() alone only returns a list of WiFi interfaces, which in most cases I assume will simply be @[@"en0"], e.i. the one WiFi network interface in the device. I can't see a privacy issue with that. So it's pobably been deprecated simply because all it's friends are?

My use case relates to determining the IP address of the WiFi interface on the local network and I was using CNCopySupportedInterfaces() to 'reliably' (there goes that part) know the name of the WiFi interface instead of assuming it's en0. But perhaps there is a recommended way for doing that without using the captive network work around? Or is assuming en0 considered future prove?