General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've noticed that NSLog() doesn't do anything on iOS 26 when an app is downloaded from TestFlight. I've got an app uploaded with a liberal sprinkling of NSLog lines in it for debugging purposes - if I download that onto an iOS 18 devices, and use Apple Configurator's console, the logging output is verbose and as expected. But if I download that same app onto an iOS 26 handset, there's nothing. What happened? Was this an intentional change? Why. This is a major hindrance in diagnosing issues / bugs etc.

We are implementing authentication login in our iOS mobile application, and during the sign-in/sign-out process, a native system popup appears with the following message: "This allows the app and website to share information about you." This popup interrupts the user experience, and we are concerned it may cause confusion for end users and negatively impact the adoption of our login flow. We would like clarification on the following points: What triggers this popup during the authentication process? Are there any recommended configurations or approaches to suppress or avoid this dialog? If the popup cannot be avoided, what best practices are suggested to ensure a clear and seamless user experience? Our objective is to provide a smooth, user-friendly authentication flow without unexpected system interruptions.

After perusing the sources of Apple's SMB and NFS clients' implementation of VNOP_MONITOR, my understanding of how VNOP_MONITOR+vnode_notify() operate is as follows: A user-space process advertises an interest in monitoring a file or directory via kqueue(2)/kevent(2). VFS calls the filesystem's implementation of VNOP_MONITOR. VNOP_MONITOR forwards the commencing or terminating of monitoring events request to the filesystem server. Network filesystem client nodes call vnode_notify() to notify the underlying VFS of a filesystem event, e.g. file/directory creation/removal, etc. What I'm still vague about is how does the server communicate back to client nodes that an event of interest has occurred? I'd appreciate being enlightened on the operation of `VNOP_MONITOR+vnode_notify()' in a network filesystem setting.

Hi all, I'm encountering a BLE issue with the newer iPad models featuring the A16 Bionic chip (e.g., iPad 11th Gen). I have an iOS application that runs as a BLE peripheral, and it used to work flawlessly with various central devices. 📱 Device Specs Model: iPad (A16 Bionic) OS: iPadOS 18.6 ✅ Working Setup (Before): iOS app acts as a BLE peripheral (advertises a custom service). Central device (Windows/Linux/Android) could: Discover advertisements Connect to the peripheral Exchange MTU Discover GATT services Communicate bidirectionally ❌ Issue with iPad A16 (Newer Devices): Central device receives advertisements and connects. MTU exchange request is sent by central, but iPad A16 does not respond. The BLE link remains active but only transmits empty PDUs, and communication never proceeds. Same issue observed with third-party apps like BLE HID keyboard — they also fail to connect or communicate on A16 iPads but work on older devices (e.g., iPad 10th Gen and below). 🔍 Debugging So Far: Confirmed that MTU Exchange Request is compliant (Client Rx MTU = 527). Works fine with iPad 10th Gen and earlier. Works with Android, Windows, and even Linux central stacks with older iPads. A16-based iPads seem to silently drop or ignore the MTU request. 🧪 Suspected Cause: Possible regression or behavioral change in LE Privacy handling on newer iPads. Possibly tied to iPadOS version or Bluetooth controller firmware. 🙏 Looking for: Anyone else facing similar BLE issues on iPads with A16? Any known changes to BLE LE Privacy, MTU negotiation, or connection behavior in iPadOS on A16 devices? Any workarounds, entitlements, or configuration changes that fixed the issue? Would appreciate any insights or suggestions. Thank you!

Hello, I have a raw device number, as an input, for external usb/thunderbolt device (i.e. for /dev/disk9 - it is 9). And I want to format it to APFS or read/confirm APFS FS type if it is already formatted. But I can see that APFS container/volume have another disk number (i.e /dev/disk10) in compare with for my raw disk. Is there a guaranteed way to match raw disk number to underlying APFS container/volume disk number? May be some API? Or just add +1 to raw disk number for getting APFS container/volume disk device number?

The command line interface for diskutil is missing the snapshot features there is now no way to take a custom snapshot of a volume and mount it. tmutil doesn’t not allow the flexibility of diskutil when doing research. Please restore this functionality. feedback id: FB19590860

Hello, Starting with macOS 26 beta 4, I’ve noticed that the fflag field in es_event_open_t sometimes contains O_SEARCH instead of the expected FREAD or FWRITE values. According to the documentation, fflag should represent the kernel-applied flags (e.g., FREAD, FWRITE), not the open(2) oflag values. However, in my tests, when intercepting ES_EVENT_TYPE_AUTH_OPEN events, the value appears to match O_SEARCH in certain cases. Is this an intentional change in macOS 26, or could it be a bug in the current beta? If this is expected behavior, could you clarify under what conditions O_SEARCH or some oflag are returned? Environment: macOS 26 beta 4 Endpoint Security Framework Thanks in advance for any clarification!

I am writing an NSFileProviderExtension for my app. Every once in a while it will get to a point where NSFileProviderManager.getDomainsWithCompletionHandler { domains, error in DispatchQueue.main.async { if let error = error { completion(.failure(.domainQueryFailed(error))) } else { completion(.success(domains)) } } } this always fails, once this happens then regardless of what I do - clean build, restart machine, uninstall plugin nothing works. The only way to get back to a wokring state is a full reinstall of the OS. It seems like when this happens Finder gets to a weird irrecoverable state that only a restart can fix. Is there anything I can do to address this? I have a laptop which is in this state. Finder has this image attached

I am trying to list all the installed FS modules. fetchInstalledExtensions seems to only list the system installed modules (exfat.appex and msdos.appex), even though System Settings --> General --> Login Items and Extensions --> File System Extension lists my custom one and is turned on. Is this the expected behavior? Thanks!

We have iOS application to connect and monitor the Wiser smart devices. This application supports WiFi access point change as well. When there is change in the WiFi, wiser devices supports for 3mins BLE mode for re-pairing. When BLE devices are newly commissioning, all devices are being able to discover by CoreBluetooth. But when we try to change the WiFi, Previously connected BLE devices are not being discoverable though they are in pairing mode.

In the latest beta of Ventura (and perhaps earlier versions) there is a section of the System Settings > General > Login Items pane called "Allow in Background". It appears that helpers (LaunchAgents/LaunchDaemons) that are installed by apps are listed here. As you can see in the screenshot below, I have 3 such items installed on my test system. The per User LaunchAgent for the Google Updater, the WireShark LaunchDaemon for the ChmodBPF script, and the LaunchDaemon for my userspace CoreAudio Driver (labelled "Metric Halo Distribution, Inc."). The WireShark and Google Updater have nice user identifiable names associated with them, whereas my Launch Daemon only has my company name associated with it. I don't see anything in the plists for Wireshark or GoogleUpdater that seem to specify this user-visible string, nor in the bundles the plists point to. How do I go about annotating my LaunchDaemon plist or the helper tool's plist so that the string in this pane helps the user properly identify what this Background item is for so that they don't accidentally turn it off and disable the driver they need to use our audio hardware? Obviously, we will document this, but just as obviously users don't always read the docs, and it would be better if the user just could make the immediate association that this Background item is needed for our CoreAudio driver.

I know you guys probably dont care or what to help with this but I got taken down in the support communities because I simply run a beta version (didn’t even discuss it) but here we go **My MacBook Air has multiple accounts and the other users & shared category takes up 100+ gb. When I sign into one of the accounts, that 100+ gb gets moved to System Data. When I look in finder, the user only seems to take up 12 gb, though. I’ve shown hidden items and looked through the library, but it’s not showing anything that’s taking up that much space! **

Hello, I’m a developer at an IT service provider in the banking sector. In the context of an HCE-based payment solution on iOS, we use the Apple Card Session API to receive and process APDU commands. We are currently facing an issue with a specific payment terminal model (CCV): When using this terminal, the Apple Card Session correctly triggers the readerDetected and readerDeselected events, but does not fire the expected received event, even though APDU commands are clearly being sent at the protocol level. This behavior only occurs with this particular CCV terminal in our implementation – with other terminals and on Android devices, the received event is triggered reliably. The same CCV terminal also works without issues when using Apple Pay or PayPal (which also uses HCE → Card Session), and APDU data is transmitted as expected in those cases. Interestingly, in our implementation, roughly every 10th to 20th transaction with this CCV terminal does trigger the received event and APDU commands are delivered — in those rare cases, the payment proceeds successfully. In the system logs, we sometimes see APDU commands marked as invalid, but this also happens in cases where communication works fine, so we’re not sure whether this is actually related to the missing events. Our questions: Has anyone encountered this behavior before – specifically missing received events despite active communication from the terminal? Are there known limitations or specific requirements for payment terminals so that APDU commands are passed through to the Apple Card Session? Are there any diagnostic tools or logs we could use to better narrow down the root cause? At this point, we are unsure whether the issue lies in terminal compatibility, the Apple Card Session itself, or our implementation. Any insights, experiences, or technical hints would be greatly appreciated. Thanks in advance for your help!

When converting a string using libiconv, for certain combinations of strings and encodings, sometimes iconv() crashes Assertion failed: (tmpin - *in <= *inbytes), function _citrus_iconv_std_iconv_convert, file citrus_iconv_std.c, line 1916. This means that libiconv is a debug build since it asserts and also that it doesn't handles certain characters, it should not crash but return some error code. I've reported this problem twice to Apple, nothing happens. FB17715360 and FB17567155 Below is a simple code snippet that illustrates the problem: #include <iconv.h> #import <Foundation/Foundation.h> void TestLibIconv() { NSLog(@"Convert a string from some encoding to some other"); NSLog(@"The in string may have some unknown encoding"); const char *inEnc = "SHIFT_JIS"; // Japanese //const char *inEnc = "CP1252"; // works const char *outEnc = "UTF-8"; NSLog(@"inEnc %s outEnc %s", inEnc, outEnc); iconv_t cd = iconv_open(outEnc, inEnc); if (cd != (iconv_t) -1) { #if 1 // works when this flag isn't set int on = 1; // allow illegal byte sequence iconvctl(cd, ICONV_SET_DISCARD_ILSEQ, &on); #endif const size_t m_kMaxOutChars = 200; char outBuffer[m_kMaxOutChars+1]; memset(outBuffer, 0, sizeof(outBuffer)); char inStr[] = "\"\xe5\""; // crashes - the '\"' character seems to be the problem size_t inbytesleft = strlen(inStr); size_t outbytesleft = m_kMaxOutChars; char *pInBuf = inStr; char *pOutBuf = outBuffer; size_t retVal = iconv(cd, &pInBuf, &inbytesleft, &pOutBuf, &outbytesleft); NSLog(@"iconv() returns %ld", retVal); NSLog(@"outBuffer %s", outBuffer); iconv_close(cd); } }

Hi, In macOS26 beta, our app icon is not showing anymore in the MenuBar. It is also not displayed in the new section "Menu Bar > Allow in the Menu Bar", which seems to be the way to show/hide Menu Bar icons in macOS 26. The icon is correctly displayed and working in macOS 15. Our app is signed and notarized. It also has the "LSUIElement" value set to "true" in the Info.plist file. Is there some new mandatory entitlements to add in order to have our app showing in the "Allow in the Menu Bar" section? Thanks in advance for your help. Regards

To gain exclusive access to keyboard HID devices like Amazon Fire Bluetooth remote controls, my app has been installing a privileged helper tool with SMJobBless in the past. The app - which also has Accessibility permissions - then invoked and communicated with that helper tool through XPC. Now I'm looking into replacing that with a daemon installed through the newer SMAppService APIs, but running into a permission problem: If I try to exclusively open a keyboard HID device from the SMAppService-registered XPC service/daemon (which runs as root as seen in Activity Monitor), IOHIDDeviceOpen returns kIOReturnNotPermitted. I've spent many hours now trying to get it to work, but so far didn't find a solution. Could it be that XPC services registered as a daemon through SMAppService do not inherit the TCC permissions from the invoking process (here: Accessibility permissions) - and the exclusive IOHIDDeviceOpen therefore fails?

Hello, The following simple code leads to memory leak IOHIDManagerRef hidManager = IOHIDManagerCreate(kCFAllocatorDefault, kIOHIDManagerOptionNone); ... IOHIDManagerSetDeviceMatching(hidManager, matchingCriteria); CFRelease(matchingCriteria); if (IOHIDManagerOpen(hidManager, kIOHIDOptionsTypeNone) != kIOReturnSuccess) { return 1; } ... if (IOHIDManagerClose(hidManager, kIOHIDOptionsTypeNone) != kIOReturnSuccess) { return 1; } CFRelease(hidManager); The following leaks report: STACK OF 2 INSTANCES OF ROOT LEAK: : 17 dyld 0x19b3aeb98 start + 6076 16 a.out 0x1027147e4 main + 200 15 com.apple.framework.IOKit 0x19f6781b8 __ApplyToDevices + 100 14 com.apple.CoreFoundation 0x19b801cfc CFSetApplyFunction + 224 13 com.apple.CoreFoundation 0x19b801dc0 CFBasicHashApply + 148 12 com.apple.CoreFoundation 0x19b801f94 __CFSetApplyFunction_block_invoke + 28 11 com.apple.framework.IOKit 0x19f6784c8 __IOHIDManagerDeviceApplier + 76 10 com.apple.framework.IOKit 0x19f5e18ec IOHIDDeviceOpen + 56 9 com.apple.iokit.IOHIDLib 0x102992cf0 0x102984000 + 60656 8 com.apple.iokit.IOHIDLib 0x10298d8ec 0x102984000 + 39148 7 com.apple.iokit.IOHIDLib 0x10298d3e8 0x102984000 + 37864 6 com.apple.framework.IOKit 0x19f5d5760 IORegistryEntrySearchCFProperty + 420 5 com.apple.framework.IOKit 0x19f5d66b4 IOCFUnserializeBinary + 480 4 com.apple.CoreFoundation 0x19b7d9ef0 __NSArrayM_new + 60 3 com.apple.CoreFoundation 0x19b7c2378 __CFAllocateObject + 20 2 libobjc.A.dylib 0x19b35b7ec class_createInstance + 76 1 libsystem_malloc.dylib 0x19b56ba40 _calloc + 88 0 libsystem_malloc.dylib 0x19b581270 _malloc_zone_calloc_instrumented_or_legacy + 132 _ I have not found any mention in documentation what should be released before/after the call IOHIDManagerClose. Are there any advices? Thank you in advance!

Hey, we also opened a bug regarding this behavior on April, back when you introduce the new event on MacOs 15.4 The bug ticket is: FB17139326 Starting macOs 15.4 you added a new event for the system extension framework named: tcc_modify The event should be triggered every-time there is a change regarding the tcc db (granted / revoked using various ways). One of the ways you can grant / revoke tcc db permission is by changing the user sqlite with root permissions. You can change various permissions regarding the user for example the apps that allowed to use microphone permissions. It is expected that when granted / revoked permissions using sqlite for microphone we will get notify from the system extension for tcc modify event. but the actual result is that the permission is added without any tcc modify event. We wanted to know if this is intentional that changing the user tcc db with root permissions, using sqlite and not conventional methods (user popup / settings), suppose to not initiate an event, and we should monitor them using other methods. Thank you, Idan

There are inconsistent behaviors in sleep/wake notification callbacks across different MacBook devices and macOS versions when the device is not connected to power, with or without external displays, entering sleep mode by closing the lid, and waking up from sleep by opening the lid. When monitoring the following Objective-C notifications: NSWorkspaceScreensDidSleepNotification NSWorkspaceScreensDidWakeNotification NSWorkspaceWillSleepNotification NSWorkspaceDidWakeNotification Different devices exhibit varying notification trigger patterns: Some devices trigger all four notifications properly Some devices fail to trigger NSWorkspaceScreensDidWakeNotification Some devices fail to trigger NSWorkspaceDidWakeNotification Some devices fail to trigger NSWorkspaceWillSleepNotification These inconsistencies make it challenging to implement reliable sleep/wake detection logic across different MacBook models and macOS versions.

I want to fully control the BLE send timing myself, instead of relying on the iOS system. When I try to send a large data block using BLE (i.e., splitting it and sending multiple times), I follow Apple’s official guide. However, after the first successful updateValue() call in my loop, the second call always fails unless I wait for the peripheralManagerIsReady(toUpdateSubscribers:) callback. This callback timing is managed by the system, so I can’t control exactly when I can send the next packet. If I send data manually by clicking a button, updateValue() always returns true—even if I add a long delay (like sleep(10)) between calls. But in a loop, after the first send, updateValue() returns false until the thread leaves or the callback occurs. I suspect this is a thread or queue issue blocking subsequent sends. I also tried using DispatchQueue.global().async {} in the loop, but the result is the same. Is there any way to fully control when I call updateValue(), without waiting for peripheralManagerIsReady()? Or is this a limitation of iOS BLE? Thank you!