I have determined that this is actually buggy behavior, on the part of Apple, and I reported it as such. They may choose not to address it, as things become more consistent after a connection is established with the device. However, I would argue that consistent behavior is fairly important, between different parts of the Apple ecosystem, if the same SDK (Core Bluetooth) is used, and advertisement is a pretty damn important part of BLE (Some devices, such as beacons, ONLY operate with advertisements). I could see that, if it were Core Bluetooth vs. IOBluetooth, or some other SDK, then a difference would be OK, but this is not, in my opinion, acceptable. Additionally, the Mac inserts another field (kCBScanOptionAppleFilterPuckType) into the advertising data that is not available on other platforms. I made the test project a lot more robust: https://github.com/ChrisMarshallNY/TestCBIssue

Thanks! I'll have to check if it's possible to get what I need from it. Not sure if it's possible; but maybe.

Well, here it is, "release day," and...envelope, please? IT'S STILL HAPPENING! The 60 seconds thing tells me that a TCP/IP or Bluetooth timeout is happening. I should mention that Charles Proxy is not showing anything happening on the Mac, so the timeout is happening on the device.

This solved my issue: https://stackoverflow.com/a/66334661/879365 The deal is that specifying platforms does not actually prevent Swift Build from trying to compile them, anyway, so we need to bracket platform-specific code in macros. Yeah, it sucks. It's a kludge.

Nope. I have a feeling that Apple is abandoning IB, in favor of SwiftUI; which isn't a bad thing, except that I'm not convinced that SwiftUI is up for really big, complex projects, yet.

This is a problem for me, as well

I think that this is the answer you are looking for. I have not fully tested it, so far, but it seems to work.

I am posting this as an answer, even though it is just another gripe. The reason is because I can't seem to track my comments; only answers. This is what I posted in a comment, above: Sadly, this does not work for me, and there's absolutely ZERO indication, as to why. Even the sample Apple SlothCreator package example does not work. I am using the latest ship Xcode (13.2.1), and I downloaded the sample (From the page linked with instructions), fifteen minutes ago. I followed the example in this page, verbatim. It simply opens the Apple documentation viewer, with the standard built-in docs. My app's docs are nowhere to be seen. I have been writing frameworks and packages in Swift for years, and documenting with Jazzy, so all my code already has the triple-slash/double-star markdown notation. I can't get documentation to appear for any of my projects (they have all been upgraded to 5.5, for some time). I'm quite sure that I'm doing something wrong, but it is impossible to tell what it is, that I am doing wrong.

OK. Now this is an answer. It's really, really dumb, and I'm not the dummy. It looks like the documentation screen hangs onto the last filter that was used, so if you (as do I) like to use the Quick Help Navigator, and "Open in Documentation," you'll generally have a value in the "Filter" entry, and the bottom of the Navigator. If there is anything at all in there, it will block display of the documentation. I will register a bug, saying that this should be cleared, when opening as a result of the "Build Documentation" step.

Same thing is happening to me, but ONLY when compiling for My Mac (Mac Catalyst). It has been working fine, for iOS/iPadOS, for years.

Thanks! That was what I needed.

Thanks. I had assumed that would be the answer, and I think that I may have come up with an acceptable workaround, but we'll see. You, sir, are an international treasure.

I did submit a feedback item on this: FB13787361 I suggested adding a "Sign in with Apple" line to the app's Settings Screen:

I am seeing the same issue in the release iOS18 simulator. Works fine, on-device, and on the iOS17 simulator. The only issue is the iOS18 simulator. I did not test the iOS18 SIMULATOR, because I didn't want to use an unreleased Xcode. I did test on an iOS18 device, though, and that never showed a problem.

Yup. There is definitely a bug. This conversation covers it, as well as a reported bug.