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!

our app has a helper to perform privileged operations which communicates with the main app via xpc_connection* previously that helper was installed via SMJobBless() into the /Library/LaunchDaemons/ and /Library/PrivilegedHelperTools/ due to various issues with the old SMJobBless() as well as it being deprecated we have ported the helper to the new SMAppService API where the helpers do not need to be installed but remain within the app bundle ( [[SMAppService daemonServiceWithPlistName:HELPER_PLIST_NAME] registerAndReturnError:&err] ) the new approach has been used in production for a year now and works fine in most cases and seems to be more reliable than the old SMJobBless(). however, we've observed two problems with the new helper architecture. • sometimes when users update the app (with the built-in Sparkle framework), the app does not seem to have FullDiskAccess, although the checkbox in the system settings remains toggled on. only once the Mac has been restarted, things work fine again. since this is cured by a reboot, lets ignore this issue • on some Macs, it just seems impossible to use the helper, while "installation" via SMAppService runs fine without error, using the helper always just fails with Connection invalid. This issue seems to affect ~0.2% of our users Macs, and we have found no cure yet how to get things into a working state on those Macs. luckily the issue also occurs 100% reproducible on one of the Macs in our office now. the problem seems to be a regression in macOS 26, as things worked absolutely fine on all previous macOS versions. we'd like to investigate why the helper just won't work on some Macs. unfortunately even enabling Console logging for just a few seconds yields thousands of messages nowadays, but this may be insightful: we found that on the "bad Mac", the "FATAL ERROR - fullPath is nil" always appears and subsequently no working XPC connection to the helper is ever established. on the "good Macs", this "fullPath is nil" error never appears, and the XPC connection works fine after all the required permissions (helper permission, FDA permission) are granted. so, my questons: • has anyone else seen a problem where a SMAppService / XPC based priviledged helper just won't work on a handful of Macs? • what about the "FATAL ERROR - fullPath is nil", is this the real root cause of the issue or should we look somewhere else? how can we prevent the issue on the affected Macs? the only thing that seems to be clear here is that this is a macOS 26 Tahoe bug.

I'm working on a command line tool, and trying to make it as fast as possible. I ran it under instruments' processor trace (really cool tool by the way, thanks for that) and found that the majority of the time it is taking to run, is actually spent in dyld, specifically dyld4::prepare(dyld4::APIs&, mach_o::Header const*). Out of a total run time of 1.27ms my code only takes 34.17μs or about 2.7%, that's a LOT of overhead! I re-ran my binary with the dyld activity instrument added to the mix, and it showed that the biggest known chunk of time that dyld spends during process startup is in "Run static initializer" from libSystem, though the majority of the time spent by dyld is unaccounted for and left labelled generically as "Launch Executable". Obviously I can't modify libSystem on my users' systems so is there anything I can do to reduce this overhead? Maybe some way to promise that I won't use the Obj-C runtime so that doesn't need setting-up or something?

Hi! I was able to successfully persist my debug log entires using the OSLogPreferences key in my Info.plist and retrieve the logs from my iPhone using log collect. This worked to get log messages created when my app executed a background task tonight (2026-01-20 00:20). But log Debug and Default log messages from a normal run yesterday (2026-01-19 15:34) disappeared. I can query for the missing messages in the log archive I created yesterday but they are missing in the log archive I created today covering also yesterday. I had invoked: % sudo log collect --device-name "<my device name>" --last 25h --output /tmp/system_logs.logarchive ... %sudo log show /tmp/system_logs.logarchive --debug --info --predicate 'subsystem=="com.example.MyApp"' Is this expected and/or is there anything I could do to persist the logs for a longer period? For reference, that's what I have added to my Info.plist for the debug build configuration so far: <key>OSLogPreferences</key> <dict> <key>com.example.MyApp</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Level</key> <dict> <key>Enable</key> <string>Debug</string> <key>Persist</key> <string>Debug</string> </dict> <key>Enable-Private-Data</key> <true/> </dict> </dict> </dict>

There will be a cloud download icon on the folder, and when I click download, I will go to download the file below. Then this icon will disappear, but when I move a dataless file into the folder, the cloud download icon will appear again. I understand if there is any way to determine whether the folder has downloaded properties

I am developing an iOS/iPadOS application and have encountered some behavior regarding Files App and security-scoped bookmarks that I would like to clarify. Additionally, I would like to report some behavior which might include a potential issue. Question1: Accessing deleted files via bookmark (Specification clarification) Our app saves file URLs as bookmarks, which file that user has selected on Files App or app-created so to open a file which user has modified previously in the next launch. When a user deletes a file in Files App (moves a file to Recently Deleted), the app can still resolve the bookmark and access the file for read/write operations. Is this behavior intended? In other words, is it correct that a bookmark can access a file that has been deleted in Files App but not permanently removed? Question2: Overwriting a file in Recently Deleted (Potential bug) We noticed that overwriting a file in Recently Deleted behaves differently depending on the method used. Current implementation 1.Create a temporary file in the same directory 2.Write content to the temporary file 3.Delete the original file ([NSFileManager removeItemAtURL:error:]) 4.Move the temporary file to the original file path ([NSFileManager moveItemAtURL:toURL:error:]) Result: The file disappears from Files App Recently Deleted. In contrast, using [NSFileManager replaceItemAtURL:withItemAtURL:] keeps the file visible in Recently Deleted. Is this difference designed behavior? If not, this may be a bug. Question3: Detecting files in Recently Deleted We want to detect whether a file resides in Recently Deleted, but we cannot find a reliable and officially supported method. Recently Deleted files appear under .Trash, but using the path alone is not a reliable method. We have tried the following APIs without success: [NSURL getResourceValue:forKey:NSURLIsHiddenKey error:] [NSURL checkResourceIsReachableAndReturnError:] [NSFileManager fileExistsAtPath:] [NSFileManager isReadableFileAtPath:] [NSFileManager getRelationship:ofDirectory:NSTrashDirectory inDomain:NSUserDomainMask toItemAtURL:error:] We could not obtain the Recently Deleted folder URL using standard APIs. [NSFileManager URLsForDirectory:NSTrashDirectory inDomains:NSUserDomainMask] [NSFileManager URLForDirectory:NSTrashDirectory inDomain:NSUserDomainMask appropriateForURL:url create:error:] Could you advise a safe and supported way to detect Recently Deleted files properly by the app?

I understand that private APIs are not permitted under Apple’s App Review Guidelines. However, our application requires I²C communication, and we are currently using the following APIs: IOAVServiceReadI2C IOAVServiceWriteI2C IOI2CSendRequest.These api's are not permitted by apple. I didnt found any alternative public api to achieve I²C communication. please suggest any public api's for the same or any chance to use this private api.

Since the introduction of the siblings / and /System/Volumes/Data architecture, some very basic, critical commands seems to have a broken behaviour ( cp, rsync, tar, cpio…). As an example, ditto which was introduced more than 10 years ago to integrate correctly all the peculiarity of HFS Apple filesystem as compared to the UFS Unix filesystem is not behaving correctly. For example, from man ditto: --rsrc Preserve resource forks and HFS meta-data. ditto will store this data in Carbon-compatible ._ AppleDouble files on filesystems that do not natively support resource forks. As of Mac OS X 10.4, --rsrc is default behavior. [...] --extattr Preserve extended attributes (requires --rsrc). As of Mac OS X 10.5, --extattr is the default. and nonetheless: # ls -@delO /private/var/db/ConfigurationProfiles/Store drwx------@ 5 root wheel datavault 160 Jan 20 2024 /private/var/db/ConfigurationProfiles/Store                            ********* com.apple.rootless 28 *************************** # mkdir tmp # ditto /private/var/db/ConfigurationProfiles tmp ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Settings: Operation not permitted ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Store: Operation not permitted # ls -@delO tmp/Store drwx------ 5 root wheel - 160 Aug 8 13:55 tmp/Store                            * # The extended attribute on copied directory Store is empty, the file flags are missing, not preserved as documented and as usual behaviour of ditto was since a long time ( macOS 10.5 ). cp, rsync, tar, cpio exhibit the same misbehaviour. But I was using ditto to be sure to avoid any incompatibility with the Apple FS propriaitary modifications. As a consequence, all backup scripts and applications are failing more or less silently, and provide corrupted copies of files or directories. ( I was here investigating why one of my security backup shell script was making corrupted backups, and only on macOS ). How to recover the standard behaviour --extattr working on modern macOS?

I'm scanning for peripherals, and keep references to multiple CBUUIDs - one for each peripheral. I then start a connection to the peripheral. I never get a callback to say the connection succeeded, failed, or disconnected. I have a Mini-Moreph Bluetooth sniffer. The sniffer shows that the iPhone never tried to connect to any of the peripherals. The iPhone HCI logs show that a create connection request was sent, but a cancel connection request was sent 0.018 seconds later. No feedback was given to my application through CoreBluetooth. I've filed this through Feedback Assistant, but expect nothing will come of the report.

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.

SMBClient-593 introduces a crtitical bug. When reading and writing data at high volume, the SMBClient no longer properly receives and handle responses from the server. In some cases, the client mishandles the response packet and the following errors are seen in the logs: 2025-12-02 21:36:04.774772-0700 localhost kernel[0]: (smbfs) smb2_smb_parse_write_one: Bad struct size: 0 2025-12-02 21:36:04.774776-0700 localhost kernel[0]: (smbfs) smb2_smb_write: smb2_smb_read_write_async failed with an error 72 2025-12-02 21:36:04.774777-0700 localhost kernel[0]: (smbfs) smbfs_do_strategy: file.txt: WRITE failed with an error of 72 In other cases, the client mishandles the response packet and becomes completely unresponsive, unable to send or receive additional messages, and a forced shutdown of the computer is required to recover. This bug is only present on macos 26. We believe the operative change is in the latest commit, SMBClient-593 beginning at line now 3011 in smb_iod.c. The issue seems to be a race, and occurs much more frequently once throughput exceeds around 10Gbps, and again more frequently above 20Gbps.

Hello, We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs. The Change Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device. Our Workflow We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices. This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM. The Challenge With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts: New team members who spin up VMs for the first time and can't run signed builds Our CI/CD pipeline where multiple test environments need provisioning profiles Developers testing different branches who need separate clean environments Current Workaround We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward. If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds. We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable. Question Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates. Thanks for any guidance you can provide! Feedback case: FB21389730

I have an iOS and macOS app that includes a file provider extension. on macOS is is perfect no issues anywhere. on iOS it works for small datasets or if I do read only operations. as soon as I try to do anything with larger files I quickly hit the 20MB limit. I have solved file transfers by using chunking but when it comes to listing a folder with a couple thousand files it instantly crashes the FPE with an OOM error. works ok up to 100 files but anything beyond that crashes. I know enumerate items supports batches however the initial load form say a webdav server that has no concept of pagination will always fail to load in pieces no matter what I do. This likely explains why WebDAV was never implemented on iOS. in any case can you possibly consider upgrading the memory limit for FPE's or provide some mechanism to call our full iOS app for more processing power in the background to handle requests on demand? I do not understand where 20MB is a reasonable number. even 100MB seems more reasonable with everything have much more memory these days this seems incredibly limiting. even an option to request increased memory with a capability would be fine but that only works for the app itself not the FPE target. please advise if there is anything that can be done.

Hi everyone — I’m hoping to get a quick technical sanity check from folks familiar with Apple’s satellite features. I’ve put together a very narrowly scoped request around the temporary enablement of existing iPhone satellite capabilities (Emergency SOS / Messages via Satellite), focused on a simple “check-in” use case. The idea is intentionally minimal: preset status messages only (e.g. “I’m safe”, “I need help”) optional one-time location sharing strict rate limits temporary enablement with a clear sunset date This isn’t a request for new features, internet access, voice, or emergency-service integration — it’s framed as a configuration/policy enablement using systems Apple already operates. I’ve documented the full scope and assumptions here Posting mainly to invite technical review, correction, or perspective from anyone familiar with how the satellite stack is structured today. Appreciate any insights.

I am developing a utility application for macOS. In the next version, I would like to access data files from multiple third-party web browsers. However, requiring users to manually select and grant access to each browser’s folder individually would be inconvenient from a usability perspective. Therefore, I am considering requesting Full Disk Access for my app. Is it realistic to expect App Store review approval when requesting Full Disk Access? Under what conditions or use cases is such permission typically accepted by Apple? I would greatly appreciate any advice or experiences you can share.

I. am working on an app that uses automounted files using nfsv4 where the server has zfs filesystems. As a test I've created a very simple example and the directory in question seems to automount correctly, but when I try to access it, I get strange behavior. The directory is mounted on is /System/Volumes/Data/mnt/subdir and I can change to that directory just fine. However I get the following: 63 rrsum@Anywhere:subdata% pwd /System/Volumes/Data/mnt/subdata 64 rrsum@Anywhere:subdata% ls -la total 3 drwxr-xr-x 3 nobody nobody 4 Jan 10 13:03 . dr-xr-xr-x 3 root wheel 2 Jan 8 17:27 .. drwxr-xr-x 2 nobody nobody 3 Jan 9 11:20 dir -rw-r--r-- 1 nobody nobody 12 Jan 10 13:09 file.txt 65 rrsum@Anywhere:subdata% cd dir cd: string not in pwd: ls The directory appears in the 'ls -la' properly, but I cannot cd to it.

https://developer.apple.com/documentation/NetworkExtension/filtering-network-traffic App example not auto reconnect after network extension crush. what need to add for auto reconnect when network extension restart?

So I'm aware that Apple can designate a folder as a "data vault", and access to that folder is limited to applications that have a specific entitlement. I was wondering if there was an equivalent (or the same, I'm not fussy :) feature available to third parties, even if only during the app-store submission ? To avoid the X-Y problem, what I want to do is have a launch agent with access to a SQLite database, and I want only that launch agent to have access. Any reads of the database will have to be done through an XPC call from the main user-facing application. I want to store private data into that database, and I don't want there to be any way for any other application to read it. If there's a way to do that without data-vaults I'm all ears :) I'm not sure if this is really the right place, perhaps the core-os forum would be better, but since the Apple solution is gate-kept by entitlements, I thought I'd start here :)

I am adding NSFileProviderPartialContentFetching support to an existing NSFileProviderReplicatedExtension. My backend has a high "Time To First Byte" latency (approx. 3 seconds) but reasonable throughput once the connection is established. I am observing a critical behavior difference between Partial Content Fetching and standard Materialization that causes sequential reads (e.g., dd, Finder copies, Adobe apps) to fail with timeouts. The Scenario: I have a 2.8 GB file. I attempt to read it sequentially using dd. **Baseline (Working): Partial Fetching Disabled ** I do not conform to NSFileProviderPartialContentFetching. The system triggers fetchContents(for:version:request:completionHandler:). My extension takes 3 seconds to connect, then streams the entire 2.8 GB file. Result: Success. The OS waits patiently for the entire download (minutes) without timing out, then dd reads the file instantly from the local disk. **The Issue: Partial Fetching Enabled ** I add conformance to NSFileProviderPartialContentFetching. The system requests small, aligned chunks (e.g., 16KB or 128KB). My extension fetches the requested range. This takes ~3 seconds due to network latency. The first few chunks succeed, but shortly after, the operation fails with Operation timed out. It appears the VFS kernel watchdog treats these repeated 3-second delays during read() syscalls as a stalled drive and kills the operation. **My Questions: ** Is there a documented timeout limit for fetchPartialContents completion handlers? It seems strictly enforced (similar to a local disk I/O timeout) compared to the lenient timeout for full materialization. Is NSFileProviderPartialContentFetching inherently unsuitable for high-latency backends (e.g., cold storage, slow handshakes), or is there a mechanism to signal "progress" to the kernel to reset the I/O watchdog during a slow partial fetch? Does the system treat partial fetching as "Online/Direct I/O" (blocking the user application) whereas full fetch is treated as "Offline/Syncing" (pausing the application), explaining the difference in tolerance? Any insights into the VFS lifecycle differences between these two modes would be appreciated.

I face this issue only on macOS 26 and only on the Intel architecture. I'm unable to download files from a file provider's folder when I make them read-only. STEPS TO REPRODUCE Download the sample from https://developer.apple.com/documentation/fileprovider/synchronizing-files-using-file-provider-extensions?language=objc Follow the steps on the page to configure the project. Build the project. Run it. Add a domain. Open the domain's folder in the Finder. Move a file to the domain's folder. Right-click on the file in the domain's folder and select "Remove Download". Close the Finder's window with the domain's folder and kill all the "Provider" processes to get rid of running instances of the extension. Change Item's capabilities in Item.swift to make the items read-only: var result: NSFileProviderItemCapabilities = [ .allowsContentEnumerating, .allowsReading ] Rebuild the project and run it. Open the domain's folder and try to drag and drop the file from the extension's folder to, let's say, the Desktop folder. EXPECTED RESULT The file is copied ACTUAL RESULT A dialog pops up with text "The file “filename” cannot be downloaded. Do you want to skip it?" Stop/Skip