get current WiFi ssid

I'm in the same boat. Just found that out today. This *****

I have a same problem.

I can't get ssid and BSSID.

Well since the old method doesn't work at all and the new method doesn't seem to work I would say it's a bug that we should all report to apple

Ah, good to know that there is a new API, so it's most likely a bug.

With the old deprecated API, I was already afraid they blocked access to the SSID due to privacy concerns.

Will report a bug too.

I guess Apple is focusing on the hotspot issue. While I still think it is a bug it seems that if you want to use the newer methods you have to register as hotspot helper app. I think most of us that were using the CaptiveNetwork features to get the SSID for the current network were using it as a side effect that apple didn't plan for and didn't know people were using that way. Hopefully we can still use it in iOS 9.

#import <NetworkExtension/NetworkExtension.h>

NSArray * networkInterfaces = [NEHotspotHelper supportedNetworkInterfaces];
NSLog(@"Networks %@",networkInterfaces);

Seeing same issue

file bug report 21964534

This is a follow-up to Bug ID# 21964534.

Engineering has determined that this issue behaves as intended based on the following information:

Please use the NEHotspotHelper API instead.

We consider this issue closed.

But is this method is working and give the SSID?

If NEHotspothelper gave a null result ...

First of all, thanks for all your feedback about this issue (both formal, via Radar, and informal, via DevForums, email, and so on).

Second, be aware that this is not a accidental change (r. 15225882): rather, Apple has serious concerns about the privacy implications of

CNCopySupportedInterfaces

However, it's now clear that lots of developers are using

CNCopySupportedInterfaces

Regardless of how this issue is resolved, I've made it clear that this issue needs to be covered in the release notes (r. 22068424).

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

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

My request to use the Network Extension framework has been denied (626193135).

My already released app will crash when my users upgrade to iOS 9. This will make for hundreds of unhappy customers.

What is an alternative way to read the current WiFi SSID if I am not allowed to use the Network Extension framework?

Hi Turbo3, were you given a reason?

adpward wrote:

were you given a reason?

I can't speak to Turbo3's specific case but, in general, the NEHotspotHelper mechanism is designed for folks doing captive network management apps. If you're not creating a captive network management app, it's not appropriate to use NEHotspotHelper.

Turbo3 wrote:

My already released app will crash when my users upgrade to iOS 9. This will make for hundreds of unhappy customers.

Yeah, that's obviously not good, and we're taking this issue very seriously. Alas, I can't offer further insight into this issue at this time. I will, however, post updates to this thread as things develop.

What is an alternative way to read the current WiFi SSID if I am not allowed to use the Network Extension framework?

Just to satisfy my own curiosity, what are you using the current Wi-Fi SSID for?

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

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

Can't speak for Turbo, but I've had a lot of experience with Wi-Fi and one of the most common reasons many of our customers want access to it is as an extra security vector. For example, banks perform numerous checks to try to verify the user and verifying they are connecting from a previously known BSSID/SSID combo is commonly used for that type of security weighting.

Thanks, Quinn. Not the answer we're hoping for, but it helps us speculate about the future. I filed Radar 22147499.

I'd also like to point out that deprecation means an API is unchanged for now, but will go away in the future. It seems to me that you might as well remove CNCopySupportedInterfaces() altogether if it's always going to return NULL, rather than mark it deprecated.

Thank you for a very detailed answer. It is appreciated.

Here is the reason they gave for not approving my request.

"We’re writing to inform you that we’re not able to approve your request. Use of the NEHotspotHelper API is not intended for the use you’re requesting."

Turbo, in my experience, I have found that it is useful to pick up the phone and speak with someone at Apple. If nothing else, you might get some advice allowing you to adapt your app so that it does conform?

eskimo,

Thanks for taking the lead on this issue.

My app communicates with the Nissan Leaf electric vehicle by using a WiFi OBDII adapter plugged into the Leaf's OBDII port. This makes a local "hotspot" that my app can communicate with after the user has selected the OBDII WiFi network.

The first thing a user of my app does after install is to register the WiFi OBDII adatper's SSID with the app. The user starts my app and confirms on a settings screen that the current WiFi SSID is the WiFi OBDII adapter's SSID. Now my app knows (but not in iOS 9!) by reading the current WiFi SSID if the iOS device is connected to the Leaf. If it is my app will start collecting data to display to the user. If the SSID is not the registered one then my app goes into an offline mode and just lets the user review previously saved data. If will also disable running in the background if the SSID does not match. While in offline mode the app polls the current SSID to see if it ever matches the registered one. If it does match, a connection is established and data is collected.

The temporary fix I am looking at, which I don't think is very good, is to just assume that the current WiFi SSID is always the OBDII adapter's SSID. This is ok if the WiFi network is actually the OBDII adapter network. But in the case that it is not ,the app will try to communicate with whatever network is selected or even when none is selected. It will do this over and over again wasting power in a futile attempt to communicate with the Leaf.

My app can also run in the background and the app uses the current SSID to know when the user has moved out of range of the WiFi OBDII adapter in which case it will stop running in the background. This will not happen with this fix and if the user does not go into the app settings and disable background operation the battery will be drained unnecessarily making for an unhappy customer when their battery goes dead.

To me readng the current WiFi SSID is no different then reading the screen size or iOS version number. It tells the app critical information about the environment.

It appears your developers think the WiFi network is only used to connect to the internet so no one should care about the SSID. That is not the case.

I'd like to add another point to the discussion.

We're using the current SSID to display it to the user in case of an error (the "device not found" kind of error). This has saved hundreds of frustrating debugging hours for our users, because you just *see* in the error message, that you're not connected to the WiFi-AP, that you think you are. "Ah, of course I'm unable to find the device on my home network, my iPhone is still connected to my neighbors AP". Or the restricted guest WiFi, or your colleagues AP in the office, or the open AP of the pub downstairs, you name it ...

You're about to remove a really helpful feature.

Thanks for having a second look on the entire issue!

It appears that a lot of users use the CaptiveNetwork functionality for retrieving information about the current WiFi network. I am one of those developers.

My app displays the network name / SSID to the user after a task has completed. While the current version doesn't really require the network name in order to function, an upcoming update including new features does. The update is already in the testing-phase, but it appears that we're going to have to push the update further away due to the deprecated functionality. 😟

I have requested the NEHotspotHelper entitlements, but I'm still waiting on a positive reply.

Apple, I really hope that you understand how many developers need to be able to retrieve the current WiFi network information for their app to be functional.

I really hope that in the next iOS9 beta the deprecated functionality will be re-introduced. A new simplified API that allows us to get the information we need would work too.

I did not mention it but my app also displays for a few seconds the current WiFi SSID on startup. I can not count the number of times I have gotten in my Leaf, started the app and found I am still connected to my home network not the Leaf OBDII WiFi network. I am sure all my users have done the same and without seeing the message about the current SSID they would not be prompted to go back and select the OBDII WiFi network. Of course if they were just reviewing data in their house they would know to ignor the incorrect network messages that flashes up.

So how can we get this changed so we can still get the current WIFI network name? For those apps that use it, it's an extremely useful feature and for some of us it's necessary. I've already filed a bug report, but I have doubts it will get looked at for a few years like all the other bugs.

eskimo --

I'll file a radar for this too, but I wanted to share my use for CaptiveNetwork: We have a custom device that acts as a WiFi Access Point and we're using the first 24 bits of the BSSID (Organization Unique Identifier) as a verification check that the user is connected to an expected WiFi network. It allows us to be more specific in suggesting trouble-shooting steps (i.e. "Please check that you're connected to the correct WiFi network") rather than just reporting a generic TCP-level connection failure. For our case, even if the user had to confirm they wanted to share that info, that would work with our flow and still provide value.

I also got my request of Hotspot helper entitlement rejected with the reason:

"We’re writing to inform you that we’re not able to approve your request. Use of the NEHotspotHelper API is not intended for the use you’re requesting."

I use SSID for my app to identify:

• whether the user is connecting into his local network or over cloud.
• My app talks to a hardware which has some features restricted depending on local or cloud connection.
• And if I know the SSID I can directly connect to the hardware. Otherwise first I need to try connecing over the wifi and if it fails then I need to connect over cloud which causes the connection time increase if user is not there in the same network where the hardware is connected to.
• Also at the time of some connection isues we instruct the user that 'his hardware is connected to "SSID" and the iPhone is connected to "SSID". Please make sure both iPhone and hardware in same network'.

Hi Eskimo,

This email address: - networkextension@apple.com as listed in the following document "717_whats_new_in_network_extension_and_vpn.pdf" bounces back. Has the email address changed for these requests?