Xcode

[quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] it is clearly still a bug in Xcode 26 [/quote] Absolutely. There’s no argument about that. [quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] which leads to deployment failure from my Visual Studio on my PC. [/quote] With Xcode, you don’t need to explicitly install the profile because the system picks it up from the embedded.mobileprovision file embedded within the built app. I don’t know enough about how Visual Studio builds and installs apps to offer any insight into why that’s not working for it. My advice is that you escalate this via the support channel for that tooling. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I wanted to wade in to the logging side of this. You wrote: print(…) When debugging code that might run in the background, I recommend that you use the system log rather than print(…). The print(…) routine prints to stdout, which you’ll only see if you ran your app from Xcode. OTOH, the system log lets you monitor your logging regardless of how your app was launched. I have a lot more info about the system log in Your Friend the System Log. I also have general info about debugging code that runs in the background in Testing and Debugging Code Running in the Background. Not all of that applies to your case, but it’s a good place to start. os_log(.debug, perform boot: (item)) Is there a reason you’re not using the new Logger API? It’s much nicer. [quote='868100022, Eloo, /thread/809001?answerId=868100022#868100022, /profile/Eloo'] the logs appear to be uneven [/quote] Right. The system log is a limited resource. If you log to it too quickly, you will run into problems. In your specific example, logging

Thanks for the suggestion but I've tried exporting the GPU trace to a Mac that runs Xcode 26 and I'm still encountering the same issues.

You can think of the number of phrases as in terms of the customer's selected locale, and the limits of 1,000 phrases applies within that locale, not all locales combined. For example, if you have an app with localization support for two different locales, and the first locale needs 500 localized phrases, and the second locale requires 600 localized phrases, your app is still within the phrase limit, because you're only working with 500 or 600 phrases at a time, not 1,100 phrases in total. Keep in mind that the system offers flexible phrase matching automatically, so you don't need to include minor wording changes as separate phrases, to help you manage the amount of phrases you need to provide with your App Shortcuts. You can test out different phrase variations to see how the flexible matching works through the Product > App Shortcuts Preview menu item in Xcode. — Ed Ford,  DTS Engineer

Any suggestions would be great. Most of the Apple documentation on USB ports is like 20 years old, and the new stuff pushes you towards DriverKit. Making this explicit, trying to do this with DriverKit is a great way to make a lot of extra work for yourself without any real benefit. You MIGHT need a codeless DEXT, but that's very different than actually using DriverKit. The USB Host framework is exactly what you want to use. I have been able to open an inservice to the device at the top level, but I get an error when I use it. What's the device? The typical issue here is that one of the class drivers has claimed the device, which blocks your access. Assuming that's the case... I started using DeviceKit, but I received signing errors. I shouldn't have to go down that path just to dump data from a USB port? ...then a codeless DEXT will let you push our driver out of the way. The article Overriding the default USB video class extension has an overview of what's involved. On the codesigning side: I started using

Regarding feedback FB20954846 for App Clip support, I got a message from Apple saying it is fixed. I can now compile, and code sign for an App Clip using the DeclaredAgeRange API. Great. Now that I can get past the compiler failure I'm running up against a new issue. When installed via TestFlight, an App Clip throws that the age range is unavailable. In the console app it looks like the App Clip is still prohibited from calling the system functionality: default PerformanceOrganizer AppClip 18:36:39.200071-0600 (501) Failed to fetch persona: got error from remote proxy: Error Domain=NSCocoaErrorDomain Code=4099 The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction. UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} error PerformanceOrganizer AppClip 18:36:39.200108-0600 (501) person

Thanks so much for the post. I went ahead and downloaded that sample and opened it with Xcode beta posted on the developer website. I do not see the freeze on HKLiveWorkoutBuilder so far, but is there anything I have to do in the sample? Albert Pascual
  Worldwide Developer Relations.

I am getting the same error with a new Xcode (26.1.1) iOS app project and a very simple menu: var body: some View { VStack { Menu(Options) { Button(One, action: {} ) } } } } The error occurs both on tapping Options and One

I'm not sure why Xcode Signing Certificate status is Failed with the above configuration. It doesn't seem to me that DriverKit and the provisioning file expect & as the expected value. Based on the above, isn't it Xcode that expects &? I'm suspicious of Xcode's behavior. I was able to get a look at your account configuration this morning, and I think I can explain what's going on. For reference, I looked at the bundle with this structure: com.0.DextPCIe **Short answer: ** Change your Entitlement.plist configuration to Development Only entitlement configuration: com.apple.developer.driverkit.transport.pci IOPCIPrimaryMatch 0xFFFFFFFF&0x00000000 ...and I think you'll find that your build will suddenly work fine. Note that it's perfectly fine to use the configuration above for normal testing and development. The entitlement above does match all devices, but your IOKitPersonalities dictionary controls what you ACTUALLY match against, so having an broad entitlement doesn'