We have an old iOS app and an old camera that connects using Wi-Fi either using an access point or Ad Hoc network, e.g., iPhone/iPad connects to the camera's Wi-Fi directly...
How it works (old legacy app/system, which cannot be redesigned):
- Camera is configured to Ad Hoc Wi-Fi network (insecure TCP).
- iPhone connects to this insecure Wi-Fi.
- Camera uses Bonjour service to broadcast its IP address.
- App reads in IP address and begin to send messages to the camera using NSMutableURLRequest, etc.
All this works fine for iOS 17. But in iOS 18 step 4 stopped working. App simply doesn't get any responses!
We believe we have configured ATS properly (App Store version):
In panic we have also tried this in Test Flight version:
The latter actually seemed to make a difference when running the app on macOS Apple Silicon. But on iOS it didn't seem to make any difference.
Occasionally, I was lucky to get connection on on iPhone 16 Pro with iOS 18. But for the 'many' iPads I have tried I couldn't.
I also tried to install CFNetwork profile and look at the logs but I believe I just got timeout on the requests.
Questions:
- Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't
- Do we configure ATS correctly for this scenario?
- What should I look for in the Console log when CFNetwork profile is installed?
- Should I file a TSI?
Thanks! :)
Camera is configured to Ad Hoc Wi-Fi network (insecure TCP).
I try to avoid the term ad hoc when it comes to Wi-Fi, because different folks use it to mean different things. I talk about this more in Wi-Fi Fundamentals.
Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't
It’s hard to say without more information.
Do we configure ATS correctly for this scenario?
No. You should only need NSAllowsLocalNetworking.
I’ll note that, if ATS were blocking this request, it would fail promptly and with a helpful log message. Given the symptoms you’ve described, I very much doubt this is an ATS issue.
What should I look for in the Console log when CFNetwork profile is installed?
That’s not where I’d go to first. More on this below.
Should I file a TSI?
No. Well, TSIs technically don’t exist any more [1]. Instead, DTS spends a lot more time on the forums these days, so everyone can benefit from our work.
Reading your post it wasn’t clear what the actual failure mode is. You wrote:
App simply doesn't get any responses!
What does that mean exactly? URLSession requests have a default timeout so, if you get no response from the server, you should expect to time out within a minute or two [2]. Is that what happens in your case?
Beyond that, what I’d do next is to look at what’s happening on the ‘wire’. It’s quite possible that the device is sending a request but your accessory is not responding. Use an RVI packet trace for this.
That’ll also let you compare the iOS 17 and 18 behaviour.
ps I have a bunch of info about working with accessories in my Extra-ordinary Networking > Working with a Wi-Fi Accessory post. None of it directly relevant to your current issue, but I recommend that you keep it in mind.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Rather, we have DTS code-level support request.
[2] The exact timeout depends on exactly what’s failing on the wire.
