have you read this thread? https://developer.apple.com/forums/thread/681053

You didn't post any code so I'm making an educated guess here. Your ContentView contains a PreviewPane which is dependent on data from a LiDAR camera. You're developing on a Mac which doesn't have a LiDAR camera. The Preview runs on your Mac, not on the phone, so if it expects a LiDAR camera it isn't going to work. Previews aren't magic, they are conveniences which enable you to see what your UI would look like under various circumstances. But if your UI is tied to dependencies which cannot be represented in the context of a preview, it is going to be difficult to preview. You're going to have to change your preview so that it isn't dependent on LiDAR. That probably means that your preview will just show a static image as a placeholder, and you're going to have to get the static image from somewhere and explicitly refer to it in your preview. This is a problem I run into all the time because a lot of example code uses in-memory data structures for brevity, but the real world is much messier.

Neither forums.developer.apple.com nor discussions.apple.com are places where bugs are tracked or reported. Please report a bug using Feedback Assistant

You are not wrong, something did change - "The p and po command aliases have been redefined to the new dwim-print command." More info here https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes in the section "Debugging, New Features", or search for dwim-print, or scroll through the whole thing

You could take a look at this rather ancient sample code: https://developer.apple.com/library/archive/samplecode/TextEdit/Introduction/Intro.html, then see what has been deprecated and/or replaced since Note that TextEdit performance is not great with large or complex files, and I have no idea if the currently-shipping TextEdit is still based on the code published in the link above or has been substantially updated. If you want to look at newer code, try searching GitHub for "swift rich text".

see the function signatures in the Developer Documentation and follow those to some explanations of the use of the various types of buffers and buffer pointers. func withUnsafeMutableBytes<R>((UnsafeMutableRawBufferPointer) throws -> R) rethrows -> R and func withUnsafeMutableBufferPointer<R>((inout UnsafeMutableBufferPointer<Element>) throws -> R) rethrows -> R an UnsafeMutableRawBufferPointer is simply a pointer into untyped memory. It is just a bag of bytes. an UnsafeMutableBufferPointer is a pointer into typed memory. Each element is of type Element. It is a bag of Elements. You may need to use these APIs to interact with C APIs which take pointers to void *, char * or expect a contiguous array of Elements.

I think this isn't doing what you expect because it is a command line program without a running run loop. You could put your code into an regular application, or you could try calling CFRunLoopRunInMode(kCFRunLoopDefaultMode, 10.0, false); instead of your sleep(10) calls I looked at my own code, but I found I never uninstall my listener blocks so I've never tripped over this problem. I do have a command line program with an explicit call to CFRunLoopRunInMode though...

did RegisterService succeed on all the systems?

The message tells you the problem. Your type, Tag, does not conform to Hashable. Tell the compiler that Tag should be Hashable: final class Tag : Hashable { and then actually conform to it by providing a hashValue property which returns Int. You can probably just use the hashValue of the UUID you already have in your tag, assuming they are all truly unique. inside Tag: var hashValue { id.hashValue }

You asked this question before pointing your function at a file much larger than the memory in your machine to find out what happens? Should it be a problem, you can use CC_MD5_Init, CC_MD5_Update and CC_MD5_Final, breaking up your huge file into manageable chunks.

My specific problem here was that there was no code to sign. I was messing about with two near-identical projects trying to fix a link error, and removed all the code from my dext, then forgot I had done so. This is what DTS said: This system extension has no main executable. For some reason it’s gone completely missing, making it a codeless bundle. So, the code signature gets stashed away in extra files in the _CodeSignature directory, and that has no place to store DER entitlements.

DTS (thank you Quinn!) helped me solve this. The problem is a bug in Xcode's support for DriverKit in projects with a test plan (FB13381958). You have to go into the configuration of the test plan and disable Code Coverage for all targets. Disabling Code Coverage for the driver target only does not work . Note that there's a code coverage setting in the target's Build Settings too, but changing that setting won't make the link error go away.

does this affect you: https://developer.apple.com/help/account/manage-profiles/provisioning-profile-updates/. ? also, have a look at https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles

did you check https://www.apple.com/support/systemstatus/ when the problem occurred? Does it still not work? It works for me now, but you posted a day ago

IOServiceNameMatching is a convenience function which creates a matching dictionary with the contents [ "IONameMatch": ], so it is behaving exactly as it should. It does not return an IOService with name matching . The "IOService" prefix serves as a poor man's namespace. You need to take the matching dictionary and pass it to IOServiceGetMatchingServices, which will return an iterator. You walk through that iterator to get the actual services (if found).