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

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

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

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

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

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

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

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

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

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

Hello Apple Bluetooth team, We are developing a real-time call translation system that streams raw PCM audio over BLE between iPhone and custom earbuds. This works reliably on iPhone 14 / 15 / 16, but on iPhone 17 (Bluetooth 6, N1 chip) we see severe and repeatable BLE packet loss, affecting both microphone uplink and TTS downlink. Our audio stream 16 kHz, 16-bit mono PCM 20 ms frames (~640 bytes) continuous bidirectional BLE streaming What happens on iPhone 17 BLE packets are frequently dropped entire audio frames are missing results in ASR gaps and broken TTS playback occurs even with strong RSSI and no RF interference Same firmware, same BLE protocol, same MTU and connection interval work normally on older iPhones. Questions We would like to know: Did Bluetooth 6 / N1 change BLE throughput, buffering, or scheduling? Are there new limits on sustained notify / write-without-response traffic? Is BLE audio now arbitrated differently against Wi-Fi / A2DP on iPhone 17? Is BLE still expected to support low-latency continuous audio streaming on iPhone 17, or is this no longer a safe assumption? Any guidance or new best practices would be greatly appreciated. Best regards, Valenti Zhang

My app allows to save user-selected URLs in a list and browse them with a tap. A user reported that the app often shows that when browsing their saved entry for "On My iPad", it's apparently empty (it contains no files). I saved "On My iPad" in my own list some time ago and noticed that the same issue occurs. The URL seems to be correctly resolved from the saved bookmark data, but I noticed that url.startAccessingSecurityScopedResource() returns false. The other URL I saved some time ago is iCloud Drive, which I can access without issues. If I select "On My iPad" again in a file importer, create new bookmark data from it and resolve the URL from it, access works correctly. I create bookmark data like this: let data = try url.bookmarkData(includingResourceValuesForKeys: [.localizedNameKey, .pathKey, .volumeIsLocalKey]) and resolve URLs like this: let url = try URL(resolvingBookmarkData: data, bookmarkDataIsStale: &bookmarkDataIsStale) bookmarkDataIsStale is false for both the working and not working URLs for "On My iPad". The two bookmark data are different though, even if url.path is the same. What could be the issue?

Hello, Is there a 2-device limit for CoreBluetooth on visionOS 2.1? My app connects to 4 BLE peripherals on iOS but fails at the 3rd device on Vision Pro. The 3rd call to centralManager.connect() is successful and the peripheral enters .connecting state, but didConnect never fires and it stays in .connecting forever. No errors reported. First 2 devices work perfectly. Same code on iOS connects all 4. Has anyone else had this problem? Is there any documentation I can refer to that states something like this? Environment: visionOS 2.1, CoreBluetooth, Apple Vision Pro. My BLE Peripherals are running on nRF52840.

We have a Matter 1.2 certified device, with device type "On/Off Light Switch" (0x0103) that we are launching soon. The last tests include the updatability via DCL published updates: showing up immediately via Google Home, and Home Assistant not showing up at all in Apple Home, waited for >1 week We successfully tested with the TestNet DCL profile.

I am able to symbolicate kernel backtraces for addresses that belong to my kext. Is it possible to symbolicate kernel backtraces for addresses that lie beyond my kext and reference kernel code? Sample kernel panic log

We're updating a FileProvider-based app which was written for Big Sur to recent macOS. The system requires that the extension be manually enabled by the user in System Preferences -- either under Extensions > Added Extensions, Privacy & Security > Extensions > Added Extensions, or in newer versions General > Login Items & Extensions. Is there a programmatic (preferably Swift) or installer-based way to enable this checkbox-- or at least to detect if it has been enabled for a particular app, and if not bring up the appropriate pane of Preferences? (For which I'd need a complete OS-version-specific list of which pane to bring up.) (I can detect whether our particular NSFileProviderDomain has its userEnabled flag set after it's defined during the mounting process, but I'd rather be able to detect / set it during initial setup.)

I regularly see questions, both here on the Apple Developer Forums and in my Day Job™ at DTS, that are caused by a fundamental misunderstanding of how background execution works on iOS. These come in many different variants, for example: How do I keep my app running continuously in the background? If I schedule a timer, how do I get it to fire when the screen is locked? How do I run code in the background every 15 minutes? How do I set up a network server that runs in the background? How can my app provide an IPC service to another one of my apps while it’s in the background? How can I resume my app in the background if it’s been ‘force quit’ by the user? The short answer to all of these is You can’t. iOS puts strict limits on background execution. Its default behaviour is to suspend your app shortly after the user has moved it to the background; this suspension prevents the process from running any code. There’s no general-purpose mechanism for: Running code continuously in the background Running code at some specific time in the background Running code periodically at a guaranteed interval Resuming in the background in response to a network or IPC request [1] However, iOS does provide a wide range of special-purpose mechanisms for accomplishing specific user goals. For example: If you’re building a music player, use the audio background mode to continue playing after the user has moved your app to the background. If you’re building a timer app, check out the AlarmKit framework. On older systems, use a local notification to notify the user when your timer has expired. If you’re building a video player app, use AVFoundation’s download support. Keep in mind that the above is just a short list of examples. There are many other special-purpose background execution mechanisms, so you should search the documentation for something appropriate to your needs. IMPORTANT Each of these mechanisms fulfils a specific purpose. Do not attempt to use them for some other purpose. Before using a background API, read clause 2.5.4 of the App Review Guidelines. Additionally, iOS provides some general-purpose mechanisms for background execution: To resume your app in the background in response to an event on your server, use a background notification (aka a ‘silent’ push). For more information, see Pushing background updates to your App. To request a small amount of background execution time to refresh your UI, use the BGAppRefreshTaskRequest class. To request extended background execution time, typically delivered overnight when the user is asleep, use the BGProcessingTaskRequest class. To continue user-visible work after the user has left your app, use the BGContinuedProcessingTask class. To prevent your app from being suspended for a short period of time so that you can complete some user task, use a UIApplication background task. For more information on this, see UIApplication Background Task Notes. To download or upload a large HTTP resource, use an URLSession background session. All of these mechanisms prevent you from abusing them to run arbitrary code in the background. As an example, consider the URLSession resume rate limiter. For more information about these limitations, and background execution in general, I strongly recommend that you watch WWDC 2020 Session 10063 Background execution demystified [2]. It’s an excellent resource. Specifically, this talk addresses a common misconception about the app refresh mechanism (BGAppRefreshTaskRequest and the older background fetch API). Folks assume that app refresh will provide regular background execution time. That’s not the case. The system applies a range of heuristics to decide which apps get app refresh time and when. This is a complex issue, one that I’m not going to try to summarise here, but the take-home message is that, if you expect that the app refresh mechanism will grant you background execution time, say, every 15 minutes, you’ll be disappointed. In fact, there are common scenarios where it won’t grant you any background execution time at all! Watch the talk for the details. [1] iOS 26 introduced support for general-purpose IPC, in the form of enhanced security helper extensions. However, these can only be invoked by the container app, and that means there’s no background execution benefit. [2] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back. When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. So: If the app is running, iOS terminates it. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. This gesture is a clear statement of user intent; there’s no documented way for your app to override the user’s choice. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Finally, if you have questions about background execution that aren’t covered by the resources listed here, please open a new thread on the forums with the details. Put it in a reasonable subtopic and tag it appropriately for the technology you’re using; if nothing specific springs to mind, use Background Tasks. Also, make sure to include details about the specific problem you’re trying to solve because, when it comes to background execution, the devil really is in the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 2026-01-09 Added a reference to AlarmKit. Added a reference to BGContinuedProcessingTask. Add a footnote about IPC and another one about WWDC 2020 Session 10063. Made other minor editorial changes. 2024-03-21 Added a discussion of ‘force quit’. 2023-05-11 Added a paragraph that explains a common misconception about the app refresh mechanism. Made other minor editorial changes. 2021-08-12 Added more entries to the common questions list, this time related to networking and IPC. Made minor editorial changes. 2021-07-26 Extended the statement about what’s not possible to include “running code periodically at a guaranteed interval”. 2021-07-22 First posted.

File Provider Extension Testing Mode -2014 Error Issue I'm developing a macOS File Provider Extension and encountering a -2014 (Extension not registered) error when using Testing Mode only. Environment macOS: 13.0+ Xcode: Latest version Developer Account: Paid Developer Account Extension Type: NSFileProviderReplicatedExtension Current Status App ID Configuration App ID: kr.it.flux.FluxDrive2.FileProvider Capabilities: ✅ com.apple.developer.fileprovider.testing-mode (enabled) ❌ General com.apple.developer.fileprovider (not visible) Extension Configuration NSExtensionPointIdentifier: com.apple.fileprovider NSExtensionPrincipalClass: FluxDrive2FileProvider.FileProviderExtension Code Signing: Valid (Team Identifier verified) Info.plist: Valid Error Message Error Domain=NSFileProviderErrorDomain Code=-2014 The operation couldn't be completed. (NSFileProviderErrorDomain error -2014.) Underlying error: Error Domain=NSFileProviderErrorDomain Code=-2001 Extension cannot be used Attempted Solutions ✅ Verified and corrected Extension Info.plist ✅ Verified Extension code signing ✅ Added App Group (group.kr.it.flux.FluxDrive2) ✅ Clean Build and rebuild ✅ Verified installation in /Applications ❌ Attempted to enable Extension in System Settings (Testing Mode doesn't appear) Observations Extension is not actually loaded (FileProviderExtension.init() is never called) NSFileProviderManager.add(domain) immediately returns -2014 error Extension file is built correctly and included in the app bundle Questions Shouldn't Testing Mode allow testing of File Provider Extension? Why is the -2014 error occurring? The general com.apple.developer.fileprovider capability is not visible in Developer Portal. How can I enable it? Is it normal for Extension not to be registered in the system when using Testing Mode, or are additional settings required? Is the general File Provider capability mandatory for App Store submission? Additional Information Extension code correctly implements NSFileProviderReplicatedExtension protocol All required methods (item, enumerator, fetchContents, etc.) are implemented Network permission (com.apple.security.network.client) is configured Any help would be greatly appreciated!

File Provider Extension Testing Mode -2014 Error Issue I'm developing a macOS File Provider Extension and encountering a -2014 (Extension not registered) error when using Testing Mode only. Environment macOS: 13.0+ Xcode: Latest version Developer Account: Paid Developer Account Extension Type: NSFileProviderReplicatedExtension Current Status App ID Configuration App ID: kr.it.flux.FluxDrive2.FileProvider Capabilities: ✅ com.apple.developer.fileprovider.testing-mode (enabled) ❌ General com.apple.developer.fileprovider (not visible) Extension Configuration NSExtensionPointIdentifier: com.apple.fileprovider NSExtensionPrincipalClass: FluxDrive2FileProvider.FileProviderExtension Code Signing: Valid (Team Identifier verified) Info.plist: Valid Error Message Error Domain=NSFileProviderErrorDomain Code=-2014 The operation couldn't be completed. (NSFileProviderErrorDomain error -2014.) Underlying error: Error Domain=NSFileProviderErrorDomain Code=-2001 Extension cannot be used Attempted Solutions ✅ Verified and corrected Extension Info.plist ✅ Verified Extension code signing ✅ Added App Group (group.kr.it.flux.FluxDrive2) ✅ Clean Build and rebuild ✅ Verified installation in /Applications ❌ Attempted to enable Extension in System Settings (Testing Mode doesn't appear) Observations Extension is not actually loaded (FileProviderExtension.init() is never called) NSFileProviderManager.add(domain) immediately returns -2014 error Extension file is built correctly and included in the app bundle Questions Shouldn't Testing Mode allow testing of File Provider Extension? Why is the -2014 error occurring? The general com.apple.developer.fileprovider capability is not visible in Developer Portal. How can I enable it? Is it normal for Extension not to be registered in the system when using Testing Mode, or are additional settings required? Is the general File Provider capability mandatory for App Store submission? Additional Information Extension code correctly implements NSFileProviderReplicatedExtension protocol All required methods (item, enumerator, fetchContents, etc.) are implemented Network permission (com.apple.security.network.client) is configured Any help would be greatly appreciated!

If (in terminal) I type 'env', I'll see a line that looks like: LANG=en_GB.UTF-8 And I can parse that to get the 2-char 'en' locale-code, the sub-domain 'GB' and the character-set encoding of UTF-8. All well and good. However in a Cocoa app, I can't seem to find the equivalent for the "UTF-8" part. This is a cross-platform app, but at this point I'll go with any solution... I've tried: NSLocale *loc = NSLocale.currentLocale; NSString *lang = loc.localeIdentifier; setlocale(LC_ALL, NULL); char *text = nl_langinfo(CODESET); if (text) NSString *charset = [NSString stringWithUTF8String:text]; NSLog(@"lang:%@\nchar:%@\n",lang, charset); which displays: lang:en-GB char:US-ASCII Also tried: // Search for locale info by preferred environment variable NSProcessInfo *pi = NSProcessInfo.processInfo; NSDictionary<NSString *,NSString *> *env = pi.environment; NSString *spec = env[@"LC_ALL"]; if (spec == nil) spec = env[@"LC_CTYPE"]; if (spec == nil) spec = env[@"LANG"]; NSLog(@"spec:%@\n", spec); which displays: spec:(null) Also tried: CFStringEncoding sys = CFStringGetSystemEncoding(); CFStringRef enc = CFStringConvertEncodingToIANACharSetName(sys); NSString *nsEnc = (__bridge NSString *)enc; NSLog(@"iana:%@", nsEnc); enc = CFStringGetNameOfEncoding(sys); nsEnc = (__bridge NSString *)enc; NSLog(@"name:%@", nsEnc); CFStringEncoding compat = CFStringGetMostCompatibleMacStringEncoding(sys); enc = CFStringGetNameOfEncoding(compat); nsEnc = (__bridge NSString *)enc; NSLog(@"name:%@", nsEnc); which displays: iana:macintosh name:Western (Mac OS Roman) name:Western (Mac OS Roman) Any ideas ?