open the Info.plist in its editor, by selecting Info.plist in the Navigator on the left. You'll find that the width of the Key field has been made very wide, and this is tied to the width of the Key field in the Info panel. If you can't see the column width handles in the Info.plist editor, you can scroll the whole display to the left to bring them into view. The Target's Info tab editor can't do that.

the short answer is because the id of the view in your ForEach is \.self (line 31). If you just write ForEach($cars) { $car in your code will work. (with the code you posted) you can edit all the fields, but you won't see your changes in the detail view until you close the view by going Back, then opening a new CarDetailView. the equality function is used to check if a structure has changed. If you make the equality function only dependent on the id, and have no means to change id, then when you edit your Car, the new struct is considered equal to the old struct value and your 'new' struct won't be saved to the cars array. I have to admit I spent a lot of time today trying to understand why there's a difference between ForEach($cars, id: \.self) { $car in and ForEach($cars) { $car in but could not find a satisfactory explanation. In fact, your code worked in the simulator for me, but not on a real phone, and not in Xcode's live preview. On the phone, it did accept edits, but the values propagated to the cars array were different, while in the live preview, I saw the behavior you described. The id used in the ForEach needs to be stable - self keeps changing if you edit the fields.

Yes our driver is purely virtual, and we know about he best practice note - that's what I'm asking about. We're not using the device only to capture system audio. We're building a software mixer. We create multiple audio mixes from different sources, such as apps and audio inputs, at different levels. We provide the mixed audio to the system as input devices so other apps can use it. As far as I can tell, an audio tap can be used for mixing, but without volume control. I tried to add per-input and per-mix volume control by cascading aggregate devces, but an ggregate of aggregate devices doesn't work - the first-level aggregate device is considered "off-line" by the second-level aggregate device.

https://developer.apple.com/documentation/professional-video-applications/enabling-security-scoped-bookmark-and-url-access

For real devices, someone (it might be the Account Owners, or perhaps any Admin) can go to the Devices section of the Accounts tab of developer.apple.com, and add the "Provisioning UDID" of a device to the list of devices. I've never tried this for a virtual Mac. You can find the Provisioning UDID of your Mac in the Hardware section of System Information. Bear in mind that you can have a maximum of 100 devices on your developer account, and that list can only be pruned once a year. So if you re-create your virtual Mac often, and it has a different Provisioning UDID every time, you may run out of devices. If you build your software on a Mac with Xcode, with automatic signing turned on, that Mac will be automatically added to the list of developer devices. The process of manually adding to the list is only necessary for pure "victim" devices which need to run development software.

I lied. Inadvertently. Sorry. I put all the code (create and find) into one function and ran it from a standalone executable - it fails. If I create two separate standalone executables, one that creates, and another that finds, and run those one after the other, the find executable succeeds. In the single-executable case, I can add this line between creation and finding to make it work: RunLoop.main.run(until: Date().addingTimeInterval(0.5)) 0.1 seconds was not long enough. I'm not sure about the 0.5s because I've only tried it once. I'm interested in doing this in a test because I'd like to create and destroy many such plugins to check for leaks. But I'm not keen on hard-coded delays. Is there a way to detect when CoreAudio is ready to be interrogated again (rather like IORegistryWaitQuiet)? And is there a way to run a runloop within a Swift Test?

Hi Quinn that's what I originally had - within one test, create, then find. That always fails when run from a Swift Test. Same code (of course without all the #expect stuff) run from a command line executable - always works.

https://developer.apple.com/help/app-store-connect/manage-your-team/add-and-edit-users

You can remove some of the default menu items that don't make any sense for your app by replacing that group of commands with nothing at all, for example CommandGroup(replacing: .textEditing) { } however, if I remove all the text formatting commands, CommandGroup(replacing: .textFormatting) { } I still have a Format menu in the menu bar, but the menu has no content. I don't know how (in SwiftUI) you can entirely remove framework-provided menu items.

where do you get the documentation that tells you that the method selector should be 1, or that the parameters should be packed the way you have packed them? In general, objects with class names beginning with"Apple" are private to Apple. You can probably do what you're trying to do if you replace the Apple driver, but not through the Apple driver. However, it may not be necessary at all. If I understand this document correctly, all Macs with a T2 chip or M series processor encrypt the built-in storage, all the time. https://support.apple.com/guide/security/volume-encryption-with-filevault-sec4c6dc1b6e/web.

The value kIOPCIDeviceConnectType is just a number, the third parameter to IOServiceOpen called by your user-space client code. That number appears as the first parameter to NewUserClient_Impl in your dext. If your dext is your own, you can use any value you like, or ignore it entirely. If your code is no longer reporting the kIOReturnUnsupported error, but instead printing only "Failed to match to device", that suggests that there's no driver with the correct name installed. Did you call SetName("com.accusys.scsiDriver"); within your dext's Start_Impl()? I've never written a PCI driver, sorry can't help you with that.

your bug won't be tracked if you "report" it here, so it is very unlikely that any action will be taken

what do you expect to see in the debugger? The view is shown, the layer isn't. What is the problem in your code that you are trying to debug?

this should get you started https://developer.apple.com/documentation/coreimage/cifilter/3228262-qrcodegenerator

0xe00002c7 is kIOReturnNotSupported (from IOReturn.h). You're trying to open four objects, none of which support that operation. I have had more success using IOServiceNameMatching, and giving the driver a unique name (call SetName in your dext, before RegisterService). This way you should make only one attempt to open your driver through its user client. Also, make sure you actually implement NewUserClient_Impl in your dext.