“show when run”

To clarify, this isn't a memory leak, it's an issue with not de-duplicating or evicting copied model weights from a SIP-protected disk space. I'm also not sure the bug is CLI-specific. I definitely observed it with my CLI tool, Junco,, but I have another SwiftUI application where I'm observing the issue as well. Simply running the app from XCode copies the weights & metadata to the location above, and I've only been able to delete the accumulated ~104GB (645 model clones) through Recovery Mode.

Is there any way at all to do this on macOS? I'm not sure exactly which APIs you're interacting with and how that translates to the specific failure you're seeing, so I'm going to outline what should work. Give it a try and then we can dig into the specifics of any issue you run into. Getting into the details: You should be using the IOUSBHost Framework, which is the modern framework for interacting with USB devices from user space. I'll assume you already know how to find your target in the IORegistry, but please let me know if you need guidance on that. You should be looking and connecting to the IOUSBHostDevice, NOT the https://developer.apple.com/documentation/iousbhost/iousbhostinterface?language=objc. That gives you full control over the accessory and removes all other drivers, which is what you want for a firmware updater. When you create your host object, you'll need to pass in the IOUSBHostObjectInitOptionsDeviceCapture option. You can also try IOUSBHostObjectInitOptionsDeviceSeize, but I th

Your diagnosis is correct — this is Metal shader compilation and GPU resource setup. SceneKit compiles pipeline states and uploads textures and geometry buffers lazily the first time a particular combination of geometry, materials, and lighting reaches the GPU. SceneKit caches the compiled results to disk, which is why every subsequent launch is smooth and why installing over an existing copy doesn't trigger the problem. If you want to confirm this, you can profile a first-launch run in Instruments using the Metal System Trace template — you'll see pipeline state compilation happening on the GPU timeline right at the moments the frame hitches occur. But based on what you're describing (first install hitches, smooth after that, returns after delete/reinstall) this is almost certainly what's happening. In watchOS, the tools available for prewarming are limited. SCNRenderer (which offers offscreen rendering and snapshots) is not available in watchOS. What you do have are the prepare methods on the SCNSc

TestFlight distribution and testers have the same requirements as your end users who would be downloading your app from the App Store. This means the testers will have to be: physically be in the EEA logged on to their phones with an iCloud account based in the EEA As explained in the documentation HCE-based contactless NFC transactions for apps in the European Economic Area (EEA), if you have testers outside the EEA, you cannot use TestFlight builds. Testing requirements Apple has developed a solution which allows HCE Developers to develop and test HCE Payment Apps outside the EEA. The new solution allows development and testing on a device through known and well-used means such as Xcode and provisioning of profiles used for testing on devices within a developer’s organization. Developers will be able to have up to 100 test devices outside the EEA. To test HCE-based contactless transactions, you’ll need to test with an iPhone and NFC hardware. CardSession requires the presence of an NFC reader, which isn’t s

Thanks for confirming this! A follow-up question: when you say specific to command line tools, what is the distinction exactly? My CLI (hunch) is a Swift executable compiled with swiftc, no app bundle, no NSApplication. Each invocation is a new process that loads the adapter, runs one inference, and exits. Is the difference that: App bundles (.app with NSApplication) store adapter caches in a different location that gets cleaned up on termination? Or is there a cleanup callback tied to the app lifecycle (applicationWillTerminate, etc.) that CLI tools never trigger? Would wrapping the same code in a minimal .app bundle avoid the issue?

Thanks all for the feedback reports, those were super helpful tracking down the issue! We've identified this is a current bug specific to command line tools. So you will see this adapter memory leak from a CLI on macOS, but not if you load the adapter into a running Swift app.

My main goal was to use Authentication Services but it requires the device to be managed via mobile device management. For non-managed devices, I was looking to create an extension that all apps on the device can talk to silently using CTK for tokens in the CTK host app's possession. In iOS, with the sandbox restrictions, as you pointed out, only apps hosting their extensions can talk to it via XPC. iOS26 introduced some APIs in extensionKit to add an interactive view for users. I was hoping, as a developer I can control the messaging in the consent prompt that shows up when an app tries to access tokens using CTK the first time. The best path would be to open up XPC communication across apps using extensionKit in iOS but that is Apple's decision to make :) Or remove the device management prequisite to use Single-sign on extension in Authentication Services.

What is it that triggers iOS to show my device as a paired device on the Bluetooth settings screen after it is paired? I have managed to make it appear once or twice and seems to depend on the advertising data and scan response. It looks like I must have the Complete Name in the advertising data (not the scan response) but there is some other switch as well. It is working sporadically for me at the moment. Could someone tell me what the heuristic is?

I'm going through the same issue. I made the payment on April 12, showing on my credit card, and my account is still pending. It's asking to pay again. I created a ticket on April 13 and I haven't heard anything.

[quote='884845022, Pavel, /thread/823101?answerId=884845022#884845022, /profile/Pavel'] To avoid confusing users with unnecessary UI, this container app must run in the background without a Dock icon. [/quote] This is something I specifically recommend against. Your container app should have some sort of UI. Ideally that UI should allow the user to enable and disable your product (subject to appropriate authorisation). If you want something that does processing in the background without a UI, do that in: Your launchd daemon, if the work doesn’t require a user context Or your launchd agent, if it if does Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com