General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi all, I'm building an iOS app extension using ExtensionKit that works exclusively with its containing host app, presenting UI via EXHostViewController. I'd like the extension to have read-only access to the host's task for process introspection purposes. I'm aware this would almost certainly require a special entitlement. I know get-task-allow and the debugger entitlement exist, but those aren't shippable to the App Store. I'm looking for something that could realistically be distributed to end users. My questions: Does an entitlement exist (or is one planned) that would grant an extension limited, read-only access to its host's task—given the extension is already tightly coupled to the host? If not, is this something Apple would consider adding? The use case is an extension that needs to inspect host process state without the ability to modify it. Is there a path to request such an entitlement through the provisioning profile process, or is this fundamentally off the table for App Store distribution? It seems like a reasonable trust boundary given the extension already lives inside the host's app bundle, but I understand the security implications. Any insight appreciated. Thanks!

panic(cpu 6 caller 0xfffffe00408d5cc8): "AMCC0 DCS GROUP 0 CHANNEL 0 AMPH_AIC_IRQ_EN_FLD error: INTSTS 0x00000002" @AppleH16GFamilyPlatformErrorHandler.cpp:4284 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25F80 Kernel version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:26 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8132 Fileset Kernelcache UUID: 810ED0581F8496D5014005FD8C299E58 Kernel UUID: 4FEB3A7D-D020-3910-B7AF-232C78D32651 Boot session UUID: BD3ADC9E-8793-494E-A0D9-2764E76D7F6E iBoot version: mBoot-18000.120.36 iBoot Stage 2 version: mBoot-18000.120.36 secure boot?: YES roots installed: 0 Paniclog version: 15 Debug Header address: 0xfffffe001de0d000 Debug Header entry count: 3 TXM load address: 0xfffffe002dd68000 TXM UUID: F0C1A57F-CE44-3DF4-9E86-0CFF02D7C00D Debug Header kernelcache load address: 0xfffffe003dd68000 Debug Header kernelcache UUID: 810ED058-1F84-96D5-0140-05FD8C299E58 SPTM load address: 0xfffffe001dd68000 SPTM UUID: BF0FEC4B-5AEA-35B8-BF85-518497A9C1C5 KernelCache slide: 0x0000000036d64000 KernelCache base: 0xfffffe003dd68000 Kernel slide: 0x0000000036d6c000 Kernel text base: 0xfffffe003dd70000 Kernel text exec slide: 0x000000003b488000 Kernel text exec base: 0xfffffe004248c000 mach_absolute_time: 0x1832dfe2d Epoch Time: sec usec Boot : 0x6a3ef98d 0x000c2461 Sleep : 0x6a3efa94 0x00069c13 Wake : 0x00000000 0x00000000 Calendar: 0x6a3efa96 0x000a335d Zone info: Zone map: 0xfffffe100c000000 - 0xfffffe360c000000 . VM : 0xfffffe100c000000 - 0xfffffe15d8000000 . RO : 0xfffffe15d8000000 - 0xfffffe1872000000 . GEN0 : 0xfffffe1872000000 - 0xfffffe1e3e000000 . GEN1 : 0xfffffe1e3e000000 - 0xfffffe240a000000 . GEN2 : 0xfffffe240a000000 - 0xfffffe29d6000000 . GEN3 : 0xfffffe29d6000000 - 0xfffffe2fa2000000 . DATA : 0xfffffe2fa2000000 - 0xfffffe360c000000 Metadata: 0xfffffe9654010000 - 0xfffffe965d810000 Bitmaps : 0xfffffe965d810000 - 0xfffffe96605b0000 Extra : 0 - 0 CORE 0 [EACC0] recently retired instr at 0x0000000000000000 CORE 1 [EACC0] recently retired instr at 0x0000000000000000 CORE 2 [EACC0] recently retired instr at 0x0000000000000000 CORE 3 [EACC0] recently retired instr at 0x0000000000000000 CORE 4 [EACC0] recently retired instr at 0x0000000000000000 CORE 5 [EACC0] recently retired instr at 0x0000000000000000 CORE 6 [PACC1] recently retired instr at 0x0000000000000000 CORE 7 [PACC1] recently retired instr at 0x0000000000000000 CORE 8 [PACC1] recently retired instr at 0x0000000000000000 CORE 9 [PACC1] recently retired instr at 0x0000000000000000 TPIDRx_ELy = {1: 0xfffffe2ea1fe8900 0: 0x0000000000000006 0ro: 0x0000000000000000 } CORE 0: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 1: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 2: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 3: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 4: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 5: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 6 is the one that panicked. Check the full backtrace for details. CORE 7: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 8: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 9: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe28d5fa3960: 0 pages, 634 threads: pid 0: kernel_task Panicked thread: 0xfffffe2ea1fe8900, backtrace: 0xfffffea9d5fdabd0, tid: 102 lr: 0xfffffe00424e2194 fp: 0xfffffea9d5fdac70 lr: 0xfffffe00426602a0 fp: 0xfffffea9d5fdace0 lr: 0xfffffe004265e234 fp: 0xfffffea9d5fdada0 lr: 0xfffffe0042491e9c fp: 0xfffffea9d5fdadb0 lr: 0xfffffe00424e24a4 fp: 0xfffffea9d5fdb2d0 lr: 0xfffffe0042dd35c4 fp: 0xfffffea9d5fdb2f0 lr: 0xfffffe00408d5cc8 fp: 0xfffffea9d5fdb630 lr: 0xfffffe00408d6090 fp: 0xfffffea9d5fdbef0 lr: 0xfffffe0042ccd0b0 fp: 0xfffffea9d5fdbf30 lr: 0xfffffe00402f16e4 fp: 0xfffffea9d5fdbfc0 lr: 0xfffffe0042661a50 fp: 0xfffffea9d5fdbfe0 lr: 0xfffffe0042491f40 fp: 0xfffffea9d5fdbff0 lr: 0xfffffe0042506714 fp: 0xfffffe5be553bee0 lr: 0xfffffe0042506670 fp: 0xfffffe5be553bf20 lr: 0xfffffe0042492b6c fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8132(1.0)[47D903D9-8F8C-3E63-BD11-57EC7038EE44]@0xfffffe00408c9310->0xfffffe00408d96a3 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe003f7d7d30->0xfffffe003f82b0f3 dependency: com.apple.driver.AppleEverestErrorHandler(1)[656D28F2-FD94-3B53-AD95-C1DEE28140D2]@0xfffffe003ff78f60->0xfffffe003ff79ebb dependency: com.apple.iokit.IOReportFamily(47)[B53BE23F-34ED-35B3-9E6C-12B7BECC2267]@0xfffffe00418563a0->0xfffffe0041858eeb com.apple.driver.AppleInterruptControllerV3(1.0d1)[17E37838-AA51-37A2-B605-871825C22626]@0xfffffe00402ee730->0xfffffe00402f2ba3 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe003f7d7d30->0xfffffe003f82b0f3 last started kext at 717088811: com.apple.filesystems.autofs 3.0 (addr 0xfffffe003ea21780, size 5927) loaded kexts: (skipped, see boot kernelcache) ** Stackshot Succeeded ** Bytes Traced 474581 (Uncompressed 1135664) **

macOS has the clonefile*() calls to create a new file that's a clone of an existing file, but is it possible to clone only parts of an existing file into a different existing file? Linux (FICLONERANGE) and Windows (FSCTL_DUPLICATE_EXTENTS_TO_FILE) both provide this functionality. I previously filed FB12737014 with this request.

Hello, I'm implementing an NSFileProviderReplicatedExtension (iOS 26 and macOS 26) and would like to validate my approach. What I do To make my uploads efficient I batch them: instead of uploading file-by-file inside each createItem / modifyItem, I ingest all local changes into my extension's local state quickly and upload the content blobs in the background in batches. Concretely, for both createItem and modifyItem: I persist the item to my local store, write its content blob to a local cache, and schedule the upload in my internal queue. I call the completionHandler right away before uploading the item, returning the NSFileProviderItem with isUploaded = false. Once the upload succeeds, I flip the item to isUploaded = true and call signalEnumerator(for: .workingSet) so the change is delivered through the working-set enumerateChanges. This works in my testing, but I'm unsure it is the intended approach, and I have the following questions. Question 1 — Honoring the Progress object I call the completion handler early (step 2) and run the upload afterwards. The convenient part for my batched uploads is that I don't seem to need to honor the returned Progress at all — I never report into it and I just drop it, yet in my testing the upload still completes. I'd like to confirm two things: (a) Can I ignore the Progress? I'd like to never report into the returned Progress and simply drop it: I coalesce uploads into batches drained from a persisted queue, so I can't map one Progress to one upload, and retaining thousands of them is itself a cost. Is that allowed? What makes me unsure is that the docs read a little asymmetrically — for createItem the progress is "presented in the user interface until the completion handler is called", whereas for modifyItem it is "expected to include the upload progress … even if the provider chose to call the completion handler before the upload finishes". (b) If I ignore it, am I still granted execution time to finish the upload? This is what worries me, because the "Execution time" clause couples the two: the system "will grant enough time … to upload the file" but "will interrupt the call if it stops making progress." If I report no progress, does the system stop granting runtime? Question 2 — Upload pipeline depth When calling the completion handler before finishing the upload, both createItem and modifyItem are no longer gated by the NSExtensionFileProviderUploadPipelineDepth limit, and I can have thousands of items pending upload. This is crucial for my approach. Is this behaviour correct and intended?

I have a custom keyboard (UIInputViewController, Full Access). For a dictation feature it opens its containing app to record audio (the keyboard can't use the microphone) and then needs to return the user to the host app they were typing in. That requires knowing the host app. Through iOS 26.3 this worked, because the host bundle id was exposed on the keyboard's input-session connection. On iOS 26.4 / 26.5 it is now nil, and every route I have tried is blocked: UIInputViewController _hostApplicationBundleIdentifier -> nil _hostProcessIdentifier and the host audit token are available, but: RBSProcessHandle handleForAuditToken: / handleForIdentifier: -> "Client not entitled" SecTaskCopySigningIdentifier / SecTaskCopyValueForEntitlement -> nil (sandbox) proc_pidpath -> EPERM UIKeyboardImpl _remoteAppId / _remoteLocalizedAppName -> nil The keyboard arbiter client-change event fires in SpringBoard, not in the extension process However, at least one shipping keyboard still does this on iOS 26.5. I verified in device logs that Yandex Keyboard launches its container app with a URL containing the correct, current host bundle id, and it is live: it reported net.whatsapp.WhatsApp, then net.whatsapp.WhatsAppSMB when the host was WhatsApp Business. So the capability clearly still exists for some apps. Questions: Is there a supported API on iOS 26.4+ for a keyboard extension to identify its host app? If it requires an entitlement, can developers request it, and how? If there is no public path, is the intended approach the system "back to previous app" breadcrumb (manual) plus a containing-app round trip? I have also filed Feedback (FB#######). Thanks.

Hello, Public documentation for NFCPaymentTagReaderSession states that it is currently limited to European Union (EU). Could you please advise when will this restriction be lifted and NFCPaymentTagReaderSession be made available outside of the EU? Are there any other capabilites available to be able to read EMV card data via NFC on a financial services or card issuer's iOS mobile app? Thank you!

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

SUMMARY iOS16 Beta system local network permission pop-up alert does not display STEPS TO REPRODUCE Install My App for the first time on iOS16 Beta system devices Open the My App and you will first see the local network permissions introduction page On this page we will send UDP broadcast packets RESULTS The user should then see the local network permission authorization pop-up alert，but there is no actual popup in iOS16Beta，but it works fine on the previous version of iOS system NOTES On the previous version of iOS system, by sending UDP broadcast, the local network permission authorization pop-up alert can be triggered normally, but in iOS16Beta, the pop-up alert will not appear, and the local network permission switch will not appear in the App-related system settings. I don't know how to deal with this problem. I have tried many methods and it doesn't work. Can someone help me.

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

I saw there is a new es_new_descendants_client() function in Endpoint Security, with very interesting details: no TCC approval required no root privileges required which makes it very different from how we've known Endpoint Security so far. What is the real life use of this client? First, I thought it would be good to monitor processes I launch from my central application - but I won't fork() or exec() other apps - I will ask launchd to open them (NSWorkspace...), so they won't be descendants of my Endpoint Security client containing process. Not to mention, I don't understand how this aligns with the entitlement being attachable only to system(?) extensions. Or, can I now add this entitlement to an application? The dropping of root privilege as a requirement seems like this entitlement could be attached to regular apps. Or it can only be attached to a launchd agent, rather than a daemon? I haven't seen any pointers in Endpoint Security documentation other than this function's documentation. A tutorial would be very nice to have. Thanks in advance!

So apparently Monterey has switched to creating .ips files instead of .crash files for application crashes. Console.app can convert these .ips files to "old-style" crash format. But is there a command-line tool to do the same thing?

Hi everyone, I am developing a macOS virtualization manager (VirtualProg) using the Virtualization.framework. The application is distributed via the Mac App Store, so it operates strictly within the App Store Sandbox. I am looking for a reliable, programmatic way to discover the IP address assigned to a guest (both macOS and Linux). Is there a recommended "Sandbox-safe" API or pattern within the Virtualization framework—or a lower-level networking entitlement—that allows a host application to retrieve the guest's assigned IP address? Ideally, I am looking for a solution that does not require the user to manually install a non-sandboxed helper tool. Thanks in advance for any insights or guidance!

I'm trying to get Apple's new Bluetooth Channel Sounding distance measurement working between an iPhone running iOS 27 Beta and a Nordic nRF54L15-based board. The CS procedures appear to execute successfully over the air (Mode 0 + Mode 2 with Inline PCT), but the iOS sample app consistently returns 0 distance readings and occasionally throws Channel Sounding configuration failed. What specific validation does iOS 27 apply to CS results before surfacing them ? Are there known compatibility requirements for Nordic nRF54L15 with iOS Channel Sounding? (Nordic has indicated they're working on official support but have no timeline) Is there a publicly available hardware and/or firmware platform already available we can use to test? PacketLogger log nRF54L15 log

I'm a contributor to Trio, an open-source automated insulin delivery (AID) app for iOS/watchOS maintained by the Nightscout Foundation. I'm posting at the recommendation of the engineering team via Feedback Assistant FB22619409 (Developer Support case 102865854185). The goal We're prototyping direct BLE connectivity between the Trio watchOS extension and the Dexcom G7 CGM sensor — eliminating dependence on iPhone-to-Watch relay via WatchConnectivity. For an AID app, stale CGM data affects insulin dosing decisions; this is a patient safety concern. The entitlements needed To maintain a BLE connection to the G7 while backgrounded and with the display off/wrist lowered, the WatchKit extension requires: com.apple.developer.bluetooth-central-background com.apple.developer.bluetooth-central-screen-off-scanning What I've confirmed Both entitlements are present on Dexcom's shipping G7 WatchKit extension (com.dexcom.g7app.watchkitapp.watchkitextension), verifiable via: codesign -d --entitlements :- \ "Dexcom G7.app/Watch/G7Watch.app/PlugIns/G7Watch Extension.appex" Output includes: com.apple.developer.bluetooth-central-background = true com.apple.developer.bluetooth-central-screen-off-scanning = true These are not self-service capabilities exposed through Xcode or the developer portal for our account: Xcode → Trio Watch App target → Signing & Capabilities → + Capability → searching com.apple.developer.bluetooth-central-background returns No Matches Certificates, Identifiers & Profiles → WatchKit Extension App ID (org.nightscout.5QE6TMMEH2.trio.watchkitapp.watchkitextension) → the entitlement does not appear under Capability Requests A screen recording demonstrating both is attached to FB22619409. The May 16 Apple Feedback response noted that the entitlement was visible in an internal Xcode project — consistent with it being a restricted/managed entitlement not exposed through standard developer accounts. My questions What is the correct process to request com.apple.developer.bluetooth-central-background for a watchOS extension App ID where it does not appear in Capability Requests? Is com.apple.developer.bluetooth-central-screen-off-scanning available through a private/managed entitlement process, and how do we enter that process? Is there a formal Apple program (e.g., MFi, HealthKit entitlements, or similar) applicable to CGM-connected medical apps that covers these entitlements? Full account details, screen recording, and entitlement output are attached to FB22619409 / Developer Support case 102865854185. Happy to provide a test build, full entitlement output, or additional context if needed. Thank you

Trying to virtualize macOS 27 on a 26.6 host failed at 77% install progress, even with Xcode 27 beta installed. But worked fine on a macOS 27 host. Are there any tricks to use a 26 host? Thanks!

Hi, I am trying to use AAUSBAccessoryManager with mac os 27 to connect host usb device to guest vm. here is my code // // USBPassthroughManager.swift // VirtualProg import AccessoryAccess import Foundation import IOKit @available(macOS 27.0, *) class USBPassthroughManager: NSObject, ObservableObject, AAUSBAccessoryListener { static let shared = USBPassthroughManager() @Published var availableDevices: [AAUSBAccessory] = [] func startListening() async { do { let existing = try await AAUSBAccessoryManager.shared .registerListener(self, matchingCriteria: []) await MainActor.run { self.availableDevices = existing } } catch { LogManager.shared.log(vmName: AppConstants.logGeneral, type: .error, message: "USB passthrough listener failed: \(error.localizedDescription)") } } func usbAccessoryDidConnect(_ usbAccessory: AAUSBAccessory) { DispatchQueue.main.async { guard !self.availableDevices.contains(where: { $0.registryID == usbAccessory.registryID }) else { return } self.availableDevices.append(usbAccessory) print(self.displayName(for: usbAccessory)) } } The usb icon in status bar menu is displayed and i can select the the usb device to connect to my app. the usb device is connected to my app. it is shown in the status bar. but usbAccessoryDidConnect is not firing. i have the entitlement com.apple.developer.accessory-access.usb in the capabilities. i get this in the xcode console start failed ((iokit/common) not permitted) for plugin for .......... and also disconnect is also not firing. Not sure what i am doing wrong. How can i determine the name of the USB Device from AAUSBAccessory. Any help would be appreciated. Thanks

Hi, Is there way to connect the host usb devices directly to guest vms using mac os Virtualization framework? Thanks

Environment macOS Tahoe 26.2 (Build 25C56) Also tested with macOS 26.3 Developer Beta - same issue Windows Server 2022 DFS namespace Connection via Tailscale VPN (but also tested with direct network connection) Problem Description When connecting to a Windows Server 2022 DFS namespace from macOS Tahoe, the root namespace connects successfully, but all subfolders appear empty and return either: "No route to host" "Authentication error" (alternates inconsistently) Steps to Reproduce Set up a Windows Server 2022 DFS namespace (e.g., \\domain.com\fs) Add DFS folder targets pointing to file servers (e.g., \\fs02\share, \\fs03\share) From macOS Tahoe, connect via Finder: smb://domain.com/fs Root namespace mounts successfully Issue: Subfolders show as empty or return "No route to host" when accessed What Works Direct SMB connections to individual file servers work perfectly: smb://10.118.0.26/sharename ✓ smb://fs02.domain.com/sharename ✓ Same DFS namespace works from Windows clients Same DFS namespace worked from macOS Sonoma 14.4+ What Doesn't Work DFS referrals from macOS Tahoe 26.x to any DFS folder target The issue persists regardless of: Kerberos vs NTLM authentication SMB signing enabled/disabled on servers Various /etc/nsmb.conf configurations DNS resolution (tested with IPs and FQDNs) Historical Context A similar DFS referral bug existed in macOS Sonoma 14.0 and was fixed in 14.1. This appears to be a regression in macOS Tahoe 26. Request Please investigate the DFS referral handling in macOS Tahoe. The fact that direct SMB connections work while DFS referrals fail suggests an issue specifically in the DFS referral processing code. Feedback Assistant report will be filed separately.

Hi, I wanted to develop a small tool to launch Home Assistant OS in a Virtualization.framework VM. Something lean (no UI, no daemons), zero-config, and Apple Silicon only. I got that running, but I wanted to also use bridge networking and USB device pass-through which require the com.apple.vm.networking and com.apple.developer.accessory-access.usb entitlements, respectively. I was unable to use those for local development using ad-hoc signing, so I guess it requires a paid Apple Developer account and official approval so that they can be enabled in provisioning profiles. I'm open to reactivating my developer subscription which I let expire years ago, but wanted to first assess the chances of getting approval (no point in renewing the subscription if I won't get the permission in the end). I could make this an open source project, if it helps.

Hello, I have a raw device number, as an input, for external usb/thunderbolt device (i.e. for /dev/disk9 - it is 9). And I want to format it to APFS or read/confirm APFS FS type if it is already formatted. But I can see that APFS container/volume have another disk number (i.e /dev/disk10) in compare with for my raw disk. Is there a guaranteed way to match raw disk number to underlying APFS container/volume disk number? May be some API? Or just add +1 to raw disk number for getting APFS container/volume disk device number?