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! :)
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.
It’s hard to say without more information.
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.
That’s not where I’d go to first. More on this below.
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:
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.