What are my options if I want to iterate over loaded images (dynamic libraries) within a signal handler? I have a few solutions that might work, but without going too much into them, i'm curious if anyone has experience here, or ideas what to look into. Cheers, AC

Getting "Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file" unexpectedly while attempting to create a small log file. Here's some background. This is a Swift app I wrote for my own use six years ago. A week ago, I made a small update to the app, which has not been changed in over two years. First time using Xcode 16.4 on this app, which required some code updates of course. The code creating this file has not been changed. Now for the first time, I'm getting this permissions error on a folder with wide-open permissions. This is the code. Worked for years under previous versions of Xcode. * if let outputURL = URL(string: "file://" + logPath + "/output_" + outputFormatter.string(from:Date()) + ".txt"){ do{ try outputString.write(to: outputURL, atomically:false, encoding: .utf8) }catch let error as NSError{ print ("log write error (error) (nl) (outputString)") } }

We have been struggling to get support and answeres regarding this roadblock : Request in whitelisting of the NFC Tag Reading and Writing (NDEF) entitlement for our iOS application Our application utilizes Core NFC to enable reading and writing of NFC tags, simplifying user interactions with NFC-enabled devices and services. The NDEF entitlement is essential for our app to deliver its core functionality effectively. Build Environment: Our app is developed and built using Xcode 16.4 on Codemagic’s cloud-based CI/CD platform, which utilizes a compatible macOS version (e.g., macOS Sonoma 14.4 or later). The app targets iOS 18 and uses Core NFC APIs for NDEF tag reading and writing. so far we cant get it to read or write as ios is restricking us

We're interested in adopting App Sandbox in an app distributed outside of the Mac App Store. However, we're hitting a bit of a roadblock and it doesn't seem like either of the techniques described in that post can be used in a reasonable way. For background, this is a third-party launcher for a cross-platform Java game that, among other things, makes it easier for users to mod the game. Users generally download mods as .jar files and place them in a certain directory. In some cases, these mods contain native dynamic libraries (e.g. a .dylib) as part of their code. In general, the .dylib is extracted from the contents of the .jar to some temporary location, loaded, and then deleted once the game closes (the exact details, like the actual temporary location, depends on the mod). App Sandbox greatly interests us in this case because it can limit the damage that a compromised mod could do, and in my testing the functionality of most mods still works with it enabled. However, sandboxed apps quarantine every file they write to by default. Unfortunately, most mods are created by individual developers who don't notarize their libraries (their mods are generally cross-platform, and they're likely just using third-party code that they bundle with the mod but don't sign or notarize). [1] This means that a mod that loads a dynamic library as described above triggers Gatekeeper as described in the documentation if the app is sandboxed, but does not if the sandbox is disabled. Even worse, a user often can't bypass the warning even if they trust the mod because the extracted library is usually a temporary file, and generally is deleted after the failure (which usually causes the game to crash and thus close). By the time they try to approve the code in System Settings, the file is gone (and even if they could approve it, this approval wouldn't stick next time they launch the game). In theory it would work to use an unsandboxed XPC service to remove the quarantine and let the libraries through. However, this is easier said than done. We don't control the mods' code or how they go about loading whatever code they need, which limits what we can do. [1] And in some cases, people like to play old versions of the game with old mods, and the versions they're using might've been released before notarization was even a thing. The closest thing I can think of to a solution is injecting code into the Java process that runs code to call out to the XPC service to remove the quarantine before a library loads (e.g. before any calls to dlopen using dyld interposition). A prototype I have... works... but this seems really flimsy, I've read that interposition isn't meant to be used in non-dev tools, and if there's a better solution I'd certainly prefer that over this. Other things we've tried have significant downsides: com.apple.security.files.user-selected.executable requires user selection in a file picker, and seems to be more blunt than just allowing libraries/plugins which might lead to a sandbox escape [2] Adding the app to the "Developer Tools" section in System Settings > Privacy & Security allows the libraries to load automatically, but requires users to add the app manually and also sounds like it would make a sandbox escape very easy [2] Oh, and I also submitted an enhancement request for an entitlement/similar that would allow these libraries to load (FB13795828) but it was returned as "no plans to address" (which honestly wasn't that surprising). [2] My understanding is that if a sandboxed process loads libraries, the library code would still be confined by the sandbox because it's still running in the sandboxed process. But if a sandboxed process can write and open a non-quarantined app, that app would not be within the confines of the sandbox. So basically we want to somehow allow the libraries to load but not allow standalone executables to run outside the sandbox. In general the game and almost all popular mods I've tested work with App Sandbox enabled, except for this Gatekeeper snag. It would be a shame to completely abandon App Sandbox for this reason if everything else can be made to work. This situation seems not super common, but documentation does say When your sandboxed app launches for the first time, macOS creates a sandbox container on the file system (in ~/Library/Containers) and associates it with your app. Your app has full read and write access to its sandbox container, and can run programs located there as well. which leaves me wondering whether the Gatekeeper prompt is even intended behavior since the libraries are in the sandbox container and written by the app. (By the way, my testing of the claim that apps can run programs in their sandbox container didn't seem to confirm what the documentation said, even without quarantine - FB15963761). Though, given the other documentation page I linked above which more directly references Gatekeeper and quarantined plug-ins, I doubt this is a bug. I suppose the final question is, is this just a situation where App Sandbox won't work (at least in any supported way)? Or is there perhaps some technique we're missing?

is it possible for the IOS 26 to make the chat bubbles different colors than blue? kinda tired of the same blue color. is it possible to get that version for the new update?

Hi there, I am in the process of writing a macOS app using NSFileProviderExtension so that I can map my customer's data in Finder. I am in the process of building it out. But one thing I notice is that once the file is downloaded and I save it to the cache folder, I see it disappear from the folder. It looks like the system removed the downloaded file a few seconds later. How do I go about tracking this? I have added the log stream messages from the point where it is downloaded to the point where it is gone missing. Any pointers greatly appreciated. 2025-07-15 16:10:41.989915-0700 0x138326 Default 0x0 989 0 filecoordinationd: (Foundation) [com.apple.foundation.filecoordination:provider] Provider radwar.Drive.DriveFileProviderExtension finished providing for 44FB3A4A-CA50-4EE2-9DC8-1C96FE584DF5 2025-07-15 16:10:41.989974-0700 0x138326 Default 0x0 989 0 filecoordinationd: (Foundation) [com.apple.foundation.filecoordination:claims] Provider radwar.Drive.DriveFileProviderExtension finished, unblocking claimer for 44FB3A4A-CA50-4EE2-9DC8-1C96FE584DF5 2025-07-15 16:10:41.987613-0700 0x138bb6 Default 0x0 990 0 fileproviderd: (Foundation) [com.apple.foundation.filecoordination:provider] radwar.Drive.DriveFileProviderExtension finished providing 2025-07-15 16:10:42.034144-0700 0x138905 Default 0x71f4b8 624 7 runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Invalidating assertion 624-44341-46806 (target:[xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:5AABEA5E-ACAD-428B-A6DD-F2EFF14CEE99]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44341]) from originator [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:5AABEA5E-ACAD-428B-A6DD-F2EFF14CEE99]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44341] 2025-07-15 16:10:44.185866-0700 0x138906 Default 0x0 624 7 runningboardd: (RunningBoard) [com.apple.runningboard:ttl] [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] termination reported by launchd (0, 0, 0) 2025-07-15 16:10:44.186166-0700 0x138906 Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] Removing process: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:44.186424-0700 0x138906 Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] Removing assertions for terminated process: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:44.189939-0700 0x138c30 Default 0x71f4e4 976 0 gamepolicyd: (RunningBoardServices) [com.apple.runningboard:monitor] Received state update for 44328 (xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}, none-NotVisible 2025-07-15 16:10:44.190503-0700 0x138c8f Default 0x0 624 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] XPC connection invalidated: [xpcservice<radwar.Drive.DriveFileProviderExtension([osservice<com.apple.FileProvider(501)>:990])(501)>{vt hash: 247410607}[uuid:B08DACEF-EDCC-4DE9-91AA-DC26EDB2FA89]{persona:9EF54117-4998-4D72-83C4-F12587C95FBA}:44328] 2025-07-15 16:10:46.294619-0700 0x13904a Default 0x0 44341 0 DriveFileProviderExtension: 🔥FileProviderExtension: 🔥FileProviderExtension: ❌ CRITICAL: File disappeared after 5 seconds! /Users/radwar/Library/Containers/radwar.Drive.DriveFileProviderExtension/Data/Library/Caches/FileCache/README.md (item: 19105790787)```

I have a simple impossible task, to restore /var/root/Library/Application Support/multipassd/qemu/vault/instances/gcc-cobol/ubuntu-22.04-server-cloudimg-arm64.img as of 8:02 Saturday morning. Because /var/root is owned by, well, root, the usual techniques don't work. This is a VM image hosted by qemu via Canonical's Multipass. ISTM the strategy would be to first mount the NAS filesystem and then use tmutil(8) to list the backups and recover the file. But $ sudo mount -v -o rdonly -t smb //nasa.local/TimeMachine /usr/local/mnt/ mount: exec /Library/Filesystems/smb.fs/Contents/Resources/mount_smb for /usr/local/mnt: No such file or directory mount: /usr/local/mnt failed with 72 Must I defeat SIP to do this?

I've faced with some performance issues developing my readonly filesystem using fskit. For below screenshot: enumerateDirectory returns two hardcoded items, compiled with release config 3000 readdirsync are done from nodejs. macos 15.5 (24F74) I see that getdirentries syscall takes avg 121us. Because all other variables are minimised, it seems like it's fskit<->kernel overhead. This itself seems like a big number. I need to compare it with fuse though to be sure. But what fuse has and fskit seams don't (I checked every page in fskit docs) is kernel caching. Fuse supports: caching lookups (entry_timeout) negative lookups (entry_timeout) attributes (attr_timeout) readdir (via opendir cache_readdir and keep_cache) read and write ops but thats another topic. And afaik it works for both readonly and read-write file systems, because kernel can assume (if client is providing this) that cache is valid until kernel do write operations on corresponding inodes (create, setattr, write, etc). Questions are: is 100+us reasonable overhead for fskit? is there any way to do caching by kernel. If not currently, any plans to implement? Also, additional performance optimisation could be done by providing lower level api when we can operate with raw inodes (Uint64), this will eliminate overhead from storing, removing and retrieving FSItems in hashmap.

During EEPROM reading or writing on some appliance devices, the app encounters an error after 6 steps. This issue occurs only on iPhone 14 Pro Max, 15 Pro Max, and 16 Pro models, while all other iPhone models function correctly. Any one with this problem?

Background: We are developing a cross-platform mobile application that communicates with a custom NFC-enabled hardware device. The hardware expects ISO7816-style APDU commands for data exchange and functions correctly with Android using the IsoDep protocol. Observed Issue on iOS: On iOS, the tag is only detectable via NFCNdefReaderSession, which provides access to INFCNdefTag. Attempting to use NFCTagReaderSession with NFCPollingOption.Iso14443 (which is required for APDU communication) results in no tag detection. As a result, the tag is inaccessible for APDU-based communication on iOS. Since NFCNdefReaderSession does not support APDU, we are unable to establish the required command channel. Constraints: The hardware firmware cannot be changed to support NDEF-based command interpretation. The device expects raw ISO-DEP APDU commands (i.e., Class-Instruction-Param1-Param2-Data-Le). Impact: The lack of ISO7816 tag detection on iOS prevents the app from sending APDU commands, resulting in a platform-specific feature limitation. Functionality that relies on secure, structured APDU communication is unavailable to iOS users, even though it works seamlessly on Android.

I recently upgraded a line of code in my Endpoint-Security client, to remove a deprecation warning: for (NSString *mutePath in ignoredBinaryPaths) { //(old) res = es_mute_path_literal(self.esClient, [mutePath UTF8String]); res = es_mute_path(self.esClient, [mutePath UTF8String], ES_MUTE_PATH_TYPE_TARGET_LITERAL); if (res!=ES_RETURN_SUCCESS) os_log_error(setupLog, "Failed to white-list binary:%{public}@ error:%{errno}d", mutePath, errno); } However, after this change, I started receiving tons of ES event messages, for AUTH_OPEN and AUTH_CREATE and many others, from processes/executables I explicitly and successfully muted! Since ES is so performance sensitive - I got worried. Inspecting better the new API I found incoherent documentation and even misleading and contradicting definitions. But the ES headers say differently!!! /** * @brief Suppress all events matching a path. * * @param client The es_client_t for which the path will be muted. * @param path The path to mute. * @param type Describes the type of the `path` parameter. * * @return es_return_t A value indicating whether or not the path was successfully muted. * * @note Path-based muting applies to the real and potentially firmlinked path * of a file as seen by VFS, and as available from fcntl(2) F_GETPATH. * No special provisions are made for files with multiple ("hard") links, * or for symbolic links. * In particular, when using inverted target path muting to monitor a * particular path for writing, you will need to check if the file(s) of * interest are also reachable via additional hard links outside of the * paths you are observing. * * @see es_mute_path_events * @discussion When using the path types ES_MUTE_PATH_TYPE_TARGET_PREFIX and ES_MUTE_PATH_TYPE_TARGET_LITERAL Not all events are * supported. Furthermore the interpretation of target path is contextual. For events with more than one target path (such as * exchangedata) the behavior depends on the mute inversion state Under normal muting the event is suppressed only if ALL paths * are muted When target path muting is inverted the event is selected if ANY target path is muted For example a rename will be * suppressed if and only if both the source path and destination path are muted. Supported events are listed below. For each * event the target path is defined as: * * EXEC: The file being executed * OPEN: The file being opened * MMAP: The file being memory mapped * RENAME: Both the source and destination path. * SIGNAL: The path of the process being signalled * UNLINK: The file being unlinked * CLOSE: The file being closed * CREATE: The path to the file that will be created or replaced * GET_TASK: The path of the process for which the task port is being retrieved * LINK: Both the source and destination path * SETATTRLIST: The file for which the attributes are being set * SETEXTATTR: The file for which the extended attributes are being set * SETFLAGS: The file for which flags are being set * SETMODE: The file for which the mode is being set * SETOWNER: The file for which the owner is being set * WRITE: The file being written to * READLINK: The symbolic link being resolved * TRUNCATE: The file being truncated * CHDIR: The new working directory * GETATTRLIST: The file for which the attribute list is being retrieved * STAT: The file for which the stat is being retrieved * ACCESS: The file for which access is being tested * CHROOT: The file which will become the new root * UTIMES: The file for which times are being set * CLONE: Both the source file and target path * FCNTL: The file under file control * GETEXTATTR The file for which extended attributes are being retrieved * LISTEXTATTR The file for which extended attributes are being listed * READDIR The directory for whose contents will be read * DELETEEXTATTR The file for which extended attribues will be deleted * DUP: The file being duplicated * UIPC_BIND: The path to the unix socket that will be created * UIPC_CONNECT: The file that the unix socket being connected is bound to * EXCHANGEDATA: The path of both file1 and file2 * SETACL: The file for which ACLs are being set * PROC_CHECK: The path of the process against which access is being checked * SEARCHFS: The path of the volume which will be searched * PROC_SUSPEND_RESUME: The path of the process being suspended or resumed * GET_TASK_NAME: The path of the process for which the task name port will be retrieved * TRACE: The path of the process that will be attached to * REMOTE_THREAD_CREATE: The path of the process in which the new thread is created * GET_TASK_READ: The path of the process for which the task read port will be retrieved * GET_TASK_INSPECT: The path of the process for which the task inspect port will be retrieved * COPYFILE: The path to the source file and the path to either the new file to be created or the existing file to be overwritten */ So the behavior completely changed, you can no longer specify executables (via their binary path) from which you do NOT want any events Muting effectively became reactive, not proactive. Why this change is not documented with the deprecation? Why no alternative is suggested? why find this only because it broke my software tool behavior and performance? And last: For how long can I rely on the old, deprecated APIs, should I choose to revert my change instead of devising a whole new mechanism for muting un-interesting

Hello! I am running into a crash at AbstractCombineLatest.request(_:) (), BUG IN CLIENT OF LIBMALLOC: memory corruption of free block. The crash is Crashed: com.apple.NSURLSession-delegate EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000, or Crashed: com.apple.NSURLSession-delegate EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x446d4644951e0518 This has only been reported in production, for a small percentage of users. It has been present in our application for a while, but has become much more prevalent in the past few weeks, coinciding with the iOS 18.5 release. The crash occurs when sending a value fetched from a network to a CurrentValueSubject, which is done on a Timer. A skeleton of the timer creation function: private func newTimer(for url: URL) { timerCancellable?.cancel() timerCancellable = Timer .publish(every: interval, on: .current, in: .common) .autoconnect() .flatMap({ [weak self] _ -> AnyPublisher<Response?, Never> in guard let self = self else { return Just(nil).eraseToAnyPublisher() } return self.fetch(from: url) }) .sink(receiveValue: { response in self.subject.send(response) // Crash occurs here }) } and the network request: private func fetch(from url: URL) -> AnyPublisher<Response?, Never> { return session .dataTaskPublisher(for: url) .map { (data, response) in let response = try? JSONDecoder().decode(Response.self, from: data) return response } .replaceError(with: nil) .eraseToAnyPublisher() } Timer creation itself is triggered by a separate publisher: otherPublisher .map({ item in guard let url = item?.url else { self.timerCancellable?.cancel() return nil } self.newTimer(for: url) return url }) ... Our crash reporting system has indicated the majority of these occur in the background, so I am curious if something could have changed in iOS 18.5 with background execution? Our app is registered with the audio background mode.

Hi there, I have discovered that the behavior of file copying has changed starting from iOS 18.4. When using FileManager.copyItem(atPath:toPath:) to copy a directory specified as an argument, whether or not there is a trailing slash ('/') affects whether the copy process works correctly. The same process operates as expected in the iOS 18.3.1 Simulator. Is this the correct behavior, or could it be a bug? The application's build environment is Xcode 16.2. Below is an example of the code. In practice, the file copying is performed within the application's folder. // Both iOS 18.3.1 and iOS 18.4 successfully complete the copy process. FileManager.default.copyItem(atPath: "/path/from/dirA", toPath: "/path/to/dirB") FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB/") // iOS 18.3.1 successfully complete the copy process, but iOS 18.4 fails. FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB") I hope this helps Apple engineers and other developers experiencing the same issue. Feedback or additional insights would be appreciated.

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 am trying to disable certain paths from Endpoint Security Events using es_mute_path, but this seems to be returning with ES_RETURN_ERROR. I am currently not having 'com.apple.developer.endpoint-security.client' but is disabling SIP to check the same. What is the reason for this behavior ?

I stumbled across the "Apple NFC &amp; SE Platform" while searching for the cause to a persistent missing entitlement error. I am curious if not having this entitlement could be the root cause to my issues? Specifically, I am trying to perform an HMAC-SHA1 challenge-response via NFC on a YubiKey. Part of this entails low level APDU Send commands via NFC. The missing entitlement occurs right after the APDU Send. Per my separate post, I believe I have exhausted all other possible causes to no avail. For reference and details, this is the other post: [https://developer.apple.com/forums/thread/791995)

Hi everyone! I've considered this — what if Apple added a native system-wide feature in all of iOS, iPadOS, and macOS called “CrossRun” where you can natively execute non-App Store software like Windows or Linux apps natively on your device? But not in a sluggish emulator—this would use intelligent Apple-signed Just-In-Time (JIT) compilation inside the virtual containers, and the experience would actually perform fast and feel natural. This is my vision for CrossRun: Every developer, student, creative professional, and enterprise user who relies on specialized software—whether it’s legacy Windows tools, Linux-only applications, or vintage DOS and Classic Mac utilities—feels the pain of platform lock‑in. Artists can’t run niche Linux‑based graphics programs on their iPads. Engineers can’t test x64‑only binaries on Apple Silicon without juggling emulators. Retro‑gaming fans miss their favorite DOS titles. Even enterprises struggle to standardize on Apple hardware because critical Windows‑only applications won’t run seamlessly. If we don’t push for CrossRun now, the Apple ecosystem remains siloed: iPads and iPhones will continue limited to App Store apps, Macs will still need multiple third‑party VM tools, and countless workflows stay fragmented across devices. That means slower development cycles, extra licensing costs for virtualization software, and lost opportunities for education, creativity, and business efficiency. Without CrossRun’s universal runtime, we’ll still be rebooting into different environments or paying for separate virtualization apps—year after year. Apple already provides the building blocks: Rosetta 2, Virtualization.framework, Apple Silicon—and QEMU thrives as open‑source, battle‑tested code. With the next wave of Apple Silicon devices on the horizon, demand for cross‑architecture support, legacy‑app compatibility, and enterprise containerization is only growing. Delaying another year will cost developers, businesses, and users real time and money. Let’s show Apple that the community is ready for a truly universal, system‑integrated solution—right now. Key features we should demand in CrossRun: Built‑in Apple‑signed QEMU for all ISAs (x86, ARM, RISC‑V, PowerPC, 68k, MIPS, etc.) Rosetta 2 JIT for seamless macOS and Windows x64 support Metal‑backed 3D GPU passthrough and Vulkan→Metal / Direct3D→Metal translation Downloadable OS and app containers via the App Store or verified repositories (Ubuntu, Windows ARM/x64, Android, Haiku, ReactOS, FreeBSD, retro OSes) Predictive ML pre‑warm cache to speed cold starts Dynamic resource scaling (CPU, GPU, RAM) per container iCloud‑synced snapshots and shareable VM links for cross‑device continuity Customizable on‑screen controls (D‑pad, virtual buttons, trackpad, keyboard) on iPhone, iPad, and macOS Secure sandboxing via Virtualization.framework with VM disk encryption and MDM policy enforcement Virtual LAN and VPN passthrough for container networking Developer tooling (crossrunctl CLI, Xcode debugger integration, CI/CD support) Plugin ecosystem and container SDK for community‑published templates and translation layers Let Apple know it’s time to bake CrossRun into the system and unlock a universal runtime for every app, past and future, across iOS, iPadOS, and macOS.

I have this very simple PersistenceController setup. It's used in both the main app and widget target. struct PersistenceController { static let shared = PersistenceController() @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) let viewContext = result.container.viewContext return result }() let container: NSPersistentContainer /// The main context. var context: NSManagedObjectContext { return container.viewContext } init(inMemory: Bool = false) { container = NSPersistentContainer(name: "Gamery") if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: "/dev/null") } else { do { let storeURL = try URL.storeURL(forAppGroup: "XXXXXXXXXX", databaseName: "Gamery") let storeDescription = NSPersistentStoreDescription(url: storeURL) /// Enable history tracking for cloud syncing purposes. storeDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) print("### Persistent container location: \(storeURL)") container.persistentStoreDescriptions = [storeDescription] } catch { print("Failed to retrieve store URL for app group: \(error)") } } container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { Crashlytics.crashlytics().record(error: error) fatalError("Unresolved error \(error), \(error.userInfo)") } }) container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergePolicy.mergeByPropertyObjectTrump #if !WIDGET if !inMemory { do { try container.viewContext.setQueryGenerationFrom(.current) } catch { fatalError("###\(#function): Failed to pin viewContext to the current generation: \(error)") } } PersistentHistoryToken.loadToken() #endif } } I regularly receive crash logs from the widget. I never experienced crashes myself and the widgets work fine. GameryWidgetExtension/PersistenceController.swift:35: Fatal error: Unresolved error Error Domain=NSCocoaErrorDomain Code=256 "The file “Gamery.sqlite” couldn’t be opened." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/B6A63FE1-ADDC-4A4C-A065-163507E991C6/Gamery.sqlite, NSSQLiteErrorDomain=23}, ["NSSQLiteErrorDomain": 23, "NSFilePath": /private/var/mobile/Containers/Shared/AppGroup/B6A63FE1-ADDC-4A4C-A065-163507E991C6/Gamery.sqlite] I have absolutely no idea what's going on here. Anyone who can help with this?

A user of my app reported that when trying to remove a file it always fails with the error "file couldn't be removed because you don't have permission to access it (Cocoa Error Domain 513)". After some testing, we found out that it's caused by trying to delete non-empty directories. I'm using FileManager.removeItem(atPath:) which has worked fine for many years, but it seems that with their particular NAS, it doesn't work. I could work around this by checking if the file is a directory, and if it is, enumerating the directory and remove each contained file before removing the directory itself. But shouldn't this already be taken care of? In the source code of FileManager I see that for Darwin platforms it calls removefile(pathPtr, state, removefile_flags_t(REMOVEFILE_RECURSIVE)) so it seems that it should already work. Is the REMOVEFILE_RECURSIVE flag perhaps ignored by the device? But then, is the misleading "you don't have permission to access the file" error thrown by the device or by macOS? For the FileManager source code, see https://github.com/swiftlang/swift-foundation/blob/1d5d70997410fc8b7700c8648b10d6fc28194202/Sources/FoundationEssentials/FileManager/FileOperations.swift#L444

The root issues is a missing entitlement error. I've jumped through countless hoops of checking/rechecking .entitlement file/plist file, creating new credentials, creating new projects, creating new provisioning profiles with no luck, manual signing, automatic signing. Any suggestions appreciated. Looking at the Provisioning Profile Info shows NFC Tag capabilities is included and NFC Entitlements are included. I'm at a loss... I am including the following: Pertinent output from console Current Info.Plist Current .entitlement file Here are the pertinent sectsis the Console Log for reference: ... NFCConnectionManager[0x074d6e40].tagReaderSessionDidBecomeActive(:): NFCTagReaderSessionDelegate: Session did become active NFCConnectionManager[0x074d6e40].tagReaderSession(:didDetect:): NFCTagReaderSessionDelegate: Session didDetectTags – 1 tags NFCConnectionManager[0x074d6e40].connected(session:tag:): Manager.connected(session:tag:) - tag: 7 bytes NFCConnection.Type.connection(): NFCConnection.connection() – connection established DEBUG: Successfully established YubiKit NFCConnection. DEBUG: UI updated: 'YubiKey connected... Performing challenge-response...' DEBUG: Sending APDU to select OATH applet: 00a4040008a000000527210101 NFCConnection[0x04575e00].send(data:): NFCConnection.send(data:) – 13 bytes NFCConnectionManager[0x074d6e40].transmit(request:for:): Manager.transmit – 13 bytes to tag ISO7816Identifier(data: 7 bytes) Here is the dreaded error: -[NFCTagReaderSession transceive:tagUpdate:error:]:897 Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} ERROR: Operation failed: Missing required entitlement DEBUG: Unexpected error: Missing required entitlement Here is the info.plist Here is the entitlements file: