Explore the core architecture of the operating system, including the kernel, memory management, and process scheduling.

Posts under Core OS subtopic

Post

Replies

Boosts

Views

Activity

Core OS Resources
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"
0
0
610
Aug ’25
26.4 beta and RC versions are unable to be created on anything but 26.4 beta host OS
We're trying to create 26.4 beta and RC VMs on 15.x and 26.3 host OS' without success. We see Tue Mar 17 17:27:36 40 anka.log (install) 45803: failed to install macOS: Error Domain=VZErrorDomain Code=10006 "Installation requires a software update." UserInfo={NSLocalizedFailure=A software update is required to complete the installation., NSLocalizedFailureReason=Installation requires a software update.} Yet, if we create it the same way on 26.4 beta host OS, it works. We've tried the usual tricks of installing latest Xcode and preparing it (accepting license, etc). But, they don't work on 26.3 and 15.x. What's the trick to get the creation of 26.4 to work on <= 26.3 host OS?
4
2
197
13h
System-wide deadlock in removexattr from revisiond / APFS
System-wide deadlock in removexattr from revisiond / APFS We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Process: revisiond [426] UUID: 5E9B9E04-984B-31AD-A4FF-A1A90B7D53A1 Path: /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond Codesigning ID: com.apple.revisiond Shared Cache: 25AE5A2A-FE2A-3998-8D4E-F3C5C6E6CEB6 slid base address 0x189834000, slide 0x9834000 (System Primary) Architecture: arm64e Parent: launchd [1] UID: 0 Sudden Term: Tracked Memory Limit: 50MB Jetsam Priority: 40 Footprint: 6225 KB Time Since Fork: 1740319s Num samples: 940 (1-940) Num threads: 5 Note: 1 idle work queue thread omitted [...] Thread 0xc0616d 940 samples (1-940) priority 46 (base 4) last ran 241692.754s ago 940 start_wqthread + 8 (libsystem_pthread.dylib + 7068) [0x189d0ab9c] 940 _pthread_wqthread + 292 (libsystem_pthread.dylib + 11852) [0x189d0be4c] 940 _dispatch_workloop_worker_thread + 692 (libdispatch.dylib + 85356) [0x189b65d6c] 940 _dispatch_root_queue_drain_deferred_wlh + 292 (libdispatch.dylib + 87156) [0x189b66474] 940 _dispatch_lane_invoke + 440 (libdispatch.dylib + 45048) [0x189b5bff8] 940 _dispatch_lane_serial_drain + 944 (libdispatch.dylib + 42420) [0x189b5b5b4] 940 _dispatch_client_callout + 16 (libdispatch.dylib + 113364) [0x189b6cad4] 940 _dispatch_call_block_and_release + 32 (libdispatch.dylib + 7004) [0x189b52b5c] 940 ??? (revisiond + 168768) [0x10494d340] 940 ??? (revisiond + 165940) [0x10494c834] 940 ??? (revisiond + 40264) [0x10492dd48] 940 ??? (revisiond + 56680) [0x104931d68] 940 <patched truncated backtrace> 940 removexattr + 8 (libsystem_kernel.dylib + 23768) [0x189cd1cd8] *940 ??? (kernel.release.t6000 + 15240) [0xfffffe000886fb88] *940 ??? (kernel.release.t6000 + 1886348) [0xfffffe0008a3888c] *940 ??? (kernel.release.t6000 + 7730436) [0xfffffe0008fcb504] *940 ??? (kernel.release.t6000 + 2759592) [0xfffffe0008b0dba8] *940 ??? (kernel.release.t6000 + 2808244) [0xfffffe0008b199b4] *940 apfs_vnop_removexattr + 1044 (apfs + 474512) [0xfffffe000be8d4d0] *940 decmpfs_cnode_set_vnode_state + 80 (kernel.release.t6000 + 2945816) [0xfffffe0008b3b318] *940 IORWLockWrite + 184 (kernel.release.t6000 + 496184) [0xfffffe00088e5238] *940 ??? (kernel.release.t6000 + 494624) [0xfffffe00088e4c20] *940 ??? (kernel.release.t6000 + 619452) [0xfffffe00089033bc] *940 ??? (kernel.release.t6000 + 624472) [0xfffffe0008904758] The bulk of the other processes are waiting for that lock. (suspended, blocked by krwlock for reading owned by revisiond [426] thread 0xc0616d) (blocked by krwlock for writing owned by revisiond [426] thread 0xc0616d) Around the time of the event, these messages were logged by revision: 2026-03-06 18:49:37.781673-0500 0x16b7 Error 0x7f92f364 426 14 revisiond: [com.apple.revisiond:default] [ERROR] CSCopyChunkIDsForToken failed for 41639 2026-03-06 18:49:37.781716-0500 0x16b7 Error 0x7f92f365 426 14 revisiond: [com.apple.revisiond:default] [ERROR] updateEntry for new entry <private> failed 2026-03-06 18:49:37.781738-0500 0x16b7 Error 0x7f92f366 426 14 revisiond: [com.apple.revisiond:default] [ERROR] no entry for '<private>' 2026-03-06 18:49:37.781754-0500 0x16b7 Error 0x7f92f367 426 14 revisiond: [com.apple.revisiond:default] [ERROR] failed assembleInfoForOffset for fsid 16777234 fileid 359684022 offset 0 size 14334 (path <private>) Our agent uses Endpoint Security Framework to monitor events, and provide anti-tamper functionality for installed components and processes. While several EndpointSecurity calls appear in the spindump stack traces, we don't have any evidence that any calls from revisiond were blocked. What we'd really like to to understand what that lock is (appears to be decompressing an object on an APFS volume), what revisiond and APFS are doing with it, and what might cause it to deadlock. Of note, one of our processes is also waiting on that lock, one thread for reading and the other for writing. This issue affects machines running several macOS versions (15.x, 26.x). The machine in the examples is running macOS 26.3 (25D125)
2
0
103
40m
copyfile Sometimes Fails to copy .DS_Store when Copying a Folder But Does Not Report Usable Error
Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.
5
0
170
1d
FSKit passthrough sample fails to mount
After building the sample and enabling the file system extension the mount command is freezing. Any tips how to diagnose that? The logs show the following: log stream --style compact --info --debug --predicate 'subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"' Filtering the log data using "subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"" Timestamp Ty Process[PID:TID] 2026-03-17 15:15:51.832 I mount[16111:d88caa] [com.apple.FSKit:default] FSClient setting up connection to fskitd 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Incomming connection, entitled 0 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Hello FSClient! entitlement no 2026-03-17 15:15:51.834 Df mount[16111:d88caa] [com.apple.FSKit:default] Setting remote protocol to all XPC 2026-03-17 15:15:51.834 Df fskitd[589:d88a5f] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.834 I fskitd[589:d88a5f] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.835 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.836 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName () 2026-03-17 15:15:51.837 I fskitd[589:d88a5f] [com.apple.FSKit:default] Probe starting on 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager getResourceState:]:found: 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager addTaskUUID:resource:]:: Adding task () 2026-03-17 15:15:51.837 Df fskitd[589:d87c31] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.837 I fskitd[589:d87c31] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.837 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension , attrs 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] applyResource starting with resource kind 4
7
0
103
1d
filecopy fails with errno 34 "Result too large" when copying from NAS
A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error "Result too large". When copying the same files from the Desktop, it works. I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help. Both the app user and QNAP are willing to help, but at this point I'm also unsure how to proceed. Can someone at Apple say anything about this? Is this something QNAP should solve, or is this a bug in macOS? P.S.: I've had users in the past who reported the same issue with other brands, mostly Synology. import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.runModal() let source = openPanel.urls[0] openPanel.canChooseFiles = false openPanel.runModal() let destination = openPanel.urls[0] do { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } catch { NSAlert(error: error).runModal() } NSApp.terminate(nil) } private func copyFile(from source: URL, to destination: URL) throws { if try source.resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true { try FileManager.default.createDirectory(at: destination, withIntermediateDirectories: false) for source in try FileManager.default.contentsOfDirectory(at: source, includingPropertiesForKeys: nil) { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } } else { try copyRegularFile(from: source, to: destination) } } private func copyRegularFile(from source: URL, to destination: URL) throws { let state = copyfile_state_alloc() defer { copyfile_state_free(state) } var bsize = UInt32(16_777_216) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_DATA | COPYFILE_SECURITY | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_XATTR)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in if what == COPYFILE_COPY_DATA { if stage == COPYFILE_ERR { return COPYFILE_QUIT } } return COPYFILE_CONTINUE } }
19
0
487
2d
FileManager.replaceItemAt(_:withItemAt:) fails sporadically on ubiquitous items
I’m encountering a strange, sporadic error in FileManager.replaceItemAt(_:withItemAt:) when trying to update files that happen to be stored in cloud containers such as iCloud Drive or Dropbox. Here’s my setup: I have an NSDocument-based app which uses a zip file format (although the error can be reproduced using any kind of file). In my NSDocument.writeToURL: implementation, I do the following: Create a temp folder using FileManager.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: fileURL, create: true). Copy the original zip file into the temp directory. Update the zip file in the temp directory. Move the updated zip file into place by moving it from the temp directory to the original location using FileManager.replaceItemAt(_:withItemAt:). This all works perfectly - most of the time. However, very occasionally I receive a save error caused by replaceItemAt(_withItemAt:) failing. Saving can work fine for hundreds of times, but then, once in a while, I’ll receive an “operation not permitted” error in replaceItemAt. I have narrowed the issue down and found that it only occurs when the original file is in a cloud container - when FileManager.isUbiquitousItem(at:) returns true for the original fileURL I am trying to replace. (e.g. Because the user has placed the file in iCloud Drive.) Although strangely, the permissions issue seems to be with the temp file rather than with the original (if I try copying or deleting the temp file after this error occurs, I’m not allowed; I am allowed to delete the original though - not that I’d want to of course). Here’s an example of the error thrown by replaceItemAt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “test-file.txt” in the folder “Dropbox”." UserInfo={NSFileBackupItemLeftBehindLocationKey=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSFileOriginalItemLocationKey=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSURL=file:///Users/username/Library/CloudStorage/Dropbox/test-file.txt, NSFileNewItemLocationKey=file:///Users/username/Library/CloudStorage/Dropbox/test-file.txt, NSUnderlyingError=0xb1e22ff90 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “test-file.txt” in the folder “NSIRD_TempFolderBug_y3UvzP”." UserInfo={NSURL=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSFilePath=/var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSUnderlyingError=0xb1e22ffc0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}} And here’s some very simple sample code that reproduces the issue in a test app: // Ask user to choose this via a save panel. var savingURL: URL? { didSet { setUpSpamSave() } } var spamSaveTimer: Timer? // Set up a timer to save the file every 0.2 seconds so that we can see the sporadic save problem quickly. func setUpSpamSave() { spamSaveTimer?.invalidate() let timer = Timer(fire: Date(), interval: 0.2, repeats: true) { [weak self] _ in self?.spamSave() } spamSaveTimer = timer RunLoop.main.add(timer, forMode: .default) } func spamSave() { guard let savingURL else { return } let fileManager = FileManager.default // Create a new file in a temp folder. guard let replacementDirURL = try? fileManager.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: savingURL, create: true) else { return } let tempURL = replacementDirURL.appendingPathComponent(savingURL.lastPathComponent) guard (try? "Dummy text".write(to: tempURL, atomically: false, encoding: .utf8)) != nil else { return } do { // Use replaceItemAt to safely move the new file into place. _ = try fileManager.replaceItemAt(savingURL, withItemAt: tempURL) print("save succeeded!") try? fileManager.removeItem(at: replacementDirURL) // Clean up. } catch { print("save failed with error: \(error)") // Note: if we try to remove replaceDirURL here or do anything with tempURL we will be refused permission. NSAlert(error: error).runModal() } } If you run this code and set savingURL to a location in a non-cloud container such as your ~/Documents directory, it will run forever, resaving the file over and over again without any problems. But if you run the code and set savingURL to a location in a cloud container, such as in an iCloud Drive folder, it will work fine for a while, but after a few minutes - after maybe 100 saves, maybe 500 - it will throw a permissions error in replaceItemAt. (Note that my real app has all the save code wrapped in file coordination via NSDocument methods, so I don’t believe file coordination to be the problem.) What am I doing wrong here? How do I avoid this error? Thanks in advance for any suggestions.
15
0
320
2d
Are read-only filesystems currently supported by FSKit?
I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)
14
0
572
3d
macOS Tahoe 26.4 Beta 4: Rosetta deprecation warning not shown — bug or intended behavior?
According to the release notes for macOS Tahoe 26.4 beta, a warning dialog should appear when launching apps that require Rosetta 2, informing users that these apps will stop working in a future macOS release. However, on my MacBook Air M1 running Tahoe 26.4 Beta 4 (25E5233c), no such warning appears when launching Intel (x86_64) apps. Test case: VLC media player Downloaded from the official VLC website: https://www.videolan.org/vlc/ Selected the Intel 64-bit version (vlc-3.0.21-intel64.dmg) Copied VLC.app to /Applications Code signature verified: Identifier: org.videolan.vlc Format: Mach-O thin (x86_64) Team ID: 75GAHG3SZQ Timestamp: June 2024 Flags: hardened runtime Notarization: accepted (Notarized Developer ID) spctl --assess --verbose /Applications/VLC.app → accepted, source=Notarized Developer ID Launched VLC.app — no Rosetta deprecation warning appeared System log findings: The following entry was repeated many times in the system log: Sandbox: oahd-helper deny(1) file-read-data /usr/libexec/rosetta/oahd-helper This suggests that oahd-helper is being blocked by the Sandbox from reading its own binary, which may be preventing the warning dialog from appearing. My questions: Is this a known bug in Beta 4? Does the absence of a warning mean the app will continue to work in macOS 28 and beyond? Should I file a Feedback report for this? Any insights would be appreciated. Thank you. Environment: Device: MacBook Air 2020 M1 OS: macOS Tahoe 26.4 Beta 4 (25E5233c) Test app: VLC 3.0.21 Intel 64-bit (org.videolan.vlc, Team ID: 75GAHG3SZQ) Source: https://www.videolan.org/vlc/
5
0
166
3d
Sandboxed applications fail to mount NFS using NetFSMountURLSync
Mounting NFS to the application's own container directory using NetFSMountURLSync failed. Mounted to /Users/li/Library/Containers/com.xxxxx.navm.MyNavm/Data/Documents/NFSMount Do sandbox applications not allow mounting NFS cloud storage? code: // 1. NFS 服务器 URL(指定 NFSv3) let urlString = "nfs://192.168.64.4/seaweed?vers=3&resvport&nolocks&locallocks&soft&intr&timeo=600" guard let nfsURL = URL(string: urlString) else { os_log("❌ 无效的 URL: %@", log: netfsLog, type: .error, urlString) return } // 2. 挂载点(必须在沙盒容器内) let fileManager = FileManager.default guard let documentsURL = fileManager.urls(for: .documentDirectory, in: .userDomainMask).first else { os_log("❌ 无法获取 Documents 目录", log: netfsLog, type: .error) return } let mountPointURL = documentsURL.appendingPathComponent("NFSMount", isDirectory: true) // 创建挂载点目录 do { try fileManager.createDirectory(at: mountPointURL, withIntermediateDirectories: true, attributes: nil) os_log("✅ 挂载点目录已准备: %@", log: netfsLog, type: .info, mountPointURL.path) } catch { os_log("❌ 创建挂载点目录失败: %@", log: netfsLog, type: .error, error.localizedDescription) return } // 3. 挂载选项(使用 NSMutableDictionary 以匹配 CFMutableDictionary) let mountOptions = NSMutableDictionary() // 如果需要,可以添加选项,例如: // mountOptions[kNetFSNoUserAuthenticationKey as String] = true // 4. 调用 NetFSMountURLSync var mountPoints: Unmanaged<CFArray>? = nil let status = NetFSMountURLSync( nfsURL as CFURL, mountPointURL as CFURL, nil, // user nil, // password nil, // open_options mountOptions, // 直接传递 NSMutableDictionary,自动桥接为 CFMutableDictionary &mountPoints ) log: 0 sandboxd: (TCC) [com.apple.TCC:cache] REMOVE: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) 2026-03-03 21:38:27.656702+0800 0x2de8d8 Info 0x867e9d 408 0 sandboxd: (TCC) [com.apple.TCC:cache] SET: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) -> <Authorization Record (0x7ecca8180) | Service: kTCCServiceSystemPolicyAppData, AuthRight: Unknown, Reason: None, Version: 1, Session pid: 42832, Session pid version: 109769, Boot UUID: 7DDB03FC-132C-4E56-BA65-5C858D2CC8DD, > 2026-03-03 21:38:27.656753+0800 0x2de8d8 Default 0x867e9d 408 0 sandboxd: (libxpc.dylib) [com.apple.xpc:connection] [0x7ecc88640] invalidated after the last release of the connection object 2026-03-03 21:38:27.656772+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc3aa80(OS_tcc_message_options) 2026-03-03 21:38:27.656779+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc44820(OS_tcc_server) 2026-03-03 21:38:27.656788+0800 0x2de8d8 Info 0x867e9b 408 0 sandboxd: [com.apple.sandbox:sandcastle] kTCCServiceSystemPolicyAppData would require prompt by TCC for mount_nfs
4
0
299
4d
Initial stack construction
I'm having problems constructing the initial stack for the guest executable for Valgrind on macOS 12 Intel. This seemed to work OK for macOS 11 but I'm getting a bad 'apple' pointer on macOS 12. The stack (constructed by Valgrind) looks like this higher address +-----------------+ <- clstack_end | | : string table : | | +-----------------+ | NULL | +-----------------+ | executable_path | (first arg to execve()) +-----------------+ | NULL | - - | envp | +-----------------+ | NULL | - - | argv | +-----------------+ | argc | +-----------------+ | mach_header * | (dynamic only) lower address +-----------------+ <- sp | undefined | : : The problem that I'm having is with the executable path (or the apple pointer). This points to NULL. The actual pointer to the "executable=xxx" string is 16 bytes lower in memory. The code for main starts with Dump of assembler code for function main: 0x0000000100003a90 <+0>: push %rbp 0x0000000100003a91 <+1>: mov %rsp,%rbp 0x0000000100003a94 <+4>: sub $0x60,%rsp 0x0000000100003a98 <+8>: movl $0x0,-0x4(%rbp) 0x0000000100003a9f <+15>: mov %edi,-0x8(%rbp) 0x0000000100003aa2 <+18>: mov %rsi,-0x10(%rbp) 0x0000000100003aa6 <+22>: mov %rdx,-0x18(%rbp) 0x0000000100003aaa <+26>: mov %rcx,-0x20(%rbp) That's the prefix, making space for locals, setting a local variable to 0 then getting the 4 arguments from main in edi, rsi, rdx and rcx as per the SYSV amd64 ABI. I think that it is dyld that puts the apple pointer into rcx. Can anyone tall me how dyld works out the address of the apple pointer?
5
0
224
4d
Current wisdom on multiple XPC services in a System Extension?
I'm following up on a couple of forum threads from 2020 to get more clarity on the current guidance for supporting multiple XPC services in system extensions. For context, I'm trying to create a system extension that contains both an Endpoint Security client and a Network Extension filter, and I'm seeing indications that the system may not expect this and doesn't handle it smoothly. First: Previous guidance indicated that the system would automatically provide a Mach service named <TeamID>.<BundleID>.xpc to use for communicating with the system extension. However, the SystemExtension man page currently documents an Info.plist key called NSEndpointSecurityMachServiceName and suggests that the default service name is deprecated; and in fact if this key is not set, I find a message in the Console: The extension from () is using the deprecated default mach service name. Please update the extension to set the NSEndpointSecurityMachServiceName key in the Info.plist file. I have accordingly set this key, but I wanted to confirm that this is the current best practice. Second, and more interesting: Another user was trying to do something similar and observed that the Mach service for the endpoint security client wasn't available but the NE filter was. Quinn did some research and replied that this was intended behavior, quoting the EndpointSecurity man page: "If ES extension is combined with a Network Extension, set the NEMachServiceName key in the Info.plist" (which I have also done), and concluding from this: ... if you have a combined ES and NE system extension then the Mach service provided by the NE side takes precedence. However, the current man page does not include this quoted text and says nothing about a combined ES and NE system extension. So I'm wondering about current best practice. If I do combine the ES and NE clients in a single system extension, should they each declare the Mach service name under their respective Info.plist keys? And could there be a single XPC listener for both, using the same service name under each key, or would it be better to have separate XPC listeners? Alternatively, would it be preferable to have each component in a separate system extension? (This would entail some rearchitecting of the current design.)
4
0
200
5d
URL Filter Behaviour
Hello I have implemented URL Filter using below sample link https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url But currently I am facing weird issue when I try to add new urls in the input_urls.txt file. When I add url in the file and execute BloomFilterTool again, it creates new bloom plist as well as server url file so I replaces those manually restart the server as well as reinstall the app, but when I do so I am not able to get new urls blocked by browser until and unless I am not killing browser and relaunching it again. Does anybody facing same kind of issue ?
1
0
83
5d
PCI Transport Entitlements
Hello, I'm trying to develop a driver that uses PCIe through the mac's thunderbold ports. I requested a PCI entitlement, and it's just an empty array in the entitlements file by default. I was wondering if the vendor ID submitted with my entitlement request is supposed to populate this dictionary? I'm currently getting an entitlement check failed from kernel: DK: IOUserServer and was unsure if the PCI entitlement configuration was incorrect. Default entitlement: <key>com.apple.developer.driverkit.transport.pci</key> <array> </array> I'd be happy to provide more information as needed, but any guidance would be much appreciated. Thanks in advance.
1
0
70
5d
BGContinuedProcessingTask expirationHandler — Is there a way to distinguish the stop reason?
We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: the user taps Stop in the Live Activity the system expires the task due to time expiration the task is terminated due to system resource pressure (CPU, memory, battery, etc.) other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? If so, is there any official or supported way for the app to distinguish between these reasons? For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device
1
0
81
5d
BGContinuedProcessingTask expirationHandler — Is there a way to distinguish the stop reason?
We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: • the user taps Stop in the Live Activity • the system expires the task due to time expiration • the task is terminated due to system resource pressure (CPU, memory, battery, etc.) • other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: 1. In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? 2. If so, is there any official or supported way for the app to distinguish between these reasons? 3. For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? 4. If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device
1
0
65
5d
Monitor mode capture broken with Wi-Fi 7 (M5 Pro MacBook Pro) on macOS 26 - worked previously on same OS with older hardware
Platform: macOS 26.3.1, M5 Pro MacBook Pro Framework: CoreWLAN Affected applications: NetViews, Air Tool 2, and our own tooling — appears to be specific to the new Wi-Fi 7 hardware Hardware Card Type: chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Firmware: Jan 27 2026 21:18:32 version XBS_BUILD_TAG GIT_DESCRIBE FWID chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Driver: IO80211_driverkit-1540.16 "IO80211_driverkit-1540.16" Jan 27 2026 Background Both issues described below were working correctly on macOS 26 with previous-generation hardware. The regression is specific to the Wi-Fi 7 card shipping in the M5 Pro MacBook Pro. This is not an OS regression — it is a hardware/driver/firmware compatibility issue with the new card under macOS 26. Issue 1: disassociate() + tcpdump/Wireshark -I no longer enters monitor mode Previously, the standard approach of calling disassociate() and then launching tcpdump -i en0 -I or Wireshark -i en0 -I -k would successfully put the interface into monitor mode. On the M5 Pro Wi-Fi 7 card, this no longer works. The capture tool launches but the interface either stays in station mode or enters mode 0 - where there is no connection, but still not able to be a monitor radio. This is the primary regression affecting third-party wireless tools. Issue 2: setWLANChannel reports success but the radio only retunes once As a workaround for Issue 1, we use the built-in Wireless Diagnostics → Sniffer tool to establish monitor mode (which works fairly reliably on this hardware). Once the interface is in monitor mode via that path, we attempt to change the channel using setWLANChannel: let iface = CWWiFiClient.shared().interface(withName: "en0")! let target = iface.supportedWLANChannels()! .first { $0.channelNumber == 6 && $0.channelWidth == .width20MHz }! try iface.setWLANChannel(target) The first call succeeds (eg: channel 48 -> 6) the radio actually tunes to the requested channel and Wireshark captures frames there. Any subsequent call (eg: channel 48 -> 6 -> 1) shows the same apparent success - no error thrown, wlanChannel() updates to reflect the new channel - but the radio does not retune. Wireshark continues capturing on the first changed channel. We have tested with disassociate() and interface power cycling between attempts — neither resets the ability to retune the radio. What we have ruled out Timing: delays between calls make no difference Competing processes holding the interface wlanChannel() returning a stale cache value — it updates correctly, but diverges from actual hardware state after the first channel change Key data point: Wireless Diagnostics Sniffer works The built-in Wireless Diagnostics → Sniffer tool successfully puts the interface into monitor mode on this hardware. This confirms the card and driver are capable - the issue is that the capability is no longer reachable via CoreWLAN or via tcpdump/Wireshark's -I flag. Wireless Diagnostics Sniffer does not support live channel changes, so it cannot serve as a full workaround. The questions Is there a supported path for third-party apps to enter monitor mode on the new Wi-Fi 7 hardware on macOS 26? What is the correct mechanism for changing channels while in monitor mode - is setWLANChannel expected to retune the radio on subsequent calls, or is there a different API intended for this? The fact that Wireless Diagnostics accomplishes both (albeit, not live) confirms the hardware and driver are fully capable - we are looking for the sanctioned equivalent for third-party tools.
2
1
133
1w
Clarification on clonefile / copyfile support of clone directories?
The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.
5
0
238
1w
CFRelease crash
Crash on CFRelease(res) com.zscaler.zscaler.TRPTunnel-2026-03-02-195306.ips.txt , com.zscaler.zscaler.TRPTunnel-2026-03-02-200554.ips.txt below is the codes, please help how to fix it. { dispatch_block_t block = ^{ //All this dancing is an attempt to work around some weird crash: //seems like ARC is trying to release NULL before assigning new value CFDictionaryRef res = SCDynamicStoreCopyMultiple(store, NULL, keyPatterns); if (res && store) { NSDictionary *nsRes = (__bridge_transfer NSDictionary *)CFPropertyListCreateDeepCopy(kCFAllocatorDefault, (CFPropertyListRef)res, kCFPropertyListImmutable); setDynamicStore(nsRes); } else { ZLogError("SCU:[%s]%s refreshDynamicStore failed", dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL), __FUNCTION__); setDynamicStore(NULL); } if(res) { CFRelease(res); } }; if (dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) == dispatch_queue_get_label(queue)) { block(); } else { dispatch_async(queue, block); } }
3
0
90
1w
Behavior of Bookmark URLs and Files App Recently Deleted – Clarification and Potential Bug
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?
6
0
335
1w
Bluetooth audio packet alignment
We’re evaluating a Bluetooth device that supports Hands Free Profile (HFP) as the “Hands-Free Unit”. You can think of this as a Bluetooth telephone headset. This device interacts with our iOS application. We observed the following. The iPhone 17 HFP Wide-Band Speech (WBS) mSBC decoder requires the WBS packet (H2 header + mSBC frame) to be sent aligned. Aligned meaning, the H2 header must be first in every packet. The WBS packet cannot span multiple eSCO packets or else the iPhone will discard the audio. This is a different implementation than the iPad (iPad Pro 11-inch M4) , presumably due to Apple’s new N1 chip. In other words, we’ve identified that older iPhones and iPads do not require this alignment. They have implemented a stateful parser/decoder of the HFP WBS audio. A quick picture to help illustrate. The iPhone 17 requires: | Frame | Frame | Frame | Frame | However, a Bluetooth implementation we are evaluating does: | me Fra | me Fra | me Fra | me Fra | Does Apple intend to keep this implementation and continue discarding audio frames that are not aligned? Page 115 of the Bluetooth HFP 1.8 specification mentions at the bottom that this behavior is “left up to the implementation” but that the “synchronization header enables unaligned codec audio frames to be recovered by the receiving side.” We understand and acknowledge that one whole frame per eSCO packet is the intended, optimal method for delivering WBS mSBC audio for reduced jitter, latency, and memory usage. However, the more robust solution would be to maintain a stateful receiver as previously implemented. Any input would be appreciated.
3
0
135
1w
Core OS Resources
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"
Replies
0
Boosts
0
Views
610
Activity
Aug ’25
26.4 beta and RC versions are unable to be created on anything but 26.4 beta host OS
We're trying to create 26.4 beta and RC VMs on 15.x and 26.3 host OS' without success. We see Tue Mar 17 17:27:36 40 anka.log (install) 45803: failed to install macOS: Error Domain=VZErrorDomain Code=10006 "Installation requires a software update." UserInfo={NSLocalizedFailure=A software update is required to complete the installation., NSLocalizedFailureReason=Installation requires a software update.} Yet, if we create it the same way on 26.4 beta host OS, it works. We've tried the usual tricks of installing latest Xcode and preparing it (accepting license, etc). But, they don't work on 26.3 and 15.x. What's the trick to get the creation of 26.4 to work on <= 26.3 host OS?
Replies
4
Boosts
2
Views
197
Activity
13h
System-wide deadlock in removexattr from revisiond / APFS
System-wide deadlock in removexattr from revisiond / APFS We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Process: revisiond [426] UUID: 5E9B9E04-984B-31AD-A4FF-A1A90B7D53A1 Path: /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond Codesigning ID: com.apple.revisiond Shared Cache: 25AE5A2A-FE2A-3998-8D4E-F3C5C6E6CEB6 slid base address 0x189834000, slide 0x9834000 (System Primary) Architecture: arm64e Parent: launchd [1] UID: 0 Sudden Term: Tracked Memory Limit: 50MB Jetsam Priority: 40 Footprint: 6225 KB Time Since Fork: 1740319s Num samples: 940 (1-940) Num threads: 5 Note: 1 idle work queue thread omitted [...] Thread 0xc0616d 940 samples (1-940) priority 46 (base 4) last ran 241692.754s ago 940 start_wqthread + 8 (libsystem_pthread.dylib + 7068) [0x189d0ab9c] 940 _pthread_wqthread + 292 (libsystem_pthread.dylib + 11852) [0x189d0be4c] 940 _dispatch_workloop_worker_thread + 692 (libdispatch.dylib + 85356) [0x189b65d6c] 940 _dispatch_root_queue_drain_deferred_wlh + 292 (libdispatch.dylib + 87156) [0x189b66474] 940 _dispatch_lane_invoke + 440 (libdispatch.dylib + 45048) [0x189b5bff8] 940 _dispatch_lane_serial_drain + 944 (libdispatch.dylib + 42420) [0x189b5b5b4] 940 _dispatch_client_callout + 16 (libdispatch.dylib + 113364) [0x189b6cad4] 940 _dispatch_call_block_and_release + 32 (libdispatch.dylib + 7004) [0x189b52b5c] 940 ??? (revisiond + 168768) [0x10494d340] 940 ??? (revisiond + 165940) [0x10494c834] 940 ??? (revisiond + 40264) [0x10492dd48] 940 ??? (revisiond + 56680) [0x104931d68] 940 <patched truncated backtrace> 940 removexattr + 8 (libsystem_kernel.dylib + 23768) [0x189cd1cd8] *940 ??? (kernel.release.t6000 + 15240) [0xfffffe000886fb88] *940 ??? (kernel.release.t6000 + 1886348) [0xfffffe0008a3888c] *940 ??? (kernel.release.t6000 + 7730436) [0xfffffe0008fcb504] *940 ??? (kernel.release.t6000 + 2759592) [0xfffffe0008b0dba8] *940 ??? (kernel.release.t6000 + 2808244) [0xfffffe0008b199b4] *940 apfs_vnop_removexattr + 1044 (apfs + 474512) [0xfffffe000be8d4d0] *940 decmpfs_cnode_set_vnode_state + 80 (kernel.release.t6000 + 2945816) [0xfffffe0008b3b318] *940 IORWLockWrite + 184 (kernel.release.t6000 + 496184) [0xfffffe00088e5238] *940 ??? (kernel.release.t6000 + 494624) [0xfffffe00088e4c20] *940 ??? (kernel.release.t6000 + 619452) [0xfffffe00089033bc] *940 ??? (kernel.release.t6000 + 624472) [0xfffffe0008904758] The bulk of the other processes are waiting for that lock. (suspended, blocked by krwlock for reading owned by revisiond [426] thread 0xc0616d) (blocked by krwlock for writing owned by revisiond [426] thread 0xc0616d) Around the time of the event, these messages were logged by revision: 2026-03-06 18:49:37.781673-0500 0x16b7 Error 0x7f92f364 426 14 revisiond: [com.apple.revisiond:default] [ERROR] CSCopyChunkIDsForToken failed for 41639 2026-03-06 18:49:37.781716-0500 0x16b7 Error 0x7f92f365 426 14 revisiond: [com.apple.revisiond:default] [ERROR] updateEntry for new entry <private> failed 2026-03-06 18:49:37.781738-0500 0x16b7 Error 0x7f92f366 426 14 revisiond: [com.apple.revisiond:default] [ERROR] no entry for '<private>' 2026-03-06 18:49:37.781754-0500 0x16b7 Error 0x7f92f367 426 14 revisiond: [com.apple.revisiond:default] [ERROR] failed assembleInfoForOffset for fsid 16777234 fileid 359684022 offset 0 size 14334 (path <private>) Our agent uses Endpoint Security Framework to monitor events, and provide anti-tamper functionality for installed components and processes. While several EndpointSecurity calls appear in the spindump stack traces, we don't have any evidence that any calls from revisiond were blocked. What we'd really like to to understand what that lock is (appears to be decompressing an object on an APFS volume), what revisiond and APFS are doing with it, and what might cause it to deadlock. Of note, one of our processes is also waiting on that lock, one thread for reading and the other for writing. This issue affects machines running several macOS versions (15.x, 26.x). The machine in the examples is running macOS 26.3 (25D125)
Replies
2
Boosts
0
Views
103
Activity
40m
copyfile Sometimes Fails to copy .DS_Store when Copying a Folder But Does Not Report Usable Error
Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.
Replies
5
Boosts
0
Views
170
Activity
1d
FSKit passthrough sample fails to mount
After building the sample and enabling the file system extension the mount command is freezing. Any tips how to diagnose that? The logs show the following: log stream --style compact --info --debug --predicate 'subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"' Filtering the log data using "subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"" Timestamp Ty Process[PID:TID] 2026-03-17 15:15:51.832 I mount[16111:d88caa] [com.apple.FSKit:default] FSClient setting up connection to fskitd 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Incomming connection, entitled 0 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Hello FSClient! entitlement no 2026-03-17 15:15:51.834 Df mount[16111:d88caa] [com.apple.FSKit:default] Setting remote protocol to all XPC 2026-03-17 15:15:51.834 Df fskitd[589:d88a5f] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.834 I fskitd[589:d88a5f] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.835 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.836 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName () 2026-03-17 15:15:51.837 I fskitd[589:d88a5f] [com.apple.FSKit:default] Probe starting on 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager getResourceState:]:found: 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager addTaskUUID:resource:]:: Adding task () 2026-03-17 15:15:51.837 Df fskitd[589:d87c31] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.837 I fskitd[589:d87c31] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.837 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension , attrs 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] applyResource starting with resource kind 4
Replies
7
Boosts
0
Views
103
Activity
1d
filecopy fails with errno 34 "Result too large" when copying from NAS
A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error "Result too large". When copying the same files from the Desktop, it works. I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help. Both the app user and QNAP are willing to help, but at this point I'm also unsure how to proceed. Can someone at Apple say anything about this? Is this something QNAP should solve, or is this a bug in macOS? P.S.: I've had users in the past who reported the same issue with other brands, mostly Synology. import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.runModal() let source = openPanel.urls[0] openPanel.canChooseFiles = false openPanel.runModal() let destination = openPanel.urls[0] do { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } catch { NSAlert(error: error).runModal() } NSApp.terminate(nil) } private func copyFile(from source: URL, to destination: URL) throws { if try source.resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true { try FileManager.default.createDirectory(at: destination, withIntermediateDirectories: false) for source in try FileManager.default.contentsOfDirectory(at: source, includingPropertiesForKeys: nil) { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } } else { try copyRegularFile(from: source, to: destination) } } private func copyRegularFile(from source: URL, to destination: URL) throws { let state = copyfile_state_alloc() defer { copyfile_state_free(state) } var bsize = UInt32(16_777_216) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_DATA | COPYFILE_SECURITY | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_XATTR)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in if what == COPYFILE_COPY_DATA { if stage == COPYFILE_ERR { return COPYFILE_QUIT } } return COPYFILE_CONTINUE } }
Replies
19
Boosts
0
Views
487
Activity
2d
FileManager.replaceItemAt(_:withItemAt:) fails sporadically on ubiquitous items
I’m encountering a strange, sporadic error in FileManager.replaceItemAt(_:withItemAt:) when trying to update files that happen to be stored in cloud containers such as iCloud Drive or Dropbox. Here’s my setup: I have an NSDocument-based app which uses a zip file format (although the error can be reproduced using any kind of file). In my NSDocument.writeToURL: implementation, I do the following: Create a temp folder using FileManager.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: fileURL, create: true). Copy the original zip file into the temp directory. Update the zip file in the temp directory. Move the updated zip file into place by moving it from the temp directory to the original location using FileManager.replaceItemAt(_:withItemAt:). This all works perfectly - most of the time. However, very occasionally I receive a save error caused by replaceItemAt(_withItemAt:) failing. Saving can work fine for hundreds of times, but then, once in a while, I’ll receive an “operation not permitted” error in replaceItemAt. I have narrowed the issue down and found that it only occurs when the original file is in a cloud container - when FileManager.isUbiquitousItem(at:) returns true for the original fileURL I am trying to replace. (e.g. Because the user has placed the file in iCloud Drive.) Although strangely, the permissions issue seems to be with the temp file rather than with the original (if I try copying or deleting the temp file after this error occurs, I’m not allowed; I am allowed to delete the original though - not that I’d want to of course). Here’s an example of the error thrown by replaceItemAt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “test-file.txt” in the folder “Dropbox”." UserInfo={NSFileBackupItemLeftBehindLocationKey=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSFileOriginalItemLocationKey=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSURL=file:///Users/username/Library/CloudStorage/Dropbox/test-file.txt, NSFileNewItemLocationKey=file:///Users/username/Library/CloudStorage/Dropbox/test-file.txt, NSUnderlyingError=0xb1e22ff90 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “test-file.txt” in the folder “NSIRD_TempFolderBug_y3UvzP”." UserInfo={NSURL=file:///var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSFilePath=/var/folders/mt/0snrr8fx7270rm0b14ll5k500000gn/T/TemporaryItems/NSIRD_TempFolderBug_y3UvzP/test-file.txt, NSUnderlyingError=0xb1e22ffc0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}} And here’s some very simple sample code that reproduces the issue in a test app: // Ask user to choose this via a save panel. var savingURL: URL? { didSet { setUpSpamSave() } } var spamSaveTimer: Timer? // Set up a timer to save the file every 0.2 seconds so that we can see the sporadic save problem quickly. func setUpSpamSave() { spamSaveTimer?.invalidate() let timer = Timer(fire: Date(), interval: 0.2, repeats: true) { [weak self] _ in self?.spamSave() } spamSaveTimer = timer RunLoop.main.add(timer, forMode: .default) } func spamSave() { guard let savingURL else { return } let fileManager = FileManager.default // Create a new file in a temp folder. guard let replacementDirURL = try? fileManager.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: savingURL, create: true) else { return } let tempURL = replacementDirURL.appendingPathComponent(savingURL.lastPathComponent) guard (try? "Dummy text".write(to: tempURL, atomically: false, encoding: .utf8)) != nil else { return } do { // Use replaceItemAt to safely move the new file into place. _ = try fileManager.replaceItemAt(savingURL, withItemAt: tempURL) print("save succeeded!") try? fileManager.removeItem(at: replacementDirURL) // Clean up. } catch { print("save failed with error: \(error)") // Note: if we try to remove replaceDirURL here or do anything with tempURL we will be refused permission. NSAlert(error: error).runModal() } } If you run this code and set savingURL to a location in a non-cloud container such as your ~/Documents directory, it will run forever, resaving the file over and over again without any problems. But if you run the code and set savingURL to a location in a cloud container, such as in an iCloud Drive folder, it will work fine for a while, but after a few minutes - after maybe 100 saves, maybe 500 - it will throw a permissions error in replaceItemAt. (Note that my real app has all the save code wrapped in file coordination via NSDocument methods, so I don’t believe file coordination to be the problem.) What am I doing wrong here? How do I avoid this error? Thanks in advance for any suggestions.
Replies
15
Boosts
0
Views
320
Activity
2d
Are read-only filesystems currently supported by FSKit?
I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)
Replies
14
Boosts
0
Views
572
Activity
3d
macOS Tahoe 26.4 Beta 4: Rosetta deprecation warning not shown — bug or intended behavior?
According to the release notes for macOS Tahoe 26.4 beta, a warning dialog should appear when launching apps that require Rosetta 2, informing users that these apps will stop working in a future macOS release. However, on my MacBook Air M1 running Tahoe 26.4 Beta 4 (25E5233c), no such warning appears when launching Intel (x86_64) apps. Test case: VLC media player Downloaded from the official VLC website: https://www.videolan.org/vlc/ Selected the Intel 64-bit version (vlc-3.0.21-intel64.dmg) Copied VLC.app to /Applications Code signature verified: Identifier: org.videolan.vlc Format: Mach-O thin (x86_64) Team ID: 75GAHG3SZQ Timestamp: June 2024 Flags: hardened runtime Notarization: accepted (Notarized Developer ID) spctl --assess --verbose /Applications/VLC.app → accepted, source=Notarized Developer ID Launched VLC.app — no Rosetta deprecation warning appeared System log findings: The following entry was repeated many times in the system log: Sandbox: oahd-helper deny(1) file-read-data /usr/libexec/rosetta/oahd-helper This suggests that oahd-helper is being blocked by the Sandbox from reading its own binary, which may be preventing the warning dialog from appearing. My questions: Is this a known bug in Beta 4? Does the absence of a warning mean the app will continue to work in macOS 28 and beyond? Should I file a Feedback report for this? Any insights would be appreciated. Thank you. Environment: Device: MacBook Air 2020 M1 OS: macOS Tahoe 26.4 Beta 4 (25E5233c) Test app: VLC 3.0.21 Intel 64-bit (org.videolan.vlc, Team ID: 75GAHG3SZQ) Source: https://www.videolan.org/vlc/
Replies
5
Boosts
0
Views
166
Activity
3d
Sandboxed applications fail to mount NFS using NetFSMountURLSync
Mounting NFS to the application's own container directory using NetFSMountURLSync failed. Mounted to /Users/li/Library/Containers/com.xxxxx.navm.MyNavm/Data/Documents/NFSMount Do sandbox applications not allow mounting NFS cloud storage? code: // 1. NFS 服务器 URL(指定 NFSv3) let urlString = "nfs://192.168.64.4/seaweed?vers=3&resvport&nolocks&locallocks&soft&intr&timeo=600" guard let nfsURL = URL(string: urlString) else { os_log("❌ 无效的 URL: %@", log: netfsLog, type: .error, urlString) return } // 2. 挂载点(必须在沙盒容器内) let fileManager = FileManager.default guard let documentsURL = fileManager.urls(for: .documentDirectory, in: .userDomainMask).first else { os_log("❌ 无法获取 Documents 目录", log: netfsLog, type: .error) return } let mountPointURL = documentsURL.appendingPathComponent("NFSMount", isDirectory: true) // 创建挂载点目录 do { try fileManager.createDirectory(at: mountPointURL, withIntermediateDirectories: true, attributes: nil) os_log("✅ 挂载点目录已准备: %@", log: netfsLog, type: .info, mountPointURL.path) } catch { os_log("❌ 创建挂载点目录失败: %@", log: netfsLog, type: .error, error.localizedDescription) return } // 3. 挂载选项(使用 NSMutableDictionary 以匹配 CFMutableDictionary) let mountOptions = NSMutableDictionary() // 如果需要,可以添加选项,例如: // mountOptions[kNetFSNoUserAuthenticationKey as String] = true // 4. 调用 NetFSMountURLSync var mountPoints: Unmanaged<CFArray>? = nil let status = NetFSMountURLSync( nfsURL as CFURL, mountPointURL as CFURL, nil, // user nil, // password nil, // open_options mountOptions, // 直接传递 NSMutableDictionary,自动桥接为 CFMutableDictionary &mountPoints ) log: 0 sandboxd: (TCC) [com.apple.TCC:cache] REMOVE: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) 2026-03-03 21:38:27.656702+0800 0x2de8d8 Info 0x867e9d 408 0 sandboxd: (TCC) [com.apple.TCC:cache] SET: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) -> <Authorization Record (0x7ecca8180) | Service: kTCCServiceSystemPolicyAppData, AuthRight: Unknown, Reason: None, Version: 1, Session pid: 42832, Session pid version: 109769, Boot UUID: 7DDB03FC-132C-4E56-BA65-5C858D2CC8DD, > 2026-03-03 21:38:27.656753+0800 0x2de8d8 Default 0x867e9d 408 0 sandboxd: (libxpc.dylib) [com.apple.xpc:connection] [0x7ecc88640] invalidated after the last release of the connection object 2026-03-03 21:38:27.656772+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc3aa80(OS_tcc_message_options) 2026-03-03 21:38:27.656779+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc44820(OS_tcc_server) 2026-03-03 21:38:27.656788+0800 0x2de8d8 Info 0x867e9b 408 0 sandboxd: [com.apple.sandbox:sandcastle] kTCCServiceSystemPolicyAppData would require prompt by TCC for mount_nfs
Replies
4
Boosts
0
Views
299
Activity
4d
Initial stack construction
I'm having problems constructing the initial stack for the guest executable for Valgrind on macOS 12 Intel. This seemed to work OK for macOS 11 but I'm getting a bad 'apple' pointer on macOS 12. The stack (constructed by Valgrind) looks like this higher address +-----------------+ <- clstack_end | | : string table : | | +-----------------+ | NULL | +-----------------+ | executable_path | (first arg to execve()) +-----------------+ | NULL | - - | envp | +-----------------+ | NULL | - - | argv | +-----------------+ | argc | +-----------------+ | mach_header * | (dynamic only) lower address +-----------------+ <- sp | undefined | : : The problem that I'm having is with the executable path (or the apple pointer). This points to NULL. The actual pointer to the "executable=xxx" string is 16 bytes lower in memory. The code for main starts with Dump of assembler code for function main: 0x0000000100003a90 <+0>: push %rbp 0x0000000100003a91 <+1>: mov %rsp,%rbp 0x0000000100003a94 <+4>: sub $0x60,%rsp 0x0000000100003a98 <+8>: movl $0x0,-0x4(%rbp) 0x0000000100003a9f <+15>: mov %edi,-0x8(%rbp) 0x0000000100003aa2 <+18>: mov %rsi,-0x10(%rbp) 0x0000000100003aa6 <+22>: mov %rdx,-0x18(%rbp) 0x0000000100003aaa <+26>: mov %rcx,-0x20(%rbp) That's the prefix, making space for locals, setting a local variable to 0 then getting the 4 arguments from main in edi, rsi, rdx and rcx as per the SYSV amd64 ABI. I think that it is dyld that puts the apple pointer into rcx. Can anyone tall me how dyld works out the address of the apple pointer?
Replies
5
Boosts
0
Views
224
Activity
4d
Current wisdom on multiple XPC services in a System Extension?
I'm following up on a couple of forum threads from 2020 to get more clarity on the current guidance for supporting multiple XPC services in system extensions. For context, I'm trying to create a system extension that contains both an Endpoint Security client and a Network Extension filter, and I'm seeing indications that the system may not expect this and doesn't handle it smoothly. First: Previous guidance indicated that the system would automatically provide a Mach service named <TeamID>.<BundleID>.xpc to use for communicating with the system extension. However, the SystemExtension man page currently documents an Info.plist key called NSEndpointSecurityMachServiceName and suggests that the default service name is deprecated; and in fact if this key is not set, I find a message in the Console: The extension from () is using the deprecated default mach service name. Please update the extension to set the NSEndpointSecurityMachServiceName key in the Info.plist file. I have accordingly set this key, but I wanted to confirm that this is the current best practice. Second, and more interesting: Another user was trying to do something similar and observed that the Mach service for the endpoint security client wasn't available but the NE filter was. Quinn did some research and replied that this was intended behavior, quoting the EndpointSecurity man page: "If ES extension is combined with a Network Extension, set the NEMachServiceName key in the Info.plist" (which I have also done), and concluding from this: ... if you have a combined ES and NE system extension then the Mach service provided by the NE side takes precedence. However, the current man page does not include this quoted text and says nothing about a combined ES and NE system extension. So I'm wondering about current best practice. If I do combine the ES and NE clients in a single system extension, should they each declare the Mach service name under their respective Info.plist keys? And could there be a single XPC listener for both, using the same service name under each key, or would it be better to have separate XPC listeners? Alternatively, would it be preferable to have each component in a separate system extension? (This would entail some rearchitecting of the current design.)
Replies
4
Boosts
0
Views
200
Activity
5d
URL Filter Behaviour
Hello I have implemented URL Filter using below sample link https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url But currently I am facing weird issue when I try to add new urls in the input_urls.txt file. When I add url in the file and execute BloomFilterTool again, it creates new bloom plist as well as server url file so I replaces those manually restart the server as well as reinstall the app, but when I do so I am not able to get new urls blocked by browser until and unless I am not killing browser and relaunching it again. Does anybody facing same kind of issue ?
Replies
1
Boosts
0
Views
83
Activity
5d
PCI Transport Entitlements
Hello, I'm trying to develop a driver that uses PCIe through the mac's thunderbold ports. I requested a PCI entitlement, and it's just an empty array in the entitlements file by default. I was wondering if the vendor ID submitted with my entitlement request is supposed to populate this dictionary? I'm currently getting an entitlement check failed from kernel: DK: IOUserServer and was unsure if the PCI entitlement configuration was incorrect. Default entitlement: <key>com.apple.developer.driverkit.transport.pci</key> <array> </array> I'd be happy to provide more information as needed, but any guidance would be much appreciated. Thanks in advance.
Replies
1
Boosts
0
Views
70
Activity
5d
BGContinuedProcessingTask expirationHandler — Is there a way to distinguish the stop reason?
We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: the user taps Stop in the Live Activity the system expires the task due to time expiration the task is terminated due to system resource pressure (CPU, memory, battery, etc.) other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? If so, is there any official or supported way for the app to distinguish between these reasons? For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device
Replies
1
Boosts
0
Views
81
Activity
5d
BGContinuedProcessingTask expirationHandler — Is there a way to distinguish the stop reason?
We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: • the user taps Stop in the Live Activity • the system expires the task due to time expiration • the task is terminated due to system resource pressure (CPU, memory, battery, etc.) • other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: 1. In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? 2. If so, is there any official or supported way for the app to distinguish between these reasons? 3. For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? 4. If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device
Replies
1
Boosts
0
Views
65
Activity
5d
Monitor mode capture broken with Wi-Fi 7 (M5 Pro MacBook Pro) on macOS 26 - worked previously on same OS with older hardware
Platform: macOS 26.3.1, M5 Pro MacBook Pro Framework: CoreWLAN Affected applications: NetViews, Air Tool 2, and our own tooling — appears to be specific to the new Wi-Fi 7 hardware Hardware Card Type: chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Firmware: Jan 27 2026 21:18:32 version XBS_BUILD_TAG GIT_DESCRIBE FWID chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Driver: IO80211_driverkit-1540.16 "IO80211_driverkit-1540.16" Jan 27 2026 Background Both issues described below were working correctly on macOS 26 with previous-generation hardware. The regression is specific to the Wi-Fi 7 card shipping in the M5 Pro MacBook Pro. This is not an OS regression — it is a hardware/driver/firmware compatibility issue with the new card under macOS 26. Issue 1: disassociate() + tcpdump/Wireshark -I no longer enters monitor mode Previously, the standard approach of calling disassociate() and then launching tcpdump -i en0 -I or Wireshark -i en0 -I -k would successfully put the interface into monitor mode. On the M5 Pro Wi-Fi 7 card, this no longer works. The capture tool launches but the interface either stays in station mode or enters mode 0 - where there is no connection, but still not able to be a monitor radio. This is the primary regression affecting third-party wireless tools. Issue 2: setWLANChannel reports success but the radio only retunes once As a workaround for Issue 1, we use the built-in Wireless Diagnostics → Sniffer tool to establish monitor mode (which works fairly reliably on this hardware). Once the interface is in monitor mode via that path, we attempt to change the channel using setWLANChannel: let iface = CWWiFiClient.shared().interface(withName: "en0")! let target = iface.supportedWLANChannels()! .first { $0.channelNumber == 6 && $0.channelWidth == .width20MHz }! try iface.setWLANChannel(target) The first call succeeds (eg: channel 48 -> 6) the radio actually tunes to the requested channel and Wireshark captures frames there. Any subsequent call (eg: channel 48 -> 6 -> 1) shows the same apparent success - no error thrown, wlanChannel() updates to reflect the new channel - but the radio does not retune. Wireshark continues capturing on the first changed channel. We have tested with disassociate() and interface power cycling between attempts — neither resets the ability to retune the radio. What we have ruled out Timing: delays between calls make no difference Competing processes holding the interface wlanChannel() returning a stale cache value — it updates correctly, but diverges from actual hardware state after the first channel change Key data point: Wireless Diagnostics Sniffer works The built-in Wireless Diagnostics → Sniffer tool successfully puts the interface into monitor mode on this hardware. This confirms the card and driver are capable - the issue is that the capability is no longer reachable via CoreWLAN or via tcpdump/Wireshark's -I flag. Wireless Diagnostics Sniffer does not support live channel changes, so it cannot serve as a full workaround. The questions Is there a supported path for third-party apps to enter monitor mode on the new Wi-Fi 7 hardware on macOS 26? What is the correct mechanism for changing channels while in monitor mode - is setWLANChannel expected to retune the radio on subsequent calls, or is there a different API intended for this? The fact that Wireless Diagnostics accomplishes both (albeit, not live) confirms the hardware and driver are fully capable - we are looking for the sanctioned equivalent for third-party tools.
Replies
2
Boosts
1
Views
133
Activity
1w
Clarification on clonefile / copyfile support of clone directories?
The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.
Replies
5
Boosts
0
Views
238
Activity
1w
CFRelease crash
Crash on CFRelease(res) com.zscaler.zscaler.TRPTunnel-2026-03-02-195306.ips.txt , com.zscaler.zscaler.TRPTunnel-2026-03-02-200554.ips.txt below is the codes, please help how to fix it. { dispatch_block_t block = ^{ //All this dancing is an attempt to work around some weird crash: //seems like ARC is trying to release NULL before assigning new value CFDictionaryRef res = SCDynamicStoreCopyMultiple(store, NULL, keyPatterns); if (res && store) { NSDictionary *nsRes = (__bridge_transfer NSDictionary *)CFPropertyListCreateDeepCopy(kCFAllocatorDefault, (CFPropertyListRef)res, kCFPropertyListImmutable); setDynamicStore(nsRes); } else { ZLogError("SCU:[%s]%s refreshDynamicStore failed", dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL), __FUNCTION__); setDynamicStore(NULL); } if(res) { CFRelease(res); } }; if (dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) == dispatch_queue_get_label(queue)) { block(); } else { dispatch_async(queue, block); } }
Replies
3
Boosts
0
Views
90
Activity
1w
Behavior of Bookmark URLs and Files App Recently Deleted – Clarification and Potential Bug
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?
Replies
6
Boosts
0
Views
335
Activity
1w
Bluetooth audio packet alignment
We’re evaluating a Bluetooth device that supports Hands Free Profile (HFP) as the “Hands-Free Unit”. You can think of this as a Bluetooth telephone headset. This device interacts with our iOS application. We observed the following. The iPhone 17 HFP Wide-Band Speech (WBS) mSBC decoder requires the WBS packet (H2 header + mSBC frame) to be sent aligned. Aligned meaning, the H2 header must be first in every packet. The WBS packet cannot span multiple eSCO packets or else the iPhone will discard the audio. This is a different implementation than the iPad (iPad Pro 11-inch M4) , presumably due to Apple’s new N1 chip. In other words, we’ve identified that older iPhones and iPads do not require this alignment. They have implemented a stateful parser/decoder of the HFP WBS audio. A quick picture to help illustrate. The iPhone 17 requires: | Frame | Frame | Frame | Frame | However, a Bluetooth implementation we are evaluating does: | me Fra | me Fra | me Fra | me Fra | Does Apple intend to keep this implementation and continue discarding audio frames that are not aligned? Page 115 of the Bluetooth HFP 1.8 specification mentions at the bottom that this behavior is “left up to the implementation” but that the “synchronization header enables unaligned codec audio frames to be recovered by the receiving side.” We understand and acknowledge that one whole frame per eSCO packet is the intended, optimal method for delivering WBS mSBC audio for reduced jitter, latency, and memory usage. However, the more robust solution would be to maintain a stateful receiver as previously implemented. Any input would be appreciated.
Replies
3
Boosts
0
Views
135
Activity
1w