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?

For me neither… could it perhaps just be broken in modern iOS versions? When did you see it last time?

Did you find a method in the meantime? I don't care about app-store-safe or not, but it's pretty annoying that this is no longer possible, in particular, because iOS15 seems to have broken the auto-connect to known Bluetooth devices for everything but audio devices.

Did you solve your problem? I'm having the same since macOS 12 which seems to have even more stricter rules. My SPM-based command-line-utility https://github.com/mickeyl/core-bluetooth-tool no longer works due to these rules.

I can confirm this. The iPhone mini simulators are pretty much unusable as of Xcode 13. Congrats, this marks a new low in the release of Apple developer tools.

Derive a custom application class and override preferredContentSizeCategory.

Note that softlinks do not impose any problems. I have my DerivedData softlinked to a ramdisk volume and everything is pretty snappy that way.

FWIW, the culprit is the missing inherited permissions. When running the tool from iTerm (which is what I'm using as terminal emulator), it inherits the permissions from it. Granting Bluetooth permissions to iTerm fixes my problem. Now: Is it possible that my command line program can detect this lack of (inherited) permission, thus preventing the crash and rather showing an instruction alert instead?