Solved. Must call setNeedsDisplay from the main thread.

It looks like the main culprit here is a lack of patience on our part. Another way of putting it is that the portal is slow when handling some operations and doesn't do the best job of reporting current status. In any case, coming back to the problem the next day showed the user and the portal in their appropriate states. We are able to continue with our test.

This problem has been solved. Please see this thread for details. https://developer.apple.com/forums/thread/751490

Kevin, thank you so much for responding. My entire dev team just got together on a video call and spent 3 hours trying everything we could to figure this out. No personal reflection on you but Apple MUST do better. The information you provided above jives with most of what we discovered. The solution for us was to switch to automatic and also change the idVendor value from a String to a Number when moving from an wildcard value to a literal value. This appears to be necessary when putting a real Vendor ID in the entitlements file. This was a lot harder than it should have been.

I have the same question with regard to the USB transport entitlement. I've added my vendor id to the appropriate entitlement files but my binary fails validation when trying to upload it to the store for distribution. The embeded.mobileprovision file in the generated archive shows an asterisk instead of my approved Vendor ID. How can I make sure the embedded provisioning file has my Vendor ID?

Solved. Must call setNeedsDisplay from the main thread.

The iPad I'm trying to use is not an M1 or M2 iPad, which is a requirement for the DriverKit extensions. I have the generation just prior to the M1 iPad.

Ignore the API call I listed in the initial post. That is for macOS not iPadOS. I actually support both platforms but the issue I'm having is with the iPad. There we simply launch the settings app using the following technique: extension ExtensionManager { func activate() { guard let url = URL(string: UIApplication.openSettingsURLString) else { return } UIApplication.shared.open(url) } func deactivate() { } }

Trial & error coupled with scouring the web has yielded at least a partial answer: import AVFoundation import Cocoa import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true let engine = AVAudioEngine() let inputNode = engine.inputNode let format = inputNode.inputFormat(forBus: 0) let outputNode = engine.outputNode engine.connect(inputNode, to: outputNode, format: format) //var bufferCount = 0 //input.installTap(onBus: 0, bufferSize: 2048, format: nil) { audioBuffer, audioTime in // bufferCount += 1 // print(bufferCount) //} engine.prepare() do { try engine.start() } catch { print(error) } Ridiculously simple but amazingly difficult to stumble upon. At least, that was my experience. Next, I need a way to enumerate the inputs so I can pick the microphone I want to use. Anyone have a clue on how that is accomplished on macOS? During my time researching this problem, I noticed that things are much easier and much better documented for iOS.

Thank you for your response.

Same deal. I need to support custom hardware via USB-C and serial communication. We are currently trying to figure out the iPad (started three days ago; slow going), the iPhone is next on the list.

I don't know if this is still an issue for you but you have the choice of calling C, Objective-C, and now C++ directly from Swift. See what's new in Swift from WWDC23. There is a sample here that will allow you to enumerate serial devices on macOS. That might be a useful place to start. I would place this code in a separate framework and write the appropriate wrapper functions (as needed) to invoke them from SwiftUI or Swift. If you are trying this on iPadOS, forget it. The sample code won't compile for iOS since most of the definitions are missing or not made public for serial device support in IOKit. I was able to test this code with an FT232(USB-C to UART) board and it worked well enough. Also, you can use Serial Tools to make sure the device you want to talk to is supported by the default drivers built into macOS.

@svedm How do you link against USBSerialDriverKit.framework? Using Xcode 15, I can seem to locate this framework.

I also have the same issue. Did the entitlement from Apple solve the problem?

The solution was provided by "_Agent". I was missing the full type name task handle. A case of mental blindness.