I'm having a problem on macOS 26 that has not happened on previous macOS versions. When I call guard url.startAccessingSecurityScopedResource() else { return } try url.bookmarkData(options: [.withSecurityScope]) with url being "file:///", I get an error Error Domain=NSCocoaErrorDomain Code=256 "File descriptor doesn't match the real path." Given that Google returns 0 results on this error, I suppose this is a macOS 26 novelty. (The bookmark data created before upgrading to 26 resolve well). Does anyone already met this or have an idea on how to get around it? The app is a file manager, so having bookmarked access to "/" is crucial.

Dear Apple Team,​ We are reaching out regarding several compatibility issues our app users have encountered after upgrading to iOS 26. These issues not only affect our application but also seem to impact the system's native settings, which has raised concerns about the universality of these problems.​ Problem Description​ Bluetooth Functionality: When users attempt to use the Bluetooth feature within our app after upgrading to iOS 26, the app freezes completely. What's more, when accessing the Bluetooth section in the system Settings app, it also freezes and ultimately crashes.​ Location Service: The location service on the device becomes inoperable after the iOS 26 upgrade. However, both the Bluetooth and location service issues are resolved after the user restarts the device.​ 2. Questions​ Universality: We are eager to know if these issues are exclusive to our app or are a more widespread problem among other applications on iOS 26. Are these known compatibility glitches in iOS 26? ​ Avoidance: Is there any guidance or best - practice that we, as developers, can follow to avoid these issues in our app? For example, are there specific API calls or configurations that need to be adjusted? ​ System - level Impact: If these are system - level bugs related to Bluetooth and location services, will they affect all apps that rely on these features? Or are there certain app - level mitigations that can be implemented? ​ We would greatly appreciate it if you could provide us with any insights, solutions, or information regarding these issues. Your prompt response will be crucial for us to address these problems and ensure a smooth user experience for our customers.​ Thank you in advance for your assistance.​ Best regards,

On iOS when I run my Autofill extension target from Xcode and attach to Safari, Swift print() statements appear in the Xcode console log. If I run the same extension on MacOS Sequoia, no log messages appear. The header strip in the debugger area remains blank. Anyone know how to see these log messages? In both cases, the scheme is set to Debug build, and "Debug Executable" is not selected. In fact, for iOS the "Debug Executable" is grayed out. When I set Debug Executable on the MacOS run, I get failure to attach with a warning about permission to debug Safari.

I am currently developing a BLE device that connects to iPhone and transmits a large amount of data within a certain period of time. The BLE device sends data to iPhone under the following conditions, but the transfer speed does not meet my expectations. Could you guys tell me how I can further increase the transfer speed. Conditions: iPhone14 Pro iOS 17.0 Connection Interval = 15ms More Data Flag = valid Characteristic sending = Notification

I would like to understand the recommended App Store–compliant method for uninstalling applications, particularly in cases where certain apps are owned by root rather than the user. Currently, since root-owned apps cannot be uninstalled, I display the error message: 'App name couldn’t be moved to the Trash because you don’t have permission to access it. please run sudo chown -R $user /application/appname and try again' I then instruct users to change the ownership of the app and try again, but this approach does not appear to align with App Store policies.

Hi, I’m expecting the demo from Apple, but I think I’m seeing different behavior on my end. Here are the steps I followed: Run the SampleEndpointApp example. Copy SampleEndpointApp to the /Applications folder. Run and enable the Extension and Full Disk Access → Everything works properly. I modify something in the example and start again from step #1, but nothing gets updated as shown in the demo video. The only way I can make it work is by going into Settings, manually removing the ES extension, and then running the app again. My concern is: if I deliver the application to clients, how can I properly update the extension without requiring them to manually remove it first? Thanks,

Environment: iOS Version: 26.0 Device Model: iPhone 12 Pro Max Peripheral: [Fill in peripheral name/model/firmware version] Steps to Reproduce: Connect to the peripheral using CoreBluetooth. Discover services via discoverServices. Discover characteristics via discoverCharacteristics. Call setNotifyValue:YES for a characteristic that supports notifications (Notify or Indicate). Capture the HCI log during the above process. Expected Result: After calling setNotifyValue:YES, CoreBluetooth should write the appropriate value to the Client Characteristic Configuration descriptor (UUID: 0xFCF8) to enable notifications, and subsequent notifications should be received from the peripheral. Actual Result: After calling setNotifyValue:YES, no subscription action is triggered. HCI logs show that the subscription write to the CCC descriptor (0xFCF8) is missing. The target service and characteristic values have already been discovered prior to calling setNotifyValue:YES. Additional Information: HCI log screenshot attached below highlights the moment after setNotifyValue:YES was invoked, showing no GATT Write Request to the CCC descriptor. Full HCI log file is also attached for reference. 11:29:38:165: Call setNotifyValue: YES

Is it possible to use the Matter.xcframework without the MatterSupport extension for onboarding a Matter device to our own ecosystem(own OTBR and matter controller) for an official App Store release? Currently, we can achieve this in developer mode by adding the Bluetooth Central Matter Client Developer mode profile (as outlined here https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/darwin.md). For an official release, what entitlements or capabilities do we need to request approval from Apple to replace the Bluetooth Central Matter Client Developer mode profile? Thank you for your assistance.

Description: The issue with USB FAT32 is seen in Sequoia OS. Most of the times issue is seen when FAT32 USB is mounted along with other USBs like XFAT. The scenario is where USB mounting is monitored using Endpoint Security framework event ES_EVENT_TYPE_AUTH_MOUNT and when event is received, it will be denied for mounting is it is in read-write mode. And, program tries to mount the USB in read-only mode. Steps to Reproduce: Use the xcode program (which will be sent) for testing. Run the executable on macos having Sequoia OS. start executing the binary after successful compilation. Make sure it's running. Take 2 USB drives one with FAT32 and another one with XFAT. Try to mount the USBs and watch the logs on the terminal where the binary is running. We can see, the USB mounting in read-only mode fails for FAT32 where as it passes for other USB. The issue with mounting is not seen always, but, seen when more than 1 USB mounted and FAT32 we see most of the times. Once the mounting fails for the USB, we keep seeing this issue if we try to mount the USB using command line or any other way, until we remove the device and reconnect it. #include <EndpointSecurity/EndpointSecurity.h> #include <bsm/libbsm.h> #include <iostream> #include <os/log.h> #define MAX_THREADS_LIMIT 64 es_client_t *g_client = nullptr; dispatch_queue_t dispatchQueue; static std::atomic<int> m_numThreads; bool mountVolumeCommandLine(const std::string diskPath, const bool &isReadOnly) { std::string command(""); const std::string quote = "\""; if(isReadOnly) { command = "diskutil mount readOnly "+ quote + diskPath + quote; } else { command = "diskutil mount "+ quote + diskPath + quote; } FILE *mount = popen(command.c_str(), "r"); if (mount == NULL) { os_log_error(OS_LOG_DEFAULT, "Failure!! mounting of %{public}s failed using command = %{public}s", diskPath.c_str(),command.c_str()); return false; } else { std::string result = ""; os_log(OS_LOG_DEFAULT, "successful!! executed mount for %{public}s using command = %{public}s ",diskPath.c_str(), command.c_str()); } pclose(mount); return true; } void handleEvents(const es_message_t *msg) { m_numThreads++; switch(msg->event_type) { case ES_EVENT_TYPE_AUTH_MOUNT: { std::string diskPath = msg->event.mount.statfs->f_mntfromname; std::string volumePath = msg->event.mount.statfs->f_mntonname; mountVolumeCommandLine(diskPath, true); break; } default: break; } m_numThreads--; } bool sendAuthResponse(const es_message_t *msg, const es_auth_result_t &result) { es_respond_result_t res = es_respond_auth_result(g_client, msg, result, false); if (res != ES_RESPOND_RESULT_SUCCESS) { os_log_error(OS_LOG_DEFAULT, "SampleEndpointSecurity Failed to respond to auth event error"); return false; } return true; } int createESClient(const es_handler_block_t &handler) { dispatchQueue = dispatch_queue_create("com.test.es_notify", DISPATCH_QUEUE_SERIAL); dispatch_set_target_queue(dispatchQueue, dispatch_get_global_queue(QOS_CLASS_BACKGROUND, 0)); while(1) { es_new_client_result_t res = es_new_client(&g_client, handler); if(ES_NEW_CLIENT_RESULT_SUCCESS != res) { g_client = nullptr; std::cout<<"client creation failed"<<std::endl; if(ES_NEW_CLIENT_RESULT_ERR_NOT_ENTITLED == res) { os_log_error(OS_LOG_DEFAULT, "SampleEndpointSecurity ESClient creation Error: Program requires proper entitlement"); sleep(300); } else if(ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED == res) { os_log_error(OS_LOG_DEFAULT,"SampleEndpointSecurity ESClient creation Error: Program needs proper permission for using ESClient"); } else { os_log_error(OS_LOG_DEFAULT,"SampleEndpointSecurity ESClient creation Error: %d", res); } return 1; } else { break; } } es_clear_cache_result_t resCache = es_clear_cache(g_client); if(ES_CLEAR_CACHE_RESULT_SUCCESS != resCache) { os_log_error(OS_LOG_DEFAULT, "\n SampleEndpointSecurity es_clear_cache: %d\n", resCache); return 1; } return 0; } int main() { es_handler_block_t handler = ^void(es_client_t * _Nonnull, const es_message_t * _Nonnull msg){ bool processEvent = false; if(!msg->process->is_es_client) { switch(msg->event_type) { case ES_EVENT_TYPE_AUTH_MOUNT: { std::string diskPath = msg->event.mount.statfs->f_mntfromname; std::string volumePath = msg->event.mount.statfs->f_mntonname; long flags = msg->event.mount.statfs->f_flags; if(flags & MNT_RDONLY) { os_log(OS_LOG_DEFAULT, "ALLOW readOnly mount event for volumePath= %{public}s and diskPath=%{public}s", volumePath.c_str(), diskPath.c_str()); sendAuthResponse(msg, ES_AUTH_RESULT_ALLOW); } else { os_log(OS_LOG_DEFAULT, "DENY the mount event for volumePath=%{public}s and diskPath=%{public}s", volumePath.c_str(), diskPath.c_str()); sendAuthResponse(msg, ES_AUTH_RESULT_DENY); processEvent = true; } break; } default: { os_log(OS_LOG_DEFAULT,"SampleEndpointSecurity default case event_type: (%d)", msg->event_type); break; // Not interested } } if(processEvent && m_numThreads.load() < MAX_THREADS_LIMIT) { es_retain_message(msg); dispatch_async(dispatchQueue, ^{ handleEvents(msg); es_release_message(msg); }); } } }; if(createESClient(handler) == 1) { return 1; } es_event_type_t events[] = {ES_EVENT_TYPE_AUTH_MOUNT }; es_return_t subscribed = es_subscribe(g_client, events, // Count of es_event_type_t entries stored in events[] sizeof(events) / sizeof(es_event_type_t) ); if(ES_RETURN_ERROR == subscribed) { os_log_error(OS_LOG_DEFAULT, "SampleEndpointSecurity es_subscribe: ES_RETURN_ERROR\n"); return 1; } dispatch_main(); return 0; }

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 [2], 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. [2] Although you might bump into new restrictions. For example, the macOS Tahoe 26 Release Notes describe such a change for NSLog. 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 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 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-09-18 Added a link to the macOS Tahoe 26 Release Notes discussion of NSLog. Remove the beta epithet when referring to Xcode 15. It’s been released for a while now (-: 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.

I'm trying to use FSKit to create a File System Extension that can read MFS-formatted disk images, following the old MFSLives sample project for reference. I have a well-formed MFS formatted img file that I'm trying to mount, but I'm having trouble getting the system to actually use my FSModule. DiskImageMounter fails to mount the img file, but I'm able to use it to attach the image as a device by clicking "Ignore" when it prompts me that it isn't able to read the disk. This is effectively the same as using the hdiutil command in Terminal. hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount Sample.img I've read that FSKit isn't fully integrated with Disk Arbitration yet, so I decided to see if I could force the system to use my extension by using the mount command. mkdir /tmp/Sample mount -F -t MFS disk54 /tmp/Sample Watching the logs in Console, I can see that fskit_agent sees my extension in its "New Modules List", and I see an MFS process gets launched and logs messages from com.apple.running and com.apple.xpc. However, the logs from the MFS process end there, and don't include any of my debug logs, which should be posted when my FSFileSystem subclass is created or when probeResource is called. Ultimately the mount command fails with exit code 69 and prints the following error message: mount: Probing resource: The operation couldn’t be completed. Permission denied mount: Unable to invoke task I've checked everything I could think of: The extension is enabled in System Settings. The extension has the FSKit Module capability added in Xcode. The Info.plist sets the FSSupportsBlockResources key to YES. The Info.plist sets both the FSName and FSShortName keys to MFS. The extension has its Team set to my developer account, with Xcode setting the Provisioning Profile and Signing Certificate automatically. The hosting app has its Team set to my developer account with the "Development" signing certificate. I wanted to see if it was something with my project configuration or implementation, so I downloaded the KhaosT/FSKitSample project from GitHub. Once I got that building, I tried mounting a disk image using the MyFS extesnion, but my system wouldn't run that either. Is there something about the system configuration I should be aware of to enable File System Extensions? I have my MFS extension showing up and enabled, but I'm not sure if there's something I'm missing that I still have to do. Is there a capability or signing requirement I didn't list that's required for the extension to run? The documentation doesn't specify anything about the entitlements, signing capabilities, or Info.plist keys, so I'm not sure what I should be looking for. I'm running macOS Sequoia 15.6.1 on an M2 Max MacBook Pro, and I'm building my project with Xcode 26 beta 6.

I developed an app that uses the Core NFC framework to read tags. The feature works correctly on iOS 18 and earlier versions, but after upgrading to iOS 26, it stopped working. Details: Entitlement Near Field Communication Tag Reader Session Formats D2760000850101 D2760000850101 Info.Plist com.apple.developer.nfc.readersession.iso7816.select-identifiers D2760000850101 com.apple.developer.nfc.readersession.felica.systemcodes 12FC Privacy - NFC Scan Usage Description Signing and Capabilities: Near Field Communicating Tag Reading [Eanbled] My Sample Code Is: class NFCManager: NSObject, NFCTagReaderSessionDelegate { private var nfcSession: NFCTagReaderSession? let isConnectionNeeded = false func startNFCSession() { guard NFCTagReaderSession.readingAvailable else { // NFC is not available on this device. return } nfcSession = NFCTagReaderSession(pollingOption: [.iso14443, .iso15693, .iso18092], delegate: self) nfcSession?.begin() } func stopNFCSession() { nfcSession?.invalidate() } // MARK: - NFCTagReaderSessionDelegate Methods func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) { print("tagReaderSessionDidBecomeActive") } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { print("didInvalidateWithError --\(error)") } func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) { print("didDetect: Tag Detected --\(tags)") } } The above code works fine on iOS 18 and earlier versions for detecting tags. Please let me know if I’m missing anything. Please help me to resolve the issue in iOS 26

I have created a sample app which read/write from a network file. When the file was attempted to open (using open Linux API), connection to network file was lost. The thread which was stuck on the open method, returns after a long time. It was observed that for macOS, the maximum return time of the thread was around 10 mins, whereas in Windows and Linux, the maximum timeout was 60 sec and 90 sec. macOS has a very large timeout before returning the thread with a network failure error. Is this by designed and expected? With a large timeout as 10mins, it's difficult to respond swiftly back to the user.

As a part of the video editing app I’m working on, I want to efficiently copy a folder of resources on the same (local) filesystem. Because iOS is on APFS, cloning (CoW) is an option. I read the documentation for clonefile(2) which states that cloning a folder works but is strongly discouraged. I did a small sample project which demonstrates that using clonefile on a folder works correctly and is 10× faster than using FileManager’s copyItem method. My questions: The main one I’m interested in: Why is using clonefile for a folder strongly discouraged? Is FileManager using cloning behind the scenes? Or more exactly how guaranteed are we it will use it? (I know it does, I tried manually cping the resources and it was thousands of times slower.)

Hello. I'm working on a sample project of a network file system using FSKit. The problem I'm currently facing is FSItems not getting reclaimed after they disappear from the file system. If an item deletion goes through the file system, I get the removeItem() and reclaimItem() callbacks. When deletion goes though a different client to the network file system I force an enumeration of the parent directory and FSKit gets the directory contents. The problem is the FSItem instances that are now missing from the contents don't get reclaimed or removed in any way and remain in memory. This gets reproduced both on macOS 15.6.1 + Xcode 16.4 and the latest beta software versions. Is there any way to work around this? Thanks

Hello world! Given some suitable byte sequences b1, b2 and a Bluetooth Low Energy device that provides two GATT characteristics c1 and c2, can I call CBPeripheral.writeValue(b1, c1) and then CBPeripheral.writeValue(b2, b2) without waiting for the callback of the corresponding CBPeripheralDelegate to occur for the first write operation to c1 and without causing one of both operations to fail due to iOS's BLE implementation? Is there any official documentation or specification that states what would or could happen in such scenario? The background of this question is that on Android, you usually can only perform one GATT operation on a single BluetoothGatt instance at a time. Consecutive operations, even for different characteristics, that do not await the callback invocations of previously requested GATT operations, usually just fail. However, experimenting with CBPeripheral, I can see that such accesses seem to be working on iOS. Now, is that undefined behavior and I am just observing a forgiving implementation or this actually specified behavior? I would be glad about any hints or comments on this matter that have foundation in the official Apple developer documentation or any official Bluetooth specification. Since I already tried my luck with search engines, I would assume that this is just undefined behavior. Thank you! Regards, Luis.

A user of my app brought to my attention that unless they select their ~/Library/Mail folder explicitly in an open panel, they get an error when scanning it inside my app. I can confirm that I also get a permission error when trying to scan it as a subfolder of ~/Library, but not if I select it directly. I'm assuming this is intentional, but it would be nice to have an explanation or some documentation that I can point my users to when they encounter what appears to them as a bug in my app. What makes this matter even more confusing is that selecting a folder in any open panel of an app gives the app access to it for the lifetime of the app, but after restarting the app, access is lost again (unless it has a bookmark to it). This was probably the reason why the user thought that it worked in another app but not in mine. This is the code I use to scan: let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true if openPanel.runModal() == .cancel { return } let enumerator = FileManager.default.enumerator(at: openPanel.urls[0], includingPropertiesForKeys: nil) { url, error in print(url.path, error) return true } while let url = enumerator?.nextObject() as? URL { } And this the error related to the Mail folder: ~/Library/Mail Error Domain=NSCocoaErrorDomain Code=257 "The file “Mail” couldn’t be opened because you don’t have permission to view it." UserInfo={NSURL=file:///~/Library/Mail, NSFilePath=/~/Library/Mail, NSUnderlyingError=0x600002991470 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

This concerns file provider framework on macOS. Some users of our application (Egnyte.app) report that they have problems downloading dataless files. When a file reaches invalid state, trying to open or download it through Finder results in "Invalid argument" alert (see example-recording.mp4). At the same time our FileProvider extension receives no fetchContents or fetchPartialContents calls. A step-by-step set of instructions to reproduce the problem (if possible) So far we don't have clear reproduction steps. The issue is easily reproducible, for multiple files, for some of our customers. See attached sysdiagnose and recording. What results you expected Our extension receives a request to download the file. File downloads and opens successfully. What results you actually saw No download request made to our File Provider extension. File doesn't open, Finder alert instead. PLEASE NOTE: Before recording and collecting sysdiagnose we installed FileProvider.mobileconfig, slightly modified official profile that we attach. Example reproduction happens 8:33 into full-recording.mp4, around 17:01:18 / 17:01:19 machine’s time. Shared sysdiagnose and recordings come from one of our customers, they permitted us to share the data. In the recording they try to open files with multiple 3rd party applications (Vectorworx, Office PowerPoint) and those opens fail with alerts from those applications. We have similar reports from customers using Adobe apps. More info in FB19462434

Hi, The app that I'm developing requires data transfer between iOS device and external device through usb-c cable connection. So I'm trying to copy and paste the file between iOS and external storage device automactically. I've tried using UIDocuementPickerController with bookmark, which gives the url path of connected external storage after user selection for the first selection, but it could not be used directly without user interaction afterwards. Is it possible to use the storage url path automatically after user selection for the first time? How do I achieve that? Thanks in advance

I have an iOS app that allows user to select a folder (from local Files). User is seemingly capable selecting the "On My iPhone" folder (the "Open" button is enabled, clickable and when it is tapped the app gets the relevant URL) although there's nothing in that folder apart from ".trash" item. Is selecting that folder not supported? If not why is the "Open" button enabled on that level to begin with?