The answers you are looking for are linked from the documentation you provided a link to, here: https://developer.apple.com/documentation/swiftui/migrating-from-the-observable-object-protocol-to-the-observable-macro?language=objc The Observable macro is new and most of the Internet hasn't caught up yet. If you can use Observable, you can use @State instead of @StateObject, even for classes and structs. The library lives outside the App struct. Lexically, it appears to be inside the struct, but SwiftUI manages its lifetime because of that @State macro. You can put a breakpoint inside Library's init to see when it called.

The Vision framework can detect various types of barcodes (start here: https://developer.apple.com/documentation/vision/vndetectbarcodesrequest) If you need to create bar codes to work with, you can use a built-in CoreImage filter to generate a bar code. See https://developer.apple.com/documentation/coreimage/cibarcodedescriptor. The links above should give you a starting point, and some keywords to search with.

I don't know of any API to get this kind of information directly. You might be better off using performance measurements to change your strategy on-the-fly. What differs between SSD and rotating rust that influences your strategy? You can query a volume to find out its BSD name, using statfs. The f_mntfromname field contains the BSD name, (e.g. /dev/disk1s2). You can search the IORegistry to find nodes with BSD names matching e.g. "disk1s2". Then look up the IORegistry to see if the controller is an NVMe controller or something else. The methods for iterating through the IORegistry are in IOKitLib.h, there's a tool called IORegistryExplorer which lets you inspect the registry.

You've declared getTemperature but not defined it. readSMC should return a kern_return_t but it is returning a double (0.0) or a float. I think you got readSMC mixed up with getTemperature.

On macOS, libUSB uses the methods in IOKit/usb/IOUSBLib.h. These are unavailable on iPadOS. DriverKit is available on iPadOS on devices with M1 or later processors. DriverKit doesn't have the same APIs as IOUSBLib, you would use it to make a Driver Extension (dext) which provides the functions you require. You can read the device ID and the vendor ID without direct access to the device itself, by querying the IORegistry. In principle, you could communicate with a device using the user-space property accessors like IORegistryEntrySetCFPropert(y/ies) and IORegisteryEntryCreateCFPropert(y/ies), but in practice most drivers don't support the property setters, so you would have to write a driver extension which does. And if you go that far, you may as well support direct communication with the driver by implementing a user client and calling IOConnectCallMethod or its derivatives like IOConnectCallStructMethod. I don't think you need special entitlements to read the IORegistry, but you do need them to communicate with drivers, and you driver needs specific entitlements which are tied to one or more specific USB vendor IDs. Reportedly, you can develop a driver without the entitlements, but I could never get that to work and have since been granted the entitlements so I never revisited the topic. See https://developer.apple.com/documentation/driverkit

Buttons are special. Google "swiftui macos big button" and you'll get some useful links. e.g. https://sarunw.com/posts/swiftui-button-size/ and https://stackoverflow.com/questions/59290097/in-swiftui-how-do-i-increase-the-height-of-a-button

where are you using the TestPicker (aside from in its Preview)? it works for me when used in the ContentView below. I built this for iOS and ran it in a iPhone 15 simulator. To dismiss the picker, swipe down on the horizontal grey bar near the top of the screen. struct ContentView: View { @State private var selection = 1 var body: some View { VStack { TestPicker(selection: $selection) } .padding() } } #Preview { ContentView() } Lots of SwiftUI examples on Paul Hudson't site, for example https://www.hackingwithswift.com/quick-start/swiftui

your camera extension will be removed from the system when the user deletes the app from /Applications. They'll see a warning when they do so, it says something like "this app includes an extension which will be deleted if you delete this app, are you sure?". So if your app only contains a camera extension, you don't really need an uninstaller - everything goes away when the user deletes the app. Your installer can't deactivate the extension because the uninstaller's bundle ID is "com.my.app.unisntaller" and the extension you are trying to activate has a bundle ID which is not prefixed by "com.my.app.unisntaller". Two things here: did you intentionally mis-spell "uninstaller" in your bundle ID? If you have an uninstaller, it should just delete the app hosting the extension, and the OS will take care of unloading the extension

So you're saying that when a full screen app is frontmost, if you move the mouse cursor to the top of the screen directly, the menu bar appears, but if you place the cursor programmatically using CGDisplayMoveCursorToPoint the menu bar does not appear? Are you also saying that the commented-out code which inserts a mouse-moved event doesn't work? If it doesn't, in what way does it not work - does it not move the cursor, or it does move the cursor but the menu bar doesn't appear as expected?

Does your component.plist contain <key>BundleIsRelocatable</key> <true/> If so, changed it to <false/>. I thought this (BundleIsRelocatable=true) meant that the user can change the destination. In fact, it means that the Installer can relocate the bundle to the location of a previously-installed bundle, rather than put it at RootRelativeBundlePath

import IOKit import IOKit.serial

It is possible to use pkgbuild without --component-plist, it looks like you are doing that. If you want more control, run pkgbuild with the --analyze option, then edit the template plist to your liking (this is where you could make the app bundle non-relocatable), and subsequently use pkgbuild with --component-plist. It has been forever since I did this, so this is as far as I think I could assist. I hope it helps.

@W1EBR I know exactly what you mean (I'm trying to do something similar currently myself). Fortunately, my project is for our own hardware; we are entitled to our own USB vendor ID so we can make an iPadOS driver for our hardware. If your SDR is your own, or that of a business partner, you/they can request the entitlement com.apple.developer.driverkit.transport.usb entitlement. If it were third-party hardware, but the software is open source, you can let users download and compile it to run locally. No entitlements are needed, but obviously the barriers to entry for most users is way too high. If the SDR is a commercial product, it is up to the vendor of the product to provide a driver. There doesn't seem to be a way (yet? who knows?) to talk to arbitrary USB hardware on iPadOS. Apple would encourage you to file a feature request using Feedback Assistant if that's what you would like to able to do.

I see. I didn't know that you installed other items. In this case, yes you would use an uninstaller. But the uninstaller doesn't need to deactivate the camera extension, all it needs to do is delete the hosting app. The camera extension will be deactivated and eventually deleted from the system. If the extension is still in use, it won't be unloaded until the hardware is unplugged or the system restarts. On macOS, the bundle ID of the extension and the hosting app don't have to be related. The Xcode template project sets up related bundle IDs, there's no good reason to stray from the practice. On iOS/iPad OS, the extension's ID must begin with hosting app's ID. Usually, the team ID of the extension and the host ID have to match, unless you have the com.apple.developer.system-extension.redistributable entitlement (macOS only) I don't know whether another app can deactivate your driver. Maybe it only works if the uninstaller also contains the driver extension (even if it would never activate it?). But it shouldn't be necessary anyway - just delete the camera extension's hosting app, and your audio plug-in.

Well, I'm out of ideas. If it were me, I'd file a DTS incident