another approach is to paste the offending code into some well-known llm, and ask it "what is wrong with this SwiftUI code". A predictive text model is quite good at spotting this kind of error, and suggesting a correction.

You haven't posted enough context. If you click on the Report navigator icon (the rightmost icon at the top of the left column in Xcode, which looks like a hierarchical list), you can see the full build log, which should help you to fix errors like these. With what you've posted, we can't see the name of the first missing file. The second missing file may be missing because the first is missing, and that in turn may be due to something reported only as a warning in the detailed build log.

if you scroll down to the bottom of this page, you'll see lot of links. Under the Support section there is a Contact Us section, use that to submit a support request to developer services. This forum is primarily for developers to help other developers with programming questions. It isn't an official Apple support channel, and it is public.

I can tell you my experience with a Camera extension, and with a USBDriverKit extension. I believe the requirement that the kext's bundle ID begin with the bundleID of the hosting app is for iOS/iPadOS only. There isn't such a restriction for the dexts that I know about (but networking or security extensions might have different rules). That said, I see that I actually obey that rule with my projects, and it doesn't do any harm. Your dext has a managed entitlement for PCI. Your Account Owner has to make a profile for that on the developer portal - an Admin can't (but won't see a helpful error message, last time I tried as an Admin). You can leave all the Xcode settings that are working for development as they are. Try not to fiddle with Info.plist files or Build Settings directly if there is a way to set the same settings using the Info tab for your target, or the General tab, or the Signing and Capabilities tab, because those feed into the Build Settings. in my main app and dext targets, the Provisioning Profile is "Xcode managed profile" and the Signing Certificate is a Development one. That's fine, it is all going to re-signed for distribution. When you want to build for distribution from Xcode, archive your build. choose Distribute choose the Custom distribution method select Direct Distribution select the Export destination use the Manually Manage Signing option at this point, you'll be able to choose a Developer ID Application certificate, and the appropriate profiles for you app and its extension. If you're doing all this from a script, you have to figure out what the right commands are which correspond to the steps in the dialogs. Good Luck! I can't take you any further with this, because I gladly ceded signing and notarizing tasks to our DevOps team, so I don't have the signing certificates with the private keys on my Mac. AFAIR, I selected "None" for my app's Profile, it doesn't need anything special, while the driver has managed entitlements and I do need to set its profile explicitly. After a successful signing step here, you can use notarytool to notarize the app, and attach a ticket to it. There's a post from Kevin Elliot here about this https://forums.developer.apple.com/forums/thread/751490?answerId=787624022.

I see what you're seeing, but I don't agree with your expectation. BUILT_PRODUCTS_DIR and EXECUTABLE_NAME are not environment variables, they are Xcode build settings. The environment Xcode launches your tool into is empty, aside from the variables you set in the Environment Variables section of the Scheme settings. In my Terminal, I can echo $HOMEBREW_PREFIX and the result is /opt/homebrew. However, the result of getenv("HOMEBREW_PREFIX") in my program is null, if I run it from Xcode, but it is /opt/homebrew if I run it from an interactive shell, because that shell runs its programs in a non-empty environment. If you just want to debug your application, using the environment it would have if run at the command line in a shell on your machine, you can go the Scheme's Info tab, and select "wait for the executable to be launched". Then launch it from a Terminal window - it will get whatever environment your shell gives it.

if you look up CVPixelBufferGetBaseAddress in Xcode's developer documentation, you'll see it is in the Core Video framework. Similarly, CMVideoFormatDescriptionGetDimensions is in the Core Media framework. So I think you need to add CoreMedia and CoreVideo to your framework includes.

the first error suggests that your code does not #include the second error indicates that your code is using memchr on a wchar_t, and it should be using wmemchar. If you included the code that doesn't compile, rather than just the very last error message, someone might be able to help you further.

nine months too late, but here we are. For dext loading, the OS uses the IOKitPersonalities dictionary, which is in your driver's plist. The entitlement is separate. For development, Xcode will make a special entitlement with idVendor="*", so you can play around with any device you like. I don't think I've ever managed to use "sign to run locally" for a dext. Instead, I use development signing with our team ID.

The Apple driver has the UVC interface open all the time when the device is streaming, but not the device interface. You can send device commands or receive status over pipe 0. You would have to poll to get the button press. What platform is this on - macOS, or iPadOS? On macOS, if your button exposes a HID interface, you can use HID manager routines to get notifications of reports on the interrupt pipe. The system will attach its own driver to a keyboard or mouse, but it will leave a vendor-specific HID device alone, so your code can talk to it.

Did you enable "C++ and Objective-C Interoperability" in the build settings (under Swift Compiler - Language)? What kind of interface does your library export? If it is C only, you won't need to do this. But if it exports any C++ symbols, or if its exposed headers include any C++ headers or data types, you're going to have to turn that interoperability on.

Did you check in Xcode's Settings if you are logged in with the right Apple ID?

Maybe there's a bug in the optimizer. But I think it is more likely that your code is doing something wrong, and sometimes getting away with it. Try turning on the memory management diagnostics in the Scheme editor and run your debug version again.

see https://developer.apple.com/forums/thread/763516?answerId=803923022#803923022. This looks like a bug in iPadOS 18.0, fixed in iPadOS 18.1.

did you look at the detailed build log to see what the duplicate symbol is, and where it is defined? If you compare the detailed build log with the log from Xcode 15.3, this might guide you to a solution. To access the detailed build log, click on the little hamburger icon on the right of the screenshot you posted. If you think this is a regression in Xcode 16, submit a bug report using Feedback Assistant - bugs reported here aren't tracked, and there isn't enough information in your post for anyone to help you.

I fixed this. The problem was a header file called Driver_public_shared.h, which was included in my Driver.cpp file. It lives on disk beside Driver.cpp. By default, header files have Project membership, so they are not copied into the resulting output bundle. If I give Driver_public_shared.h either Public or Private memberships of the dext target, it appears in the dext in the Headers or PrivateHeaders directory, and I can compile the delivery app, with the driver as a dependency. Interestingly, the header appears in the build folder in the dext in Products/Debug/Debug-driverkit. But the dext which is embedded in the delivery app has no Headers directory. That's fine by me, I didn't want to deliver any headers as part of the driver, but I don't understand why there had to be a Headers folder in some circumstances and not others, nor do I understand why it is removed when embedding the dext.