take a look at the AVCam sample code. It is for iOS, but most of it translates pretty well to macOS. You build a AVCaptureSession using your AVCaptureDevice, and set up a AVCapturePreviewLayer so you can see what it is producing. There is also older sample code kicking around which is more Mac-oriented, and some third-party samples on GitHub. Try searching for "macOS AVCaptureSession sample"

it seems that HIDDriverKit isn't available on iPadOS. But you can write your own code to detect your custom device (using USBDriverKit) and your own routines to read and write reports, which are usually pretty simple control pipe writes and interrupt pipe reads. If your device isn't horrendously complicated, this is easier than using EA, and you don't need to deal with MFi licensing.

If you're trying to initialize an unsigned Swift integer from something that might be negative, Swift won't let you unless you're explicit. let x:Int8 = -1 let y = UInt8(x) fails because "negative value is not representable" but this works let y = UInt8(bitPattern: x) y will be 255

/Applications/Xcode.app/Contents/Developer/Platforms/DriverKit.platform/Developer/SDKs/DriverKit.sdk/System/DriverKit/System/Library/Frameworks/USBDriverKit.framework Yes, it is weird that you have to add it manually. Mine is saved relative to the Developer directory.

@cullenp you asked "how do I access the CMIO extension in the first place" From an app, use the routines in CoreMediaIO/CMIOHardwareObject.h to iterate through the CMIO objects, starting at kCMIOObjectSystemObject until you find an object with kCMIODevicePropertyDeviceUID with a value equal to the value of the deviceID parameter used in your initializer of your CMIOExtensionDevice. You also asked "Is it possible to supply the Extension provider source with my queue? " I'm not sure what you're asking here. You find the sink stream's ID by querying the sink device you found using the code above. Using that sink stream ID, you can copy its queue using CMIOStreamCopyBufferQueue, and you use CMSimpleQueueEnqueue to put your samples onto the sink stream's queue.

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.