NSCocoaErrorDomain

Regarding feedback FB20954846 for App Clip support, I got a message from Apple saying it is fixed. I can now compile, and code sign for an App Clip using the DeclaredAgeRange API. Great. Now that I can get past the compiler failure I'm running up against a new issue. When installed via TestFlight, an App Clip throws that the age range is unavailable. In the console app it looks like the App Clip is still prohibited from calling the system functionality: default PerformanceOrganizer AppClip 18:36:39.200071-0600 (501) Failed to fetch persona: got error from remote proxy: Error Domain=NSCocoaErrorDomain Code=4099 The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction. UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} error PerformanceOrganizer AppClip 18:36:39.200108-0600 (50

SharedModelContainer.txt Folks who filed their feedback report may have gotten responses from the feedback system. For people who see the same issue but haven't yet filed any feedback report, I'd like to share our investigation here to hopefully help. To give you more context, SwiftData (with DefaultStore) uses Core Data as its underlying storage mechanism. At runtime, SwiftData converts the schema to an in-memory Core Data model (NSManagedObjectModel), and uses the model to load and persist the data store. Before system 26.1, when handling an attribute of an array type, SwiftData converts the array type to Binary Data. On system 26.1, it instead converts the type to Transformable. This change leads to a difference between the in-memory model and the model used in the persisted data store, triggering a migration error with the following message: Error Domain=NSCocoaErrorDomain Code=134140 Persistent store migration failed, missing mapping model.” To work around the issue, you might consider the follo

Thanks, I'll check explicitly for the combination of NSCocoaErrorDomain and NSFileReadNoSuchFileError then. For anyone ending up in this thread, note that NSFileNoSuchFileError is not the same error as what's being reported by checkResourceIsReachableAndReturnError. The error is: Domain=NSCocoaErrorDomain Code=260 The file “write-single-file.txt” couldn’t be opened because there is no such file. UserInfo={NSURL=file:///Users/torarne/write-single-file.txt, NSFilePath=/Users/torarne/write-single-file.txt, NSUnderlyingError=0xa83590c90 {Error Domain=NSPOSIXErrorDomain Code=2 No such file or directory}}

My standard approach would be to try creating the security-scoped bookmark and see if that fails. I’m presuming that you tried that. What went wrong? Thanks Quinn! Yepp, that's the first thing I tried. It produces a console error: Scoped bookmarks can only be created for existing files or directories Type: Error | Timestamp: 2025-11-18 14:10:18.411061+01:00 | Process: tst_manual_sandboxed_file_access | Library: CoreServicesInternal | Subsystem: com.apple.FileURL | Category: scoped | TID: 0xdd7936 and the bookmarkDataWithOptions call fails with an NSError: Error Domain=NSCocoaErrorDomain Code=260 Scoped bookmarks can only be created for existing files or directories UserInfo={NSURL=file:///Users/torarne/write-single-file2.txt, NSDebugDescription=Scoped bookmarks can only be created for existing files or directories} Which led me to using [NSURL checkResourceIsReachableAndReturnError:] before saving the bookmark. And in turn this forum topic to determine if that's the right approach to handle this use-

Hello, Thank you for your detailed response to my previous question. I understand that including all classes used within the app in the ofClasses parameter is not the correct pattern. Situation Update: Following your advice, I tested by including only the root object's class in ofClasses. Class X contains nested objects Y and Z. // Including only root object and some nested objects NSKeyedUnarchiver.unarchivedObject(ofClasses: [X.self, Y.self], from: data) Problem Encountered: However, I encountered the following error: Error Domain=NSCocoaErrorDomain Code=4864 value for key 'anotherNestedObject' was of unexpected class 'Z'. Allowed classes are: { 'X', 'Y' } The error was only resolved when I included class Z in ofClasses as well. Current Implementation Verification: Class X properly implements NSSecureCoding In the init(coder:) method, it individually decodes nested objects using coder.decodeObject(ofClass: Y.self, forKey: nestedObject) and coder.decodeObject(ofClass: Z.self, forKey: anotherNestedOb

Our app is unable to write to its own sandbox container on macOS when run via “My Mac (Designed for iPad)”. This is not an issue when the app runs on iPhone or on iPad. So, the one thing to understand here is that the sandbox enforcement system operates at a low enough level of the system that I can't really fail*, at least not in a broad, systemic way. That's particularly true of apps running compatibility mode, which are designed to operate with very limited access. *Putting that in more concrete terms, if the basic app sandbox configuration is broken in some large-scale way, then the entire system tends to fall apart. That dynamic makes large-scale problems hard to... miss. Because of that, the assumption I'd start with here isn't may app can't read/write its files, but is instead either: I'm trying to access the wrong place. Something external to my app is interfering with my app’s ability to function. Expanding on that second point, it's important to remember that macOS is FAR more flexible/configurable