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"

I am developing a macOS window-management utility for a new Mac App Store submission, targeting macOS 13+ on Apple silicon and supported Intel Macs. Its core function is to move and resize windows belonging to other, unmodified applications, in response to explicit menu commands, registered keyboard shortcuts, or optional edge-drag snapping. The current unsandboxed engineering implementation uses public Accessibility APIs: AXUIElementCreateApplication, AXUIElementCopyAttributeValue / AXUIElementCopyMultipleAttributeValues for window geometry, AXUIElementCopyElementAtPosition for drag targeting, and AXUIElementSetAttributeValue for AXPosition and AXSize. It requires explicit Accessibility consent. Window information is processed locally; the app does not transmit it. I understand that App Review Guideline 2.4.5(i) requires App Sandbox and that “Protecting user data with App Sandbox” lists assistive Accessibility API use as incompatible. The DTS answer in thread 789663 also explains that sandboxed apps cannot use Accessibility APIs, while noting that some use cases have alternatives. For this specific cross-application positioning/resizing use case: Is there a currently supported public API or documented, requestable entitlement that permits it in a newly submitted sandboxed Mac App Store app? If a supported alternative exists, what API/architecture and minimum OS requirements apply, including any approval process? If there is no supported route, can you confirm that this functionality cannot currently be delivered within the described sandboxed Mac App Store constraints? I am seeking a supported architecture for controlling other apps’ windows. The unsandboxed tests establish functionality only; they do not establish sandbox compatibility or App Review eligibility. References: https://developer.apple.com/app-store/review/guidelines/#hardware-compatibility https://developer.apple.com/documentation/security/protecting-user-data-with-app-sandbox https://developer.apple.com/forums/thread/789663

Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK. We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect. For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED: acl_get_file(path, ACL_TYPE_EXTENDED) acl_get_fd_np(fd, ACL_TYPE_EXTENDED) On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL. The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability. On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object? Please clarify: Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations. Whether relevant behavior is specific to this macOS/APFS version. Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.

Is there a publicly supported macOS API, entitlement, or framework capable of enforcing a hard 64 MiB aggregate memory ceiling across a process tree, including its supervisor, observer, and descendants? Enforcement must be established before workload execution, survive fork/exec, and remain effective if the controlling process crashes. We have examined per-process resource limits and process-memory reporting, but these do not establish the required aggregate guarantee. If supported, which API and enforcement mechanism should we use? If not, is there a documented platform limitation?

Device and software: iPhone model: iPhone 15 Pro iOS 27 Public Beta 6 Build: 24A5430a BLE receivers: two independent ESP32's IRK has worked reliably on iOS 26 and past versions. Observed behavior: With the iPhone display on both BLE receivers detect advertisements that resolve correctly using the enrolled IRK. No more than 10 seconds after the display is turned off, the IRK-resolvable advertisements stop. The IRK identity returns immediately when a notification wakes the display or when I manually do. Bluetooth itself remains active while this happens. The receivers continue to see several strong advertisements from the phone with some unidentified rotating addresses. The unidentified addresses rotate periodically and cannot be associated with the enrolled IRK. Additional observations: When my Apple Watch is powered on and connected, the iPhone remains IRK-detectable while the screen is off. It stops again when watch is disconnected. Connecting Bluetooth headphones does not have the same effect. The IRK-resolvable advertisement stops even while music continues playing. Moving the affected phone between two receivers confirmed that the unidentified rotating advertisements physically followed the phone. The existing IRK remains valid because it resolves the phone again immediately whenever the display wakes. I couldnt find any intentional IRK, private-address or screen-off advertising change documented in the iOS 27 release notes or any discussions online. Has anyone else observed this on iOS 27?

Summary A minimal read-only FUSE-T filesystem cannot be mounted over a newly created, empty directory on an external APFS volume. FSKit reaches the LIFSv2 mount stage, but the final mount(2) returns EPERM. In the same timestamp window, sandboxd requests kTCCServiceSystemPolicyRemovableVolumes on behalf of root /usr/libexec/fskitd. The request is forwarded to com.apple.tccd.system, but TCC logs an invalid XPC connection and sends an empty reply with no auth_value. sandboxd then reports the missing authorization value and denies the request; fskitd immediately reports mount(2) error 1. No user-facing consent prompt appears. This looks like an authorization handoff or policy-integration failure in the system FSKit mount path, rather than a denial returned by the filesystem implementation. The exact reason com.apple.tccd.system returns an invalid or empty reply is unknown. Environment ItemValueTest date/time2026-11-06, approximately 18:47:31 CETMacApple silicon (arm64)macOS27.2, build 26B123FUSE-T receiptsorg.fuse-t.core.1.2.9, org.fuse-t.fskit.1.2.9Registered FSKit extensionorg.fuset.fskit-srv.module, version 0.1.3FUSE-T library/Library/Application Support/fuse-t/lib/libfuse-t-1.2.9.dylibTarget volumeWDBlack4TB, /dev/disk8s1; case-sensitive APFS; owners enabled; read/write; diskutil reports Protocol: PCI-Express and Device Location: ExternalMount pointNewly created, empty directory on the target volume; owned by logged-in user (UID 501), mode 0700Minimal reproduction Enable/register the FUSE-T FSKit extension using its normal installation flow. Build or use a minimal read-only FUSE filesystem whose callbacks expose only the root directory and one static hello.txt file. The fixture used here was linked directly to FUSE-T 1.2.9 and did not read backing files or modify the target volume. As the logged-in user (UID 501; no sudo), create a new empty directory on an external APFS volume. Start a bounded unified-log capture for fskitd, sandboxd, and tccd, then run: ./hello -f -o backend=fskit <empty-directory-on-external-volume> Observe the mount failure and preserve the same-window logs. Actual result The FUSE process exits 1 and prints: fuse: mount failed with error: -1. No mount is created at the test path. fskitd finds/starts the FSKit extension instance and reaches “will mount over LIFSv2”. The final mount(2) fails with errno 1 (EPERM / “Operation not permitted”). The TCC events below occur at the same timestamp as the mount(2) error. No permission prompt is shown to the logged-in user. Timestamp-correlated attribution and authorization evidence At 18:47:31.793, fskitd enters the LiveFS mount path. At 18:47:31.801, tccd records the relevant attribution chain: accessing={TCCDProcess: identifier=com.apple.fskitd, pid=36573, auid=0, euid=0, binary_path=/usr/libexec/fskitd} requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=472, auid=0, euid=0, binary_path=/usr/libexec/sandboxd}At 18:47:31.824, TCC logs a platform-binary prompting policy of Deny. In this trace that message is associated with a separate SystemPolicyAllFiles check; the All Files result is not being presented as the final Removable Volumes denial. At 18:47:31.829, sandboxd checks kTCCServiceSystemPolicyRemovableVolumes for fskitd. Because the audit token has auid=-1, sandboxd routes the authorization request based on euid 0 to com.apple.tccd.system. The request includes fskitd’s audit token (pid 36573, auid -1, euid 0). The system tccd endpoint returns an invalid XPC connection / an empty reply without auth_value. The relevant messages are: sandboxd: checking kTCCServiceSystemPolicyRemovableVolumes for fskitd sandboxd: auid = -1; routing based on euid (0) instead tccd: REQUEST ... tccd_uid=0 ... service=kTCCServiceSystemPolicyRemovableVolumes sandboxd: RECV ... { count = 0 ... contents = } sandboxd: Error ... Code=2 "missing 'auth_value' in reply message" tccd: XPC forwardMessage error: Connection invalid tccd: sending empty reply ... auth_value absent sandboxd: kTCCServiceSystemPolicyRemovableVolumes denied by TCC for fskitd fskitd: mount(2) error: 1 fskitd: mount launch failed with result "Operation not permitted"The same EPERM/TCC failure was seen in earlier diagnostic attempts and again in this fresh invocation; this run provides the full timestamp-correlated attribution capture. It happens before a successful mount. The captured report contains the exact log lines selected from the bounded unified-log stream. Expected behavior / questions for Apple Is kTCCServiceSystemPolicyRemovableVolumes expected to authorize the final LIFSv2 mount performed by fskitd when a client asks to mount over a directory on external APFS? For a root system daemon with auid=-1, should sandboxd route this request to com.apple.tccd.system? Why does that endpoint return an invalid connection / empty reply rather than an authorization result? What is the supported authorization flow for this case? Should a user-consent prompt be shown to the initiating application, or should the system broker authorize fskitd using the caller’s audit token or security-scoped destination access? If this mount operation is unsupported by design, could the documentation or returned error distinguish that policy from a generic EPERM? Impact FSKit-based user-space filesystems cannot mount into an existing folder on this external APFS volume, despite the empty mountpoint being owned by the user and despite the FSKit extension loading successfully. This blocks applications that must expose a virtual filesystem at the user-selected original folder. The failure is in the system mount / authorization path; the minimal filesystem does not implement writes or access external backing data. Limitations This reproduction establishes the behavior on one Apple-silicon Mac, macOS 27.2 (26B123), FUSE-T 1.2.9, and one external APFS volume. It does not establish whether this is a general macOS defect, a machine-specific TCC daemon condition, or an intentional policy with a broken authorization response. The cause of com.apple.tccd.system’s invalid XPC reply remains unknown.

Apple feedback FB25355124 The SMB client no longer accepts reads to symlinks that are an absolute path to a network volume or a symlink that contains a (..) in the relative path. Reproduction steps on an SMB mount with this file structure: dir a.txt Run this command from inside of "dir": ln -s my-link ../dir/a.txt Attempt to read that symlink: cat ./my-link Which results in this error: cat: link: Invalid argument which is translating to an EINVAL getting returned from the SMB client. Same behavior was observed when making a symlink with an absolute path: ln -s my-link /Volumes/Example/dir/a.txt The server is responding successfully to the IOCTL command but the client is still rejecting the request with that error. This behavior was not observed in macOS 26.6.2 (smbfs 6.0.1) as well as previous versions of macOS.

We are investigating a severe BLE extended-advertising discovery issue on an iPhone 17 running iOS 27.2 (24B119). The phone fails to discover our peripherals approximately 90–95% of the time, based on our testing estimate. On rare occasions discovery succeeds, and the peripheral can then be connected. We have filed FB25463740, with diagnostic captures and a comparison of successful and failing behavior. Earlier iOS behavior Extended-advertising discovery and connection worked without issues in our previous iOS 26 testing. Failures became apparent with iOS 27, with behavior varying by iPhone model. We do not have a verified iOS 26 baseline for this particular iPhone 17, so we are treating an OS regression as a possibility rather than a confirmed cause. Test configuration Affected phone: iPhone 17, iOS 27.2 (24B119). Working comparison: iPhone 16, also running iOS 27.2 (24B119). Advertising: extended advertising with a 1M primary PHY, 2M secondary PHY, and 31-byte advertising data. Scanning: nRF Connect in the foreground, without a service UUID filter. Both phones were near the same powered-on peripherals, with advertising configuration unchanged during the comparison. Observed behavior The iPhone 16 discovers the extended-advertising peripherals. The iPhone 17 usually does not, even while discovering other nearby BLE devices. Switching the peripherals to legacy advertising provides reliable discovery on the tested iPhone 17. When extended-advertising discovery does succeed, connection works. The issue reproduces in nRF Connect as well as our application. What the captures show During failing foreground scans, the iPhone 17 receives thousands of legacy advertising reports, but neither target peripheral appears in its HCI packet log. A later capture contains rare successful extended-advertising receptions from both peripherals. These reports contain the same 31-byte payloads received by the working iPhone 16 and identify the secondary PHY as 2M. That capture also records a successful connection using 2M in both directions. Successful and failing scans occur on the same iPhone 17 with identical checked scan-start command sequences. The commands complete successfully. This does not establish that all internal controller state is identical. Wi-Fi disconnection preceded one successful period, but repeating that action did not reproduce success. We have not established Wi-Fi coexistence or primary-to-auxiliary timing as the cause. Questions Has anyone observed similar extended-advertising discovery failures on iPhone 17 or other models running iOS 27? If so, which phone models, iOS builds, peripheral chipsets, and advertising PHYs are involved? Does legacy advertising remain reliable? Are there any known issues or supported workarounds for this behavior? For Apple engineering, FB25463740 includes captures covering both successful and failing periods that may help distinguish reception, auxiliary-channel scheduling, and reporting/filtering problems.

How do I conect Gatt over ble(not Gatt over br/edr) when classic connected ? My device must use ANCS by ble transport and A2DP/HFP by classic transport.

We are designing a local, non-login service account provisioning process on macOS using the public Open Directory API. The documentation for ODNodeCreateRecord() states that if setting an initial attribute fails, the record is deleted and an error is returned. We need to ensure that a failed creation attempt cannot delete or modify a pre-existing record, including during concurrent record creation or replacement. Questions: When attribute initialization fails, is the internal cleanup guaranteed to target only the record instance created by that specific API call, rather than another record with the same name? Is this cleanup bound to a unique record identity or UUID, including if another process concurrently creates, removes, or replaces a record with the same name? Does the public API provide an atomic create-only guarantee that prevents changes to an existing record? If these guarantees are not provided, what supported API or provisioning approach should be used to avoid affecting pre-existing local Directory Services records? Our current plan uses the local /Local/Default Directory Services node for a dedicated service account, administrative change serialization, pre-creation collision checks, and post-operation identity verification. We understand that these checks do not themselves prove atomicity or race-free cleanup. We would appreciate clarification of the supported API guarantees, specifically for macOS 15. Thank you.

What supported public contract should software use for com.apple.provenance when copying an exact expected helper binary into a new, private owner-controlled working directory for separately authorized later use? We want to leave originals unchanged, preserve security protections, and avoid removing, decoding or reconstructing opaque Apple attribute values. Program-byte identity, permissions/custody and code validation are separate from this metadata question; an attribute name or copy success is not treated as a trust decision. Public APIs reviewed: fcopyfile with independent DATA/XATTR selection, and xattr_flags_from_name with xattr_intent_with_flags for COPY intent. A bounded public-constant probe returned zero property flags and the default preserve result for both com.apple.provenance and an invented unknown name. We therefore do not interpret that default as proof of recognition or an exemption. Could you clarify: Which supported metadata postconditions apply to this specific copy use? Is source/destination raw-value equality an appropriate invariant for this opaque attribute, or may the OS legitimately create different destination metadata while preserving the intended security behavior? Which public properties or APIs can establish the intended destination state without parsing/removing private values or weakening OS protections? The xattr manual's named-wrapper return sentence appears inconsistent with its flags-based description/example. What is the supported return-polarity contract, and is using the flags-based function the intended interpretation? This asks for supported semantics, not a bypass or private value format. No paths, binaries, source, attribute values, keys, account data or logs are attached. Public references: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fcopyfile.3.html https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_name_with_flags.3 https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_flags.h

On macOS 26.5.2 (build 25F84), which documented API and return conditions, if any, establish that a regular file on APFS has no extended access control list (ACL), using an already-open file descriptor? We tested three disposable regular files on an APFS volume reporting ACL support. For each file, we opened a read-only file descriptor and called: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY Before and after inspection, fstat() confirmed stable device, inode, mode, and change timestamp. Observed results: 1. Newly created file, no ACL explicitly assigned acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() succeeded but omitted ATTR_CMN_EXTENDED_SECURITY from the returned attribute mask. FSOPT_PACK_INVAL_ATTRS also left that bit clear. 2. File with an explicitly assigned empty ACL acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() returned the extended-security attribute with an ACL entry count of zero. 3. File with one explicit ACL entry acl_get_fd_np() returned a non-null ACL. fgetattrlist() returned the extended-security attribute with an ACL entry count of one. Apple's published XNU attribute-packing implementation appears to use the same omission branch when ACL metadata is unsupported or when the ACL pointer is null. My question: Is there a supported descriptor-based API sequence that reliably distinguishes: Genuine absence of an extended ACL Unavailable or unsupported per-file ACL metadata An ACL retrieval failure If so, which API, capability checks, return values, attribute bits, or error conditions should a caller rely on? Are there relevant APFS or macOS version limitations? If the public API cannot establish ACL absence unambiguously in this situation, confirmation of that limitation would also be helpful. Thank you for your guidance.

We are implementing a fail-closed security check for a directory opened through a file descriptor on macOS. We need to reliably distinguish between: No extended ACL is present. An extended ACL is present but contains zero entries. ACL retrieval failed or is unsupported. Observed behavior For an existing directory with mode 0700: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. acl_get_file(path, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. fstat() and lstat() agree on the device and inode. The directory exists and can be opened successfully. ls -ldeO@ displays no extended ACL entries. We reviewed Apple's open-source implementations of acl_get_fd_np() and filesec_get_property(). We understand that ENOENT can result from an unavailable FILESEC_ACL property, rather than a missing filesystem object. We also understand that XNU distinguishes an empty ACL from KAUTH_FILESEC_NOACL. Question Is there a publicly supported, file-descriptor-based API with documented postconditions that can reliably prove the absence of an extended ACL, while distinguishing it from an empty ACL and an ACL retrieval failure? Specifically: Can fstatx_np() and filesec_get_property() provide this distinction? Can fgetattrlist() with ATTR_CMN_EXTENDED_SECURITY and ATTR_CMN_RETURNED_ATTRS reliably establish ACL absence? What additional filesystem capability checks or return-value checks are required? If no public API provides this guarantee, is that a documented limitation? For security reasons, our implementation rejects the object whenever ACL absence cannot be established reliably. We would appreciate clarification of the supported API contract and its limitations. Thank you.

On macOS I am creating a public/private key pair (ECDSA 256), will be secure enclave in the long run, just trying to baseline some functionality right now using file store (currently running in a system daemon). I can sign data using the private key with no problem, and export the public key. However, after generating a cert chain via CSR externally, I’m trying to figure out the proper incantation to import that cert/chain and have it recognized as matching the existing private key, but so far I can’t figure out the correct attributes to get it to pair up. Do you have any sample code that might have the right SecAddItem (or such) calls that would make this work as expected?

Hello, We develop a sandboxed Mac App Store app that runs virtual machines with Virtualization.framework on Apple silicon (macOS 27). Users want to install a macOS guest onto an external USB disk and start the VM from it, so they can keep a VM on portable storage or on a disk larger than the Mac's internal drive. What we tried USB passthrough: we attach the disk before the VM starts, with VZUSBPassthroughDeviceConfiguration (from an AAUSBAccessory) on a VZXHCIControllerConfiguration. Linux guests install onto the disk and boot from it without problems. For a macOS guest, VZMacOSInstaller fails to start when the USB disk is the only storage: As we understand it, a macOS VM can only start from its own storage devices, never from a USB device, so even a successful install would not boot. VZDiskBlockDeviceStorageDeviceAttachment: this needs an open file handle to /dev/diskN. That requires admin rights, which a sandboxed app can't obtain, so we can't use it in our App Store app. Questions Is there a supported way to install a macOS guest onto an external USB disk and start the VM from it? Is there a sandbox-compatible way to get a VZDiskBlockDeviceStorageDeviceAttachment for an external disk, for example after user consent, similar to how AccessoryAccess grants USB devices? If neither is possible today, is support for this planned, or is there a recommended alternative? Thank you for any guidance.

Is there an Apple-supported way on macOS 15.6 to run a sandboxed local storage service under a dedicated non-root user account, with a sandboxed SwiftUI client and administrator-authorized installation?

Our (sandboxed, distributed through the Mac App Store) app can optionally run as a CLI tool, to allow users to use it in scripts and other automation contexts. One of the usecases involves being a wrapper for the ssh command, but the ssh binary is not able to enable raw mode for stdin due to a sandbox violation (bug report). As a reduced example, I've created https://github.com/mihaip/sandboxed-cli-test, which has a minimal C program that uses tcsetattr to set attributes on stdin. That fails, and sandboxd logs to the console Sandbox: SandboxedCLI(30110) deny(1) file-ioctl /dev/ttys012. If I disable sandboxing on the binary then it works as expected. Looking through the sandbox profiles on /System/Library/Sandbox/Profiles, I'm not seeing cases where file-ioctl is enabled on /dev/tty. Are we out of luck, or is there a workaround?

Apple Support directed me to the Developer Forums for this API-contract question. I am implementing conservative, read-only ACL classification for existing files and directories. I need to distinguish an absent ACL from unavailable or incomplete ACL information. Ambiguous results are currently rejected. The measurements below were taken on macOS 26.5, build 25F71, Apple Silicon (arm64), on APFS. Method I tested eight newly created objects: a regular file and a directory in each of four preparation states: Fresh: no ACL setter, deletion or normalization was performed. Explicit-empty ACL preparation. One DENY entry. One ALLOW entry. “Fresh” describes preparation only; I am not assuming it independently proves ACL absence. Each object remained open through preparation and two observations using the same file descriptor. Each observation performed: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Errno was cleared immediately before each query and captured immediately afterward. Descriptor/path identity and metadata stability were checked. Returned lengths, attribute bitmaps and applicable reference/payload bounds were validated. Observations Results matched between the two observations and between regular files and directories: Preparationacl_get_fd_np resultfgetattrlist returnEXTENDED_SECURITY returnedReturned filesec ACE countAttribute-buffer lengthFreshNULL, errno ENOENT0NoN/A32 bytesExplicit-emptyNULL, errno ENOENT0Yes076 bytesOne DENY entryNon-NULL, errno 00Yes1100 bytesOne ALLOW entryNon-NULL, errno 00Yes1100 bytesWhen the getter returned NULL, ACL validation and enumeration were not performed; their results are N/A, not measured zeros or an empty entry list. When EXTENDED_SECURITY was omitted, its payload fields were unavailable. I did not interpret default buffer values as returned ACL information. An actually returned zero-entry record is distinct from omission. No NOACL sentinel was observed in this experiment. Question For a valid descriptor referring to an existing APFS object, what is the supported interpretation of: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returning NULL with ENOENT; and fgetattrlist() succeeding while omitting ATTR_CMN_EXTENDED_SECURITY from the returned attribute bitmap? In particular: Can this combination establish ACL absence under documented conditions, or must it remain classified as unavailable/ambiguous information? How should the observed NULL/ENOENT with an actually returned zero-entry ACL record be interpreted? If these results cannot establish absence, which supported read-only, descriptor-based API or verification sequence should be used? What guarantees and limitations apply regarding macOS versions, filesystem support and genuine retrieval failures? I reviewed the acl_get(3) documentation but could not find a clear explanation of this valid-descriptor ENOENT case: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get.3.html I am seeking the supported API contract, not asserting an OS defect or vulnerability. I do not want to set, delete or normalize ACLs on the objects being inspected, or treat an ambiguous result as success.

Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified. I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object. One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL. I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results. Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract. For this reported configuration: Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished? With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation? When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification? Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state. References consulted: Apple's ACL getter manual Apple Libc-1507.100.9 ACL getter source Apple xnu-8020.140.41 attribute manual

An app built with Xcode 27.1 for a macOS 15 deployment target called Logger.isEnabled(type:). In the SDK's swiftinterface the method sits under Logger's @available(macOS 11.0, ...) with no availability of its own, so it compiled without a warning. On macOS 15.6.1, libswiftos.dylib doesn't export it, and dyld stopped the app at launch: Symbol not found: _$s2os6LoggerV9isEnabled4typeSbSo0a5_log_E2_ta_tF Expected in: /usr/lib/swift/libswiftos.dylibThe macOS 15.5 SDK's libswiftos.tbd doesn't list the symbol and the 27 SDK does. I haven't checked macOS 26. Switching to OSLog.isEnabled(type:) fixed it. Which macOS version first exports this symbol? Write-up: https://yardlet.app/blog/logger-isenabled-macos-15.html

Hi, We are seeing a reproducible system reboot (appears to be a kernel panic) on MacBook Neo when a third-party USB UVC camera device is opened in Photo Booth. The same setup works on another Apple Silicon Mac running the same OS version. Environment Mac: MacBook Neo, model A3404 macOS: 27.0.1 App used to open the camera: Photo Booth (system app) Device under test: our USB dongle presents a UVC composite device named "Room Camera" (USB Video Class gadget / USB camera backhaul from a room camera) Related hardware: room camera (Focus100) is attached behind an AV receiver/USB hub path, then redirected to the Mac through the dongle as a standard UVC device Our companion Mac app was uninstalled for verification; the reboot still happens, so this does not appear to depend on our app or CMIO camera extension Reproduction steps Connect the dongle to MacBook Neo A3404. Confirm that "Room Camera" is visible as a camera source. Open Photo Booth. Switch the camera source to "Room Camera". Observed result The Mac reboots immediately (100% reproducible on this Neo unit). Expected result Photo Booth should open the UVC stream normally without crashing the system. Control / comparison Same OS version (macOS 27.0.1) on MacBook Pro A3412 (M5): no reboot, camera works. Uninstalling our Mac app does not change the Neo behavior (still reboots). This suggests a host-side issue specific to MacBook Neo when starting this UVC stream (or a Neo USB/UVC host stack sensitivity to our device descriptors / isochronous stream), rather than an application-level bug in our software. Questions Are there known MacBook Neo / macOS 27 issues with external UVC devices that can cause kernel panic when a camera app (Photo Booth / FaceTime / Zoom) starts streaming? Which panic log / sysdiagnose artifacts are most useful for Apple to triage this (and which subsystem tags should we look for, e.g. UVCService / IOUSBHost / AppleUSB)? Are there known stricter UVC descriptor / configuration / bandwidth requirements on Neo versus other Apple Silicon Macs that we should validate on the gadget side? We can provide: panic reports from ~/Library/Logs/DiagnosticReports/ sysdiagnose USB device tree / IORegistry information for the UVC interface a Feedback Assistant report number if recommended Thanks for any guidance.