Post not yet marked as solved
Seems broken for me in Xcode 14.2 as well:
Did the usual dance of rebooting, restarting, and what not. Nothing helps.
Post not yet marked as solved
Seems broken again in Xcode 14.2:
Post not yet marked as solved
Xcode 14.2 seems to have fixed this for my case w/ conditional SPM dependencies for !APPLE platforms. Closing FB11511342 then.
Post not yet marked as solved
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?
Post not yet marked as solved
FWIW, broken since iOS13. For details check here.. Feedback reported as FB9856371.
FWIW, broken since iOS13: https://stackoverflow.com/a/70823487/415982 – FB9856371
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.
Post not yet marked as solved
Are there any facilities using the new concurrency primitives to improve this syntax?
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
