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
601
Aug ’25
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.
2
0
97
1h
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
544
2h
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 } }
17
0
424
3h
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
156
7h
Downtime feature makes phone freeze
My iphone freezes during the night, having the alarm not go off, me miss important things as I oversleep. And the phone needs to go thru hard reboot to get back to normal. It´s only been happening after I started using "Downtime". (An underdeveloped feature by Apple in the first place). I love locking my apps down nighttime for less screentime. Annoyingly it only happens once in a while, so I´m not able to link it directly to downtime consistently. I´m not developing an app right now so I´m steep ground with this post, but, with lack of sleep as this has messed up my sleep rythm several times, well I´m not able too anyway. I know ios well, and there isn´t much "to do" except having to always remember to turn off downtime (it doesn´t play well with shortcuts app either), but I hope someone from apple sees this and is able to push this bug into the right team as all reports I have seen goes on focus modes bugs, but not "downtime".
0
0
10
7h
Strange crash in iOS AudioToolboxCore when using AVSpeechSynthesizer in iOS 16
I'm getting Crashlytics crashes from some my users, deep in the Apple code: Crashed: AXSpeech EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000007ec54b360 0 libobjc.A.dylib 0x3c9c objc_retain_x8 + 16 1 AudioToolboxCore 0x99580 auoop::RenderPipeUser::~RenderPipeUser() + 112 2 AudioToolboxCore 0xe6090 -[AUAudioUnit_XPC internalDeallocateRenderResources] + 92 3 AVFAudio 0x90a0 AUInterfaceBaseV3::Uninitialize() + 60 4 AVFAudio 0x4cbe0 AVAudioEngineGraph::PerformCommand(AUGraphNodeBaseV3&, AVAudioEngineGraph::ENodeCommand, void*, unsigned int) const + 768 5 AVFAudio 0x56b0c AVAudioEngineGraph::_Uninitialize(NSError**) + 132 6 AVFAudio 0x7834 AVAudioEngineImpl::Stop(NSError**) + 388 7 AVFAudio 0x636c -[AVAudioEngine dealloc] + 52 8 TextToSpeech 0x30674 _TTSNameForVoiceInformation + 20864 9 libobjc.A.dylib 0x20a4 object_cxxDestructFromClass(objc_object*, objc_class*) + 116 10 libobjc.A.dylib 0x6e00 objc_destructInstance + 80 11 libobjc.A.dylib 0x104fc _objc_rootDealloc + 80 12 TextToSpeech 0x2d2f4 _TTSNameForVoiceInformation + 7680 13 TextToSpeech 0x496c TTSVocalizerCopyURLForFallbackResource + 8540 14 TextToSpeech 0x26094 TTSSpeechUnitTestingMode + 5548 15 libAXSpeechManager.dylib 0x108b0 -[AXSpeechManager .cxx_destruct] + 192 16 libobjc.A.dylib 0x20a4 object_cxxDestructFromClass(objc_object*, objc_class*) + 116 17 libobjc.A.dylib 0x6e00 objc_destructInstance + 80 18 libobjc.A.dylib 0x104fc _objc_rootDealloc + 80 19 libAXSpeechManager.dylib 0x5298 -[AXSpeechManager dealloc] + 268 20 Foundation 0x3b8a4 __NSThreadPerformPerform + 272 21 CoreFoundation 0xd3208 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 22 CoreFoundation 0xdf864 __CFRunLoopDoSource0 + 176 23 CoreFoundation 0x646c8 __CFRunLoopDoSources0 + 244 24 CoreFoundation 0x7a1c4 __CFRunLoopRun + 828 25 CoreFoundation 0x7f4dc CFRunLoopRunSpecific + 612 26 Foundation 0x420c4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 27 libAXSpeechManager.dylib 0x13390 -[AXSpeechThread main] + 552 28 Foundation 0x5b634 __NSThread__start__ + 716 29 libsystem_pthread.dylib 0x16b8 _pthread_start + 148 30 libsystem_pthread.dylib 0xb88 thread_start + 8 It's most likely related to my use of AVSpeechSynthesizer. I do change some of the utterance fields, including the voice that's being used (which is set to a value from speechVoices()). UtilAudioIos_tts = AVSpeechSynthesizer() let utterance = AVSpeechUtterance utterance.voice = AVSpeechSynthesisVoice(identifier: voice.voiceCode) utterance.volume = volume utterance.pitchMultiplier = pitch utterance.rate = rate UtilAudioIos_tts!.speak(utterance) By coincidence or not, the following sometimes appears in the device log: 2023-05-30 20:35:29.948078+0100 <appname>[466:12882] [catalog] Unable to list voice folder and also, sometimes: 2023-05-30 20:37:35.345933+0100 <appname>[466:13298] [catalog] Query for com.apple.MobileAsset.VoiceServices.VoiceResources failed: 2 2023-05-30 20:37:35.360854+0100 rehearserfree[466:13433] [AXTTSCommon] MauiVocalizer: 11006 (Can't compile rule): regularExpression=\Oviedo(?=, (\x1b\\pause=\d+\\)?Florida)\b, message=unrecognized character follows \, characterPosition=1 2023-05-30 20:37:35.363163+0100 <appname>[466:13433] [AXTTSCommon] MauiVocalizer: 16038 (Resource load failed): component=ttt/re, uri=, contentType=application/x-vocalizer-rettt+text, lhError=88602000 2023-05-30 20:37:35.363182+0100 <appname>[466:13433] [AXTTSCommon] Error loading rules: 2147483648 All of these crashes have been on the various versions of iOS 16. Edit: I can't reproduce the crash myself - it's just some (not all) app users. The log entries above appear locally on my device (with no crash) but I can't see the logs of the users who have the crashes. Any idea what this might be caused by, or how to go about tracking the problem down?
3
0
2.1k
7h
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
3
0
42
7h
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
279
1d
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
214
1d
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
186
1d
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.
14
0
299
2d
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
74
2d
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
64
2d
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
77
2d
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
60
2d
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
128
3d
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
221
5d
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
77
5d
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
329
5d
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
132
1w