It's been a long time, but in the meantime, this bug has been fixed. It's working as of at least watchOS7 (maybe earlier).

Still in iOS 14.3 – I find it mildly amusing, but also irritating that Apple leaves such messages in their builds. It demonstrates a general sloppiness and lack of polish.

Same problem with my AppleWatch SE cellular. Unbearable!

How did you manage to get the CoreBluetooth security confirmation appear for your command-line app? I'm trying to do the same and said alert only appears when I run the app from lldb.

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?

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

Derive a custom application class and override preferredContentSizeCategory.

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.

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.

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.

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

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

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?

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'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?