FWIW, broken since iOS13. For details check here.. Feedback reported as FB9856371.

FWIW, broken since iOS13: https://stackoverflow.com/a/70823487/415982 ­– FB9856371

In the league of 100ms.

Unfortunately I'm not in possession of that multicast entitlement. In fact, until yesterday I did not know that it existed in the first place. I have now requested it and hope that I will receive it very soon (can I do anything to speed up this process? Some of my clients have requested it for their apps as well yesterday). Assuming this is the culprit, I still don't understand why this moved from optional to mandatory ­just now – the notes seem to talk about iOS14 and yet this policy seems to have been only implemented as of iOS16.

Are there any facilities using the new concurrency primitives to improve this syntax?

FWIW, I could work around my issue of the WiFi adapter handing out a route by (ab)using the TCP multipath configuration ˋinteractiveˋ. That way it looks like every request is sent out both via WiFi and Cellular and since there is never any reply coming in via WiFi, Cellular always wins. Unless we get programmatic ability to adjust the IP configuration, this is the best thing to solve my problem.

Should be automatically present in AppStoreConnect. I guess it's still broken though for those who participated on the beta. For me, it still says "Xcode cloud beta" and there is nothing else on the page.

Thanks, interesting, initWithSSIDPrefix is news to me, that's pretty helpful. Still remaining is the problem w/ DHCP handing out a "router" IP, which it shouldn't as this confuses iOS. I can definitely reach the device of the WiFi link without HTTP. The way it works is that I have to broadcast via UDP to find out who's listening on the other side and also to find out the right interface. Then, I open a TCP socket, configure it via IP_BOUND_IF to use the appropriate interface and continue via streams with CFStreamCreatePairWithSocket.

NEHotspotConfiguration has two problems: As far as I can see, the API doesn't allow me to intercept or override the DHCP configuration that gets sent from the WiFi access point, so how could I configure the router IP programmatically? I don't know the SSID in advance. Usually those WiFi diagnostic adapters insert their (varying) serial number into the SSID, and ­– sometimes ­– the password. I'm not sure I understand your second paragraph. Do you want to say that trying to access an internet resource via the WiFi link would tell the system that it has no WiFi connection? If so, that doesn't happen ­– at least not with URLSession, since I'm already doing that. I try to access resources, which ­­– due to the WIFi link being used ­– all fail.

FWIW, most of this has been repaired since macOS 12.3.

Thanks for responding. Here are more details on my situation. I'm starting my app and everything is OK so far. Depending on where I am either my local WiFi is being used or cellular. Now I'm attaching the diagnostic WiFi adapter to the car, use Settings -> WiFi to connect to its network and now the following happens: The iPhone gets an IP, a subnet mask, and ­– sadly ­– a router, e.g. 192.168.16.103 / 255.255.255.0 / 192.168.16.254. Interestingly, for a short time, iOS seems to detect that with these settings, there is no internet available, hence it ­– sometimes ­– shows the [No Internet Connectivity] subtitle. Despite all that, the path stays the same as NWPathMonitor still reports 2022-06-03 08:51:42.503 [none:ObservableReachability] <2> (D) Network Path now satisfied (Path is satisfied), interface: en0, ipv4, dns So at this point of time, I have no internet connectivity. Now if I manually go into the WiFi settings, change it to 'custom' and set 192.168.16.103 / 255.255.255.0 / (empty router), everything immediately starts to work. In the statusbar, there is 'LTE' and I can connect both to the 192.168.16.x and to the internet. Now really I can't put the burden to my end users to go in their network settings and do the same I did. That's why I'm begging for a better solution.

I'd like to know whether anything has changed regarding the original poster's situation. While using NSURLSession on a cellular network only may not be a preferred option in iOS, in my case it's a necessity. I'm using an off-the-shelf WiFi-to-Automotive-Ethernet adapter to connect to a car's diagnostic services. The adapter hands out an 192.168.x.y address via DHCP. Unfortunately iOS does not recognize that there is no internet connectivity over this adapter, hence all my URLRequests fail immediately. Coming back to the Network preflight check… how would I use that in practice? E.g., it's good that I can detect the outgoing route, but what can I do if that's not the route I want to use? Is there anything else I can do to fix this issue?

Xcode 13.3 is very flakey here. Crashes on almost every 2nd start of a build: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1908999b8 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1908cceb0 pthread_kill + 288 2 libsystem_c.dylib 0x19080a314 abort + 164 3 libswiftCore.dylib 0x19dc86830 swift::fatalError(unsigned int, char const*, ...) + 60 4 libswiftCore.dylib 0x19dc86988 swift::swift_abortRetainUnowned(void const*) + 36 5 libswiftCore.dylib 0x19dcc9598 swift_unknownObjectUnownedLoadStrong + 76 6 IDESwiftPackageCore 0x2c088fc54 specialized IDESwiftPackageBuildable.prebuildOperations(forBuildCommand:parameters:logRecorder:) + 100 7 IDESwiftPackageCore 0x2c0885e40 @objc IDESwiftPackageBuildable.prebuildOperations(forBuildCommand:parameters:logRecorder:) + 88 8 IDEFoundation 0x101367548 -[IDEBuildOperation start] + 4300 9 Foundation 0x19188c914 __NSThreadPerformPerform + 212

I need that as well, but for a wired ethernet interface. It‘s quite a burden to require the user to set a static IP and netmask before my app can talk to the device I need to talk to. Should I just file a feedback request via the reporter?

I'd love to know this as well – did you find a solution yet?