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.

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.

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.

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.

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

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.

In the league of 100ms.

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

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

I have the same problem on Ventura, but from an SPM-based macOS command line program (thus no Info.plist nor any entitlement files nor sandbox configurations). What do I need to do in order to access USB from an SPM-based macOS command line program?

Same problem here. Did you find a fix?

Xcode 14.2 seems to have fixed this for my case w/ conditional SPM dependencies for !APPLE platforms. Closing FB11511342 then.

Seems broken again in Xcode 14.2:

Seems broken for me in Xcode 14.2 as well: Did the usual dance of rebooting, restarting, and what not. Nothing helps.

FWIW, this is a generic (as in non-Apple-specific) Swift issue that will probably find a larger audience at the official Swift forum.