NSCocoaErrorDomain

Hello! That definitely looks like a problem! I think that you’re encountering two separate issues: one with download cancellation and another with internal analytics. For the former issue, we’ll try to reproduce it on our side. It would be super helpful if you could file a feedback report in Feedback Assistant, making sure to attach sysdiagnose logs from the device on which asset-pack cancellation failed soon after reproducing the behavior. Plus, filing a feedback report ensures that you’ll be automatically notified when we fix the issue. We’ll let you know if we figure out a workaround before the fix is available. Thanks! The fact that version 0 of the asset pack with the ID X-XXXXXX-XXX finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError') That error message concerns the latter issue. If you installed the app from TestFlight, then the system collects data about success

My sandboxed application still has access to my Application Support folder without problem. Which Application Support folder? Consider this: let u = try! FileManager.default.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true) print(u.path) which prints this: /Users/quinn/Library/Containers/com.example.apple-samplecode.Test679409/Data/Library/Application Support So, you normally end up referencing the Application Support folder in your app’s container, and you obviously have access to that. Now imagine you have a file in your ‘real’ Application Support folder: % cat /Users/quinn/Library/Application Support/tmp.txt Hello Cruel World! This code: let u2 = URL(fileURLWithPath: /Users/quinn/Library/Application Support/tmp.txt) do { _ = try Data(contentsOf: u2) } catch { print(error) } prints this: Error Domain=NSCocoaErrorDomain Code=257 The file “tmp.txt” couldn’t be opened because you don’t have permission to view it. UserInfo={NSFilePath=/Users/quinn/Library/Ap

Adding some additional information. It seems like Family, imagent and searchpartyuseragent each do eight (8) tries to interface via XPC (CoreData: XPC: sendMessage: failed #5 up to #7 starting from #0) and then giving up and initiating a round of Diagnostic reporter after that. Example of a failure: default 23:23:45.419364+0100 Family [0x130e0eb70] activating connection: mach=true listener=false peer=false name=com.apple.contactsd.persistence error 23:23:45.419593+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence default 23:23:45.419765+0100 Family [0x130e0eb70] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] default 23:23:45.419812+0100 Family [0x130e0eb70] invalidated after a failed init error 23:23:45.419970+0100 Family Persistent store service connection invalidated: failed at lookup with error 159 - Sandbox restriction error 23:23:45.420160+0100 Family Error communicating with persistent store service proxy: Error Domain=NSCocoaErrorDomain

CoreData: error: Failed to create directory file:///Users/rick/Library/Application%20Support/Benchmarks: NSCocoaErrorDomain (513) CoreData: fault: Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.' https://github.com/vanvoorden/2024-08-26 I am running into these errors when attempting to run a benchmark on a SwiftData context from the 2024-08-26 repo. The errors seem to be harmless… the benchmark continues without crashing on those unhandled exceptions. https://github.com/vanvoorden/2024-08-02/ I seem to have no problem running against SwiftData from a different Swift Package Executable (2024-08-02). This package seems to build and run with no errors. This package also creates the expected directory under ~/Library/Application%20Support/2024-08-02. I don't yet completely understand what is happening… but there seems to be some reason why Benchmarks is failing to create that extra direct

I'm a bit stuck, I believe I'm experiencing this issue too although I'm not sure if it's exactly the same or not. I'm trying to test a migration from V2 to V3 in the simulator but the app always terminates before didMigrate with issues such as: error: Attempting to retrieve an NSManagedObjectModel version checksum while the model is still editable. This may result in an unstable verison checksum. Add model to NSPersistentStoreCoordinator and try again. error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate recoverFromError:](2313): - Attempting recovery from error: Error Domain=NSCocoaErrorDomain Code=134060 A Core Data error occurred. UserInfo={NSLocalizedFailureReason=The mirroring delegate could not initialize because it's store was removed from the coordinator.} BUG IN CLIENT OF CLOUDKIT: Registering a handler for a CKScheduler activity identifier that has already been registered (com.apple.coredata.cloudkit.activity.export.8315617A-2590-4989-A1F0-0AACDDA4713E). I'm not sure the first one is re

When you create a ModelConfiguration, the default value of the cloudKitDatabase attribute .automatic, which tells SwiftData to enable CloudKit synchronization using the primary CloudKit container from the app’s entitlements. That is why you see that SwiftData automatically picks up the CloudKit container, if you configure one in your project, and enables CloudKit integration. If you don't like the default behavior, pass .none when you create the model configuration. Assuming that you use the Xcode template code to trigger the crash, most likely, you will see the following message in your Xcode console: Unresolved error loading container Error Domain=NSCocoaErrorDomain Code=134060 A Core Data error occurred. UserInfo={NSLocalizedFailureReason=CloudKit integration requires that all attributes be optional, or have a default value set. The following attributes are marked non-optional but do not have a default value: Item: timestamp} The log makes clear that the failure is triggered because Item: timestam

The problem hasn't been fixed on Apple's end.Here's what's happening:1) App sends restoration request via StoreKit's standard APIs.2) Device log shows that iOS is unable to parse a proto col from the App Store:error13:04:12.641399 +0100itunesstoredDaemonProtocolDataProvider: Couldn't parse protocol: Error Domain=NSCocoaErrorDomain Code=38403) StoreKit acknowledges that it is unable to fulfill the request:default13:04:12.643606 +0100itunesstoredStoreKitClient: Restore completed transactions failed for client: <private> with error: Error Domain=SSErrorDomain4) End result: Restoration of In-App purchases is impossible using StoreKit's APIs. I've had this problem some years ago and Apple had fixed it on their servers. The fix lasted a while, then the problem resurfaced. I reposted my initial bug report with technical documentation and logs, easily verifyable with any device.IAP restoration remains broken for my app worldwide. Now since about a year it has not been fixed, although it is all easily v

However, if I then uncheck that box and launch my app again, it gets killed right away. I agree that this is unexpected. I repeated your test here in my office and it’s not what I saw. Specifically, I created a new test app and added this code to access Documents: do { ttprint(will get doc dir) ttlet docDir = try FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true) ttprint(will list doc dir) ttlet docContents = try FileManager.default.contentsOfDirectory(at: docDir, includingPropertiesForKeys: nil, options: []) ttprint(did list doc dir, contents: (docContents)) } catch { ttprint(error) } When I ran the app after revoking the app’s access to Documents, I saw this: will get doc dir will list doc dir Error Domain=NSCocoaErrorDomain Code=257 The file “Documents” couldn’t be opened because you don’t have permission to view it. UserInfo={NSURL=file:///Users/quinn/Documents, NSFilePath=/Users/quinn/Documents, NSUnderlyingError=0x600000cb6130 {Error Domain=

Can you be more precise about how you came to this conclusion? I tried this here in my office and it worked… well… failed… as I expected. Specifically: On macOS 13.2.1, I put a test.txt file at the root of my iCloud Drive. In Xcode 14.3, I created a new project with App Sandbox enabled. I wired up a button to this code: do { print(will read) let u = URL(fileURLWithPath: /Users/quinn/Library/Mobile Documents/com~apple~CloudDocs/test.text) let s = try String(contentsOf: u, encoding: .utf8) print(did read, contents: (s)) } catch { print(did not read, error: (error)) } I ran the app and clicked the button. The app printed: will read did not read, error: Error Domain=NSCocoaErrorDomain Code=257 The file “test.text” couldn’t be opened because you don’t have permission to view it. UserInfo={NSFilePath=/Users/quinn/Library/Mobile Documents/com~apple~CloudDocs/test.text, NSUnderlyingError=0x6000005f6910 {Error Domain=NSPOSIXErrorDomain Code=1 Operation not permitted}} The underlying error, EPERM, is exactly w

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

Ok. I tried my user directory and the user directory. Same result: ❌ Échec lors de la copie : Error Domain=NSCocoaErrorDomain Code=4 Le fichier « 2019-BMW-X2-Specs-Build-Sheet.pdf » n’existe pas. UserInfo={NSSourceFilePathErrorKey=/.nofollow/Users/2019-BMW-X2-Specs-Build-Sheet.pdf, NSUserStringVariant=( Copy ), NSDestinationFilePath=/Users/jean-philippegreaux/Library/Containers/jgreaux.gestion-de-comptes/Data/Documents/2025/7/justificatif_88.pdf, NSFilePath=/.nofollow/Users/2019-BMW-X2-Specs-Build-Sheet.pdf, NSURL=file:///.nofollow/Users/2019-BMW-X2-Specs-Build-Sheet.pdf, NSUnderlyingError=0x600001ed9410 {Error Domain=NSPOSIXErrorDomain Code=2 No such file or directory}} ❌ Échec lors de la copie : Error Domain=NSCocoaErrorDomain Code=4 Le fichier « 2019-BMW-X2-Specs-Build-Sheet.pdf » n’existe pas. UserInfo={NSSourceFilePathErrorKey=/Users/jean-philippegreaux/2019-BMW-X2-Specs-Build-Sheet.pdf, NSUserStringVariant=( Copy ), NSDestinationFilePath=/Users/jean-philippegreaux/Library/Containers/jg

I saved and compared the output of launchctl print for both the working sample global-daemon and mine. They both look benign and identical, except for the expected differences (label of the daemon, path of executable, PID and port number of the endpoint). They also both have this environment = { XPC_SERVICE_NAME => com.mycompany.itm.service } entry, which says launchd KNOWS my global daemon should publish an XPC Service by this name. I managed to make another tiny progress, by trying to connect to my global daemon from the UI app of the sample-code I'm using - the one that succeeds in communicating with the sample daemon. I duplicated the code there, and try to talk to the two daemons - each with its own label and protocol. Now, the UI client app no longer calls my connection invalidation handler immediately as I try to get to the remote object proxy and send it a message, like thus: id ro = [self.myServiceConnection remoteObjectProxyWithErrorHandler:^(NSError * _Nonnull error) { NSLog(@Error obtaining rem

There’s something wonky about the code you’re showing. You seem to be calling a function, listDir(dir:), but you’re not showing the definition of that function. Regardless, you won’t be able to achieve your goal. Swift Playgrounds runs your app is a sandbox and that sandbox prevents access to most stuff on the user’s hard disk. Consider this snippet: import Foundation let fileManager = FileManager.default let libDir = try fileManager.url(for: .libraryDirectory, in: .userDomainMask, appropriateFor: nil, create: true) print(libDir.path) It prints: /Users/quinn/Library/Containers/com.apple.PlaygroundsMac.ExecutionExtension/Data/Library which is the library directory associated with your sandbox. Now consider this: import Foundation let fileManager = FileManager.default let realLibDir = URL(fileURLWithPath: /Library/Logs/DiagnosticReports) do { let contents = try fileManager.contentsOfDirectory(at: realLibDir, includingPropertiesForKeys: nil) print(contents) } catch { print(error) } It fails with: Error Domain=NSCocoaErrorDomain

Exact same issue here.After installing macOS 10.15 Catalina Photos throws error PHPhotosErrorInvalidState in a dialog window upon upgrading laibrary. After klicking OK in the app quits.Filed a bug using the Feedback Assistant (2019-08-08).In Console i managed to get a longer description of the error It reads as follows:Failed to open/create library at: '/Users/Sven/Pictures/Bilder Library SvenMaster.photoslibrary' error: Error Domain=PHPhotosErrorDomain Code=4302 PHPhotosErrorInvalidState UserInfo={NSLocalizedDescription=PHPhotosErrorInvalidState, currentState=error, NSUnderlyingError=0x600002776910 {Error Domain=com.apple.photos.error Code=43002 (null) UserInfo={currentState=error, NSUnderlyingError=0x600002776be0 {Error Domain=NSCocoaErrorDomain Code=4097 connection to service on pid 1908 named com.apple.Photos.Migration UserInfo={NSDebugDescription=connection to service on pid 1908 named com.apple.Photos.Migration}}}}}I do not understand the error message or what it means.Completed troubleshooting

I figured out what the issue is in my case, but I also think I understand the way it works a little better. In my case, I was enumerating the files using FileManager.default.enumerator and the URLs were being returned with a / on the end. There is probably a way to get the enumerator to return file URLs without the / (I haven't looked into it yet). If I do this little trick:let filename = url.lastPathComponentlet folderURL = url.deletingLastPathComponent()let fileURL = folderURL.appendingPathComponent(filename, isDirectory: false)then the fileURL doesn't contain a / on the end and QLThumbnailGenerator doesn't report that it expected a folder.HOWEVER....I still get errors in my QLThumbnailGenerator.shared.generateRepresentations which I didn't expect. I am asking for .all representations in my request because I figured it would call back every time it got a better representation of the file. The first time it calls back I get this error: Optional(Error Domain=QLThumbnailErrorDomain Code=2 No cached thumbnail)I