We are testing BLE connectivity between a custom device (nRF52832, nRF5 SDK) and the latest iPad A16. Setup: Peripheral: nRF52832 running Nordic’s SoftDevice (nRF5 SDK v13) . Central: iPad A16 (Latest iPadOS 18.6.2). Issue: During the connection procedure, the iPad sends a Link Layer Control PDU with Opcode 0xFF. This is a vendor-specific LL control opcode. Our peripheral does not respond, since the Nordic SoftDevice does not implement handling for 0xFF. As a result, the link stability is affected (connection may drop / negotiation fails). Observations: With older iPads and iPhones (A14/A15 chips), no such control opcode is sent — connection and notifications work fine. Only the iPad A16 sends this vendor-specific opcode. Nordic’s SoftDevice responds to standard LL control opcodes, but ignores vendor-specific ones. Questions: Is this 0xFF LL control PDU expected behavior on A16 devices? Should peripherals ignore vendor-specific LL opcodes, or is a response required for stable connection? Are there known changes in BLE Link Layer negotiation with iPad A16?

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 or the Mac's console app, then the logging output is verbose and as expected. But if I download that same app onto an iOS 26 handset, there's nothing. Logging is visible in the Xcode console, however sometimes there are situations where you need console logging with a TestFlight build. What happened? Was this an intentional change? Why. This is a major hindrance in diagnosing issues / bugs etc.

A user of my app noticed that when using it to move a file to the trash on an USB drive, the trash doesn't show the file until unmounting the drive and mounting it again. I was able to reproduce it with one of my own USB drives, but with another USB drive it doesn't reproduce. All USB drives are formatted APFS. When moving a file to the trash from the Finder, both USB drives immediately list it in the trash. Is this a macOS bug, or am I doing something wrong? I created FB19941168. let openPanel = NSOpenPanel() openPanel.runModal() let url = openPanel.urls[0] do { var result: NSURL? try FileManager.default.trashItem(at: url, resultingItemURL: &result) print(result as Any) } catch { fatalError(error.localizedDescription) }

In the context of a FPUIActionExtensionViewController module the prepare method is defined like this: override func prepare(forAction actionIdentifier: String, itemIdentifiers: [NSFileProviderItemIdentifier]) { So you would expect the itemIdentifiers list to be the item identifier but instead it is a list of the internal fileprovider IDs like: __fp/fs/docID(6595461) So this is a bit problematic because the only way to recover the ID is by using getUserVisibleURL to get the path which is not great. Is there a better way ? Am I missing something ? Thanks,

I've gotten to the point where I can use the mount(8) command line tool and the -t option to mount a file system using my FSKit file system extension, in which case I can see a process for my extension launch, probe, and perform the other necessary actions. However, when plugging in my USB flash drive or trying to mount with diskutil mount, the file system does not mount: $ diskutil mount disk20s3 Volume on disk20s3 failed to mount If you think the volume is supported but damaged, try the "readOnly" option $ diskutil mount readOnly disk20s3 Volume on disk20s3 failed to mount If you think the volume is supported but damaged, try the "readOnly" option Initially I thought it would be enough to just implement probeExtension(resource:replyHandler:) and the system would handle the rest, but this doesn't seem to be the case. Even a trivial implementation that always returns .usable doesn't cause the system to use my FSModule, even though I've enabled my extension in System Settings > General > Login Items & Extensions > File System Extensions. From looking at some of the open source msdos and Disk Arb code, it seems like my app extension needs to list FSMediaTypes to probe. I eventually tried putting this in my Info.plist of the app extension: <key>FSMediaTypes</key> <dict> <key>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</string> <key>Leaf</key> <true/> </dict> </dict> <key>0FC63DAF-8483-4772-8E79-3D69D8477DE4</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>0FC63DAF-8483-4772-8E79-3D69D8477DE4</string> <key>Leaf</key> <true/> </dict> </dict> <key>Whole</key> <dict> <key>FSMediaProperties</key> <dict> <key>Leaf</key> <true/> <key>Whole</key> <true/> </dict> </dict> <key>ext4</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>ext4</string> <key>Leaf</key> <true/> </dict> </dict> </dict> </plist> (For reference, the partition represented by disk20s3 has a Content Hint of 0FC63DAF-8483-4772-8E79-3D69D8477DE4 and Leaf is True which I verified using IORegistryExplorer.app from the Xcode additional tools.) Looking in Console it does appear now that the system is trying to use my module (ExtendFS_fskit) to probe when I plug in my USB drive, but I never see a process for my extension actually launch when trying to attach to it from Xcode by name (unlike when I use mount(8), where I can do this). However I do see a Can't find the extension for <private> error which I'm not sure is related but does sound like the system can't find the extension for some reason. The below messages are when filtering for "FSKit": default 19:14:53.455826-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, ongoing. default 19:14:53.456038-0400 fskitd Incomming connection, entitled 1 default 19:14:53.456064-0400 fskitd [0x7d4172e40] activating connection: mach=false listener=false peer=true name=com.apple.filesystems.fskitd.peer[350].0x7d4172e40 default 19:14:53.456123-0400 fskitd Hello FSClient! entitlement yes default 19:14:53.455902-0400 diskarbitrationd [0x7461d8dc0] activating connection: mach=true listener=false peer=false name=com.apple.filesystems.fskitd default 19:14:53.456151-0400 diskarbitrationd Setting remote protocol to all XPC default 19:14:53.456398-0400 fskitd About to get current agent for 501 default 19:14:53.457185-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, failure. error 19:14:53.456963-0400 fskitd -[fskitdXPCServer applyResource:targetBundle:instanceID:initiatorAuditToken:authorizingAuditToken:isProbe:usingBlock:]: Can't find the extension for <private> (I only see these messages after plugging my USB drive in. When running diskutil mount, I see no messages in the console when filtering by FSKit, diskarbitrationd, or ExtendFS afterward. It just fails.) Is there a step I'm missing to get this to work, or would this be an FSKit bug/current limitation?

The most recent KDK for MacOS Sequoia that appears in the Downloads is for MacOS 15.5 (24F74), but the current version of MacOS Sequoia is 15.6 (24G84) and 15.7 (24G207) is in RC. Is there an ETA for the KDKs for 15.6 (24G84) and 15.7 (24G207) to be made available to download? Many thanks for any help.

Connect with ios in android

Hello. When testing with the Endpoint Security Framework for the AUTH_OPEN event, I found that the deadline was 15 seconds, but the actual process termination occurred at 5 or 6 seconds. Is this intended?

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 notice that there are two types of nfc session: "NFCTagReaderSession" this session in order to get tag's basic info like uid/type which call back function is tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) "NFCNDEFReaderSession" this session in order to get ndef message in tag which call back function is readerSession(_ session: NFCNDEFReaderSession, didDetectNDEFs messages: [NFCNDEFMessage]) My problem: How can i get tag's basic info and tag's ndef message(if it exists) simultaneously in one session or in one callback function.

Hello fellow developers, I’m currently working on an app for controlling electric vehicle charging stations, and I’ve encountered some issues related to Bluetooth file transfer that I hope you can help with. For the OTA (Over-the-Air) update feature in this app, we need to transfer files via Bluetooth. These files are in .bin format and range in size from 1MB to 10MB. I’ve heard that Classic Bluetooth on iOS requires certification to use—is this true? If so, what are the general processes and requirements for this certification? Additionally, when considering BLE (Bluetooth Low Energy) for this purpose, we face challenges with transfer speed as well as file fragmentation and reassembly. Are there any optimization strategies for transferring large files over BLE that can improve speed while ensuring the integrity and accuracy of file fragmentation and reassembly? Finally, I’m wondering if there are any Bluetooth file transfer-related demos available for reference, especially sample code for iOS that handles file sizes and formats similar to what I described. This would be extremely helpful for resolving my current issues. Thank you very much for taking the time to read my questions. I look forward to your valuable advice and experience sharing.

We're trying out using a 3rd party java applet as part of our suite, but we're getting inconsistent results that seem to be related to signing. "Fortunately," I can trivially reproduce it! It pops up a dialogue saying "Apple could not verify “java” is free of malware that may harm your Mac or compromise your privacy"; if I click through the dialogue and the system settings, it then does the same for each of the dylib files. The file seems to be signed, so is this a matter of it not being notarized? Will we have to sign and notarize them all on our own?

Hello, I'm playing around with the FSKit API and I'm looking for programmatic ways to mount a file system backed by an FSKit extension. Currently, I could only find the new -F option in the mount command but I would prefer if I could avoid executing comman line tools. I checked the DiskArbitration framework but couldn't find anything specific for FSKit there. Thanks

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.

The unified system log on Apple platforms gets a lot of stick for being ‘too verbose’. I understand that perspective: If you’re used to a traditional Unix-y system log, you might expect to learn something about an issue by manually looking through the log, and the unified system log is way too chatty for that. However, that’s a small price to pay for all its other benefits. This post is my attempt to explain those benefits, broken up into a series of short bullets. Hopefully, by the end, you’ll understand why I’m best friends with the system log, and why you should be too! If you have questions or comments about this, start a new thread and tag it with OSLog so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Your Friend the System Log Apple’s unified system log is very powerful. If you’re writing code for any Apple platform, and especially if you’re working on low-level code, it pays to become friends with the system log! The Benefits of Having a Such Good Friend The public API for logging is fast and full-featured. And it’s particularly nice in Swift. Logging is fast enough to leave log points [1] enabled in your release build, which makes it easier to debug issues that only show up in the field. The system log is used extensively by the OS itself, allowing you to correlate your log entries with the internal state of the system. Log entries persist for a long time, allowing you to investigate an issue that originated well before you noticed it. Log entries are classified by subsystem, category, and type. Each type has a default disposition, which determines whether that log entry is enable and, if it is, whether it persists in the log store. You can customise this, based on the subsystem, category, and type, in four different ways: Install a configuration profile created by Apple (all platforms) [2]. Add an OSLogPreferences property to your app’s Info.plist (all platforms). Run the log tool with the config command (macOS only) Create and install a custom configuration profile with the com.apple.system.logging payload (macOS only). When you log a value, you may tag it as private. These values are omitted from the log by default but you can configure the system to include them. For information on how to do that, see Recording Private Data in the System Log. The Console app displays the system log. On the left, select either your local Mac or an attached iOS device. Console can open and work with log snapshots (.logarchive). It also supports surprisingly sophisticated searching. For instructions on how to set up your search, choose Help > Console Help. Console’s search field supports copy and paste. For example, to set up a search for the subsystem com.foo.bar, paste subsystem:com.foo.bar into the field. Console supports saved searches. Again, Console Help has the details. Console supports viewing log entries in a specific timeframe. By default it shows the last 5 minutes. To change this, select an item in the Showing popup menu in the pane divider. If you have a specific time range of interest, select Custom, enter that range, and click Apply. Instruments has os_log and os_signpost instruments that record log entries in your trace. Use this to correlate the output of other instruments with log points in your code. Instruments can also import a log snapshot. Drop a .logarchive file on to Instruments and it’ll import the log into a trace document, then analyse the log with Instruments’ many cool features. The log command-line tool lets you do all of this and more from Terminal. The log stream subcommand supports multiple output formats. The default format includes column headers that describe the standard fields. The last column holds the log message prefixed by various fields. For example: cloudd: (Network) [com.apple.network:connection] nw_flow_disconnected … In this context: cloudd is the source process. (Network) is the source library. If this isn’t present, the log came from the main executable. [com.apple.network:connection] is the subsystem and category. Not all log entries have these. nw_flow_disconnected … is the actual message. There’s a public API to read back existing log entries, albeit one with significant limitations on iOS (more on that below). Every sysdiagnose log includes a snapshot of the system log, which is ideal for debugging hard-to-reproduce problems. For more details on that, see Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. For general information about sysdiagnose logs, see Bug Reporting > Profiles and Logs. But you don’t have to use sysdiagnose logs. To create a quick snapshot of the system log, run the log tool with the collect subcommand. If you’re investigating recent events, use the --last argument to limit its scope. For example, the following creates a snapshot of log entries from the last 5 minutes: % sudo log collect --last 5m For more information, see: os > Logging OSLog log man page os_log man page (in section 3) os_log man page (in section 5) WWDC 2016 Session 721 Unified Logging and Activity Tracing [1] Well, most log points. If you’re logging thousands of entries per second, the very small overhead for these disabled log points add up. [2] These debug profiles can also help you focus on the right subsystems and categories. Imagine you’re investigating a CryptoTokenKit problem. If you download and dump the CryptoTokenKit debug profile, you’ll see this: % security cms -D -i "CTK_iOS_Logging.mobileconfig" | plutil -p - { … "PayloadContent" => [ 0 => { … "Subsystems" => { "com.apple.CryptoTokenKit" => {…} "com.apple.CryptoTokenKit.APDU" => {…} } } ] … } That’s a hint that log entries relevant to CryptoTokenKit have a subsystem of either com.apple.CryptoTokenKit and com.apple.CryptoTokenKit.APDU, so it’d make sense to focus on those. Foster Your Friendship Good friendships take some work on your part, and your friendship with the system log is no exception. Follow these suggestions for getting the most out of the system log. The system log has many friends, and it tries to love them all equally. Don’t abuse that by logging too much. One key benefit of the system log is that log entries persist for a long time, allowing you to debug issues with their roots in the distant past. But there’s a trade off here: The more you log, the shorter the log window, and the harder it is to debug such problems. Put some thought into your subsystem and category choices. One trick here is to use the same category across multiple subsystems, allowing you to track issues as they cross between subsystems in your product. Or use one subsystem with multiple categories, so you can search on the subsystem to see all your logging and then focus on specific categories when you need to. Don’t use too many unique subsystem and context pairs. As a rough guide: One is fine, ten is OK, 100 is too much. Choose your log types wisely. The documentation for each OSLogType value describes the default behaviour of that value; use that information to guide your choices. Remember that disabled log points have a very low cost. It’s fine to leave chatty logging in your product if it’s disabled by default. Some app extension types have access to extremely sensitive user data and thus run in a restricted sandbox, one that prevents them from exporting any data. For example, an iOS Network Extension content filter data provider runs in such a sandbox. While I’ve never investigated this for other app extension types, an iOS NE content filter data provider cannot record system log entries. This restriction only applies if the provider is distribution signed. A development-signed provider can record system log entries. Apple platforms have accumulated many different logging APIs over the years. All of these are effectively deprecated [1] in favour of the system log API discussed in this post. That includes: NSLog (documented here) CFShow (documented here) Apple System Log (see the asl man page) syslog (see the syslog man page) Most of these continue to work, simply calling through to the underlying system log. However, there are good reasons to move on to the system log API directly: It lets you control the subsystem and category, making it much easier to track down your log entries. It lets you control whether data is considered private or public. In Swift, the Logger API is type safe, avoiding the classic bug of mixing up your arguments and your format specifiers. [1] Some formally and some informally. No Friend Is Perfect The system log API is hard to wrap. The system log is so efficient because it’s deeply integrated with the compiler. If you wrap the system log API, you undermine that efficiency. For example, a wrapper like this is very inefficient: -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- void myLog(const char * format, ...) { va_list ap; va_start(ap, format); char * str = NULL; vasprintf(&str, format, ap); os_log_debug(sLog, "%s", str); free(str); va_end(ap); } -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- This is mostly an issue with the C API, because the modern Swift API is nice enough that you rarely need to wrap it. If you do wrap the C API, use a macro and have that pass the arguments through to the underlying os_log_xyz macro. Note If you’re curious about why adding a wrapper is bad, see my explanation on this thread. iOS has very limited facilities for reading the system log. Currently, an iOS app can only read entries created by that specific process, using .currentProcessIdentifier scope. This is annoying if, say, the app crashed and you want to know what it was doing before the crash. What you need is a way to get all log entries written by your app (r. 57880434). There are two known bugs with the .currentProcessIdentifier scope. The first is that the .reverse option doesn’t work (r. 87622922). You always get log entries in forward order. The second is that the getEntries(with:at:matching:) method doesn’t honour its position argument (r. 87416514). You always get all available log entries. Xcode 15 beta has a shiny new console interface. For the details, watch WWDC 2023 Session 10226 Debug with structured logging. For some other notes about this change, search the Xcode 15 Beta Release Notes for 109380695. In older versions of Xcode the console pane was not a system log client (r. 32863680). Rather, it just collected and displayed stdout and stderr from your process. This approach had a number of consequences: The system log does not, by default, log to stderr. Xcode enabled this by setting an environment variable, OS_ACTIVITY_DT_MODE. The existence and behaviour of this environment variable is an implementation detail and not something that you should rely on. Xcode sets this environment variable when you run your program from Xcode (Product > Run). It can’t set it when you attach to a running process (Debug > Attach to Process). Xcode’s Console pane does not support the sophisticated filtering you’d expect in a system log client. When I can’t use Xcode 15, I work around the last two by ignoring the console pane and instead running Console and viewing my log entries there. If you don’t see the expected log entries in Console, make sure that you have Action > Include Info Messages and Action > Include Debug Messages enabled. The system log interface is available within the kernel but it has some serious limitations. Here’s the ones that I’m aware of: Prior to macOS 14.4, there was no subsystem or category support (r. 28948441). There is no support for annotations like {public} and {private}. Adding such annotations causes the log entry to be dropped (r. 40636781). The system log interface is also available to DriverKit drivers. For more advice on that front, see this thread. Metal shaders can log using the interface described in section 6.19 of the Metal Shading Language Specification. Revision History 2025-08-19 Added information about effectively deprecated logging APIs, like NSLog. 2025-08-11 Added information about the restricted sandbox applied to iOS Network Extension content filter data providers. 2025-07-21 Added a link to a thread that explains why wrapping the system log API is bad. 2025-05-30 Fixed a grammo. 2025-04-09 Added a note explaining how to use a debug profile to find relevant log subsystems and categories. 2025-02-20 Added some info about DriverKit. 2024-10-22 Added some notes on interpreting the output from log stream. 2024-09-17 The kernel now includes subsystem and category support. 2024-09-16 Added a link to the the Metal logging interface. 2023-10-20 Added some Instruments tidbits. 2023-10-13 Described a second known bug with the .currentProcessIdentifier scope. Added a link to Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. 2023-08-28 Described a known bug with the .reverse option in .currentProcessIdentifier scope. 2023-06-12 Added a call-out to the Xcode 15 Beta Release Notes. 2023-06-06 Updated to reference WWDC 2023 Session 10226. Added some notes about the kernel’s system log support. 2023-03-22 Made some minor editorial changes. 2023-03-13 Reworked the Xcode discussion to mention OS_ACTIVITY_DT_MODE. 2022-10-26 Called out the Showing popup in Console and the --last argument to log collect. 2022-10-06 Added a link WWDC 2016 Session 721 Unified Logging and Activity Tracing. 2022-08-19 Add a link to Recording Private Data in the System Log. 2022-08-11 Added a bunch of hints and tips. 2022-06-23 Added the Foster Your Friendship section. Made other editorial changes. 2022-05-12 First posted.

Hi - from the NFCPaymentTagReaderSession documentation on https://developer.apple.com/documentation/corenfc/nfcpaymenttagreadersession , it's not clear how it should be used to communicate with a payment tag, since the initial SELECT command is handled by NFCPaymentTagReaderSession automatically. Generally in a payment context, the SELECT response from the payment tag would contain necessary data for subsequent exchanges. Could you please help me understand how to receive the SELECT response from NFCPaymentTagReaderSession? Thank you for your help.

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?

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!

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!