I'm using UIDocumentPickerViewController to open a url. Works fine in debug mode but version on the App Store is failing. Code to create the document picker is like: NSArray *theTypes = [UTType typesWithTag:@"docxtensionhere" tagClass:UTTagClassFilenameExtension conformingToType:nil]; UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc]initForOpeningContentTypes:theTypes]; documentPicker.delegate = self;   [self presentViewController:documentPicker animated:YES completion:nil]; So in debug mode this is all gravy. -documentPicker:didPickDocumentsAtURLs: passes back a URL and I can read the file. In release mode I get a URL but my app is denied access to read the file. After inspecting some logging it appears the sandbox is not granting my app permission. error Domain=NSCocoaErrorDomain Code=257 "The file “Filename.fileextensionhere” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/comappleCloudDocs/Filename.fileextensionhere, NSUnderlyingError=0x2834c9da0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} -- If I'm doing something wrong with UIDocumentPickerViewController it is a real shame that permission is not being denied in Debug mode, as devs are more likely to catch in prior to release. Anyone know where I'm going wrong and if not have a workaround? Thanks in advance.

I am experiencing catastrophic data loss affecting years of documents after a routine iPhone-to-iPhone iCloud synchronization. Standard Apple Support has been unable to resolve this issue, and I urgently need engineering-level assistance. INCIDENT SUMMARY: Date: August 9, 2025 Action: Synced iCloud from iPhone 16 to iPhone 12 mini Result: ALL files in iCloud Drive on Mac disappeared Data lost: Multiple years of documents including critical PDF files Support Case #: 102658156364 TECHNICAL DETAILS: Mac: MacBook Pro running macOS Sonoma 14.6.1 Source: iPhone 16 Destination: iPhone 12 mini iCloud account: info@birth2death. com WHAT HAPPENED: Had fully populated iCloud Drive on Mac and iPhone 16 Signed into iCloud on iPhone 12 mini to sync data After sync completion, Mac's iCloud Drive became completely empty Desktop and Documents folders show in structure but contain no files iCloud.com shows empty folders "Recently Deleted" in iCloud.com is also empty ATTEMPTED RECOVERY: Checked ~/Library/Mobile Documents/ - only folder structure remains Verified with 'brctl dump' - shows folders but no documents Checked all trash locations - empty No Time Machine backup available Apple Support unable to recover server-side backups

I have an app which uses ubiquitous containers and files in them to share data between devices. It's a bit unusual in that it indexes files in directories the user grants access to, which may or may not exist on a second device - those files are identified by SHA-1 hash. So a second device scanning before iCloud data has fully sync'd can create duplicate references which lead to an unpleasant user experience. To solve this, I store a small binary index in the root of the ubiquitous file container of the shared data, containing all of the known hashes, and as the user proceeds through the onboarding process, a background thread is attempting to "prime" the ubiquitous container by calling FileManager.default.startDownloadingUbiquitousItemAt() for each expected folder and file in a sane order. This likely creates a situation not anticipated by the iOS/iCloud integration's design, as it means my app has a sort of precognition of files it should not yet know about. In the common case, it works, but there is a corner case where iCloud sync has just begun, and very, very little metadata is available (the common case, however, in an emulator), in which two issues come up: I/O may hang indefinitely, trying to read a file as it is arriving. This one I can work around by running the I/O in a thread created with the POSIX pthread_create and using pthread_cancel to kill it after a timeout. Attempts to call FileManager.default.startDownloadingUbiquitousItemAt() fails with an error Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it.". The permissions aspect of it is nonsense, but I can believe there's no applicable "sort of exists, sort of doesn't" error code to use and someone punted. The problem is that this same error will be thrown on any attempt to access that file for the life of the application - a restart is required to make it usable. Clearly, the error or the hallucinated permission failure is cached somewhere in the bowels of iOS's FileManager. I was hoping startAccessingSecurityScopedResource() would allow me to bypass such a cache, as it does with URL.resourceValues() returning stale file sizes and last modified times. But it does not. Is there some way to clear this state without popping up a UI with an Exit button (not exactly the desired iOS user experience)?

Hi, I'm having trouble implementing iCloud Drive in my app. I've already taken the obvious steps, including enabling iCloud Documents in Xcode and selecting a container. This container is correctly specified in my code, and in theory, everything should work. The data generated by my app should be saved to iCloud Drive in addition to local storage. The data does get stored in the Files app, but the automatic syncing to iCloud Drive doesn’t work as expected. I’ve also considered updating my .entitlements file. Since I’m at a loss, I’m reaching out for help maybe I’ve overlooked something important that's causing it not to work. If anyone has an idea, please let me know. Thanks in advance!

Apple face app is used to fore video calling and chatting and voice calling AP same a what’s app tango etc…

Hi everyone, I’m currently developing a SwiftUI app that uses SwiftData with CloudKit sharing enabled. The app works fine on my own Apple ID, and local syncing with iCloud is functioning correctly — but sharing with other Apple IDs consistently fails. Setup: SwiftUI + SwiftData using a ModelContainer with .shared configuration Sharing UI is handled via UICloudSharingController iCloud container: iCloud.com.de.SkerskiDev.FoodGuard Proper entitlements enabled (com.apple.developer.icloud-services, CloudKit, com.apple.developer.coredata.cloudkit.containers, etc.) Automatic provisioning profiles created by Xcode Error:<CKError 0x1143a2be0: "Bad Container" (5/1014); "Couldn't get container configuration from the server for container iCloud.com.de.SkerskiDev.FoodGuard"> What I’ve tried: Verified the iCloud container is correctly created and enabled in the Apple Developer portal Checked bundle identifier and container settings Rebuilt and reinstalled the app Ensured correct iCloud entitlements and signing capabilities Questions: Why does CloudKit reject the container for sharing while local syncing works fine? Are there known issues with SwiftData .shared containers and multi-user sharing? Are additional steps required (App Store Connect, privacy settings) to allow sharing with other Apple IDs? Any advice, experience, or example projects would be greatly appreciated. 🙏 Thanks! Sebastian

My app is live on App Store, There is already a iCloudContainer with my app identifier. I want to add another iCloundContainer on same app identifier. Will it effect my live app? When I am trying to edit identifiers(adding a new iCloud Container with other one already exist), It is showing "Adding or removing any capabilities will invalidate any provisioning profiles that include this App ID and they must be regenerated for future use." Please let me know if it effect my live application...

I was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://developer.apple.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

The NSMetadataUbiquitousItemDownloadingStatusKey indicates the status of a ubiquitous (iCloud Drive) file. A key value of NSMetadataUbiquitousItemDownloadingStatusDownloaded is defined as indicating there is a local version of this file available. The most current version will get downloaded as soon as possible . However this no longer occurs since iOS 18.4. A ubiquitous file may remain in the NSMetadataUbiquitousItemDownloadingStatusDownloaded state for an indefinite period. There is a workaround: call [NSFileManager startDownloadingUbiquitousItemAtURL: error:] however this shouldn't be necessary, and introduces delays over the previous behaviour. Has anyone else seen this behaviour? Is this a permanent change? FB17662379

Testing Environment: iOS 18.4.1 / macOS 15.4.1 I am working on an iOS project that aims to utilize the user's iCloud Drive documents directory to save a specific directory-based file structure. Essentially, the app would create a root directory where the user chooses in iCloud Drive, then it would populate user generated files in various levels of nested directories. I have been attempting to use NSMetadataQuery with various predicates and search scopes but haven't been able to get it to directly monitor changes to files or directories that are not in the root directory. Instead, it only monitors files or directories in the root directory, and any changes in a subdirectory are considered an update to the direct children of the root directory. Example iCloud Drive Documents (Not app's ubiquity container) User Created Root Directory (Being monitored) File A Directory A File B An insertion or deletion within Directory A would only return a notification with userInfo containing data for NSMetadataQueryUpdateChangedItemsKey relating to Directory A, and not the file or directory itself that was inserted or deleted. (Query results array also only contain the direct children.) I have tried all combinations of these search scopes and predicates with no luck: query.searchScopes = [ rootDirectoryURL, NSMetadataQueryUbiquitousDocumentsScope, NSMetadataQueryAccessibleUbiquitousExternalDocumentsScope, ] NSPredicate(value: true) NSPredicate(format: "%K LIKE '*.md'", NSMetadataItemFSNameKey) NSPredicate(format: "%K BEGINSWITH %@", NSMetadataItemPathKey, url.path(percentEncoded: false)) I do see these warnings in the console upon starting my query: [CRIT] UNREACHABLE: failed to get container URL for com.apple.CloudDocs [ERROR] couldn't fetch remote operation IDs: NSError: Cocoa 257 "The file couldn’t be opened because you don’t have permission to view it." "Error returned from daemon: Error Domain=com.apple.accounts Code=7 "(null)"" But I am not sure what to make of that, since it does act normally for finding updates in the root directory. Hopefully this isn't a limitation of the API, as the only alternative I could think of would be to have multiple queries running for each nested directory that I needed updates for.

As of 2025-05-03, when a macOS user enables iCloud Drive synchronization for Desktop &amp; Documents in US region, does iCloud filter xattrs upon upload or later when downloading back to another macOS host? Or is it the case that iCloud has no filtering of third-party xattrs? Where can I find the technical document outlining exactly what iCloud does with xattrs set on macOS host files and folders synchronized with iCloud Drive?

On my first attempt at adding iCloud to my existing app this is how far I've gotten. For reasons that I won't go into, the use case for my app does not need coordination. I have successfully made my app write a file to the Documents directory of iCloud and read back that same file without errors. In testing on a real iPhone 13 and iPhone 7 I have verified that my app can write a file to iCloud from the iPhone 7 and then read back that same file on the iPhone 13, so I know that the file truly exists in the cloud. But when I make my app on the iPhone 13 write to iCloud, my app on the iPhone 7 says the file does not exist. Exactly the same build of my app is running in both phones. This is problem #1. Problem #2 is that none of these files appear in the iCloud section of the Files app on either of these Phones, nor do they appear in the iCloud section of my Mac. All devices are signed in to my same Apple account in iCloud. Also my info.plist file in the app contains: <key>NSUbiquitousContainers</key> <dict> <dict> <key>iCloud.com.{my domain}.{my app}</key> <dict> <key>NSUbiquitousContainerIsDocumentScopePublic</key> <true/> <key>NSUbiquitousContainerSupportedFolderLevels</key> <string>Any</string> <key>NSUbiquitousContainerName</key> <string>{my app}</string> </dict> </dict> </dict> <key>UIFileSharingEnabled</key><true/> The iPhone 7 is running iOS 15.8.4 and the iPhone 13 is running iOS 18.3.2. The code that does the writing to iCloud is: NSFileManager *fman = [NSFileManager defaultManager]; NSURL *urlDrive = [fman URLForUbiquityContainerIdentifier: nil]; NSURL *urlDocs = [urlDrive URLByAppendingPathComponent:@"Documents"]; if(urlDocs.path == nil) { NSLog(@"NULL path"); return; //..big problem } if( ! [fman fileExistsAtPath: urlDocs.path] ) { //..need to create the Docs directory NSError *err00 = nil; @try { [fman createDirectoryAtURL: urlDocs withIntermediateDirectories:true attributes:nil error:&err00]; NSLog(@"created the directory"); } @catch (NSException *except) { NSLog(@"Exception creating directory %@", except); } } //..directory is now created NSLog(@"url=%@", urlDocs); NSURL *urlFile = [urlDocs URLByAppendingPathComponent:txtfname()]; NSData *fdata = [@"Hello world" dataUsingEncoding: NSUTF8StringEncoding]; NSLog(@"file url=%@", urlFile); NSLog(@"file Data=%@", fdata); NSError *errorReturn = nil; Boolean ret = [fdata writeToURL: urlFile options: NSDataWritingAtomic error: &errorReturn]; NSLog(@"returned %1d, error=%@", ret?1:0, errorReturn); And the code that does the reading is: NSFileManager *fman = [NSFileManager defaultManager]; NSURL *urlDrive = [fman URLForUbiquityContainerIdentifier: nil]; NSURL *urlDocs = [urlDrive URLByAppendingPathComponent:@"Documents"]; NSLog(@"url=%@", urlDocs); if(urlDocs.path == nil) { NSLog(@"urlDocs.path is NULL!"); return; //..big problem } if( ! [fman fileExistsAtPath: urlDocs.path] ) { //..need to create the Docs directory NSLog(@"It seems the urlDocs folder does not exist"); } NSURL *urlFile = [urlDocs URLByAppendingPathComponent:txtfname()]; if([fman fileExistsAtPath: urlFile.path]) { NSLog(@"file %@ exists", urlFile); [fman copyItemAtURL: urlFile toURL:<#(nonnull NSURL *)#> error:<#(NSError *__autoreleasing _Nullable * _Nullable)#>]; } else { NSLog(@"file %@ DOES NOT EXIST!", urlFile); }

My app uses iCloud to let users sync their files via their private iCloud Drive, which does not use CloudKit. FileManager.default.url(forUbiquityContainerIdentifier: nil)?.appending(component: "Documents") I plan to transfer my app to another developer account, but I'm afraid it will affect the access of the app to the existing files in that folder. Apple documentation doesn't mention this case. Has anyone done this before and can confirm if the app will continue to work normally after transferring? Thanks

I've recently added iCloud backup on my chat app. Conversations are backing up fine but some users are losing their chats and when I see the telemetry it show "BAD_REQUEST" error. I couldn't find any details or solution for it. Does anyone has any idea what it could be? My development scheme is already fully deployed to production.

Running macOS 15.4.1, Simulator 16.0 (1042.1), various iOS devices (iPhone 16, iPad 13" M4) I log into iCloud and enable iCloud Drive. Running the Files app, I noticed that I can click on "flat" documents (PDF, JPEG, etc) and they work. However, when I click on "package" documents (e.g. represented by a directory behind the scenes), I get a normal download progress, but then an alert "The operation could not be completed. No such file or directory". This seems to happen with all package documents, e.g. Keynote documents or Reality Composer objcap documents. It does not happen on actual devices logged into the same account. I've tried completely deleting and rebuilding the simulator instances in question, with no success.

Hi all, I’m building an iOS app where I need to determine user picked files or folders using UIDocumentPickerViewController, whether the selected item is synced or managed by a cloud storage provider such as: Google Drive iCloud Drive OneDrive Dropbox or any third-party File Provider extension My intent is to detect this and optionally warn the user that the item may be subject to syncing behavior. So far, I’ve tried a few different approaches: Extended Attributes (listxattr / getxattr) While this does not give reliable outcome. Heuristically search for keywords like 'Drive', 'GoogleDrive' etc But this is also not reliable. Question Is there any possible reliable and documented way to detect programmatically if a file/folder is cloud-synced or managed by a File Provider from within a regular iOS app (not an extension), especially for: Google Drive OneDrive Dropbox iCloud Other third-party providers? Also, is there any recommended fallback strategy for iOS versions prior to 17 where NSFileProviderManager may have limitations? Any input from Apple engineers or those who have tackled this would be hugely appreciated! Thanks in advance 🙌

I'm a first time developer for Swift, (getting on a bit!) but after programming in VB back in the late 90s I wanted to write an app for iPhone. I think I might have gone about it the wrong way, but I've got an app that works great on my iPhone or works great on my iPad. It saves the data persistently on device, but, no matter how much I try, what I read and even resorting to AI (ChatGPT & Gemini) I still can't get it to save the data on iCloud to synchronise between the two and work across the devices. I think it must be something pretty fundamental I'm doing (or more likely not doing) that is causing the issue. I'm setting up my signing and capabilities as per the available instructions but I always get a fatal error. I think it might be something to do with making fields optional, but at this point I'm second guessing myself and feeling a complete failure. Any advice or pointers would be really gratefully appreciated. I like my app and would like eventually to get it on the App Store but at this point in time I feel it should be on the failed projects heap! I've even tried a new Xcode project for iOS and asking it to use SwiftData and CloudKit - the default project should work - right? But it absolutely doesn't for me. Please send help!!

I'm working on implementing file moving with NSFileCoordinator. I'm using the slightly newer asynchronous API with the NSFileAccessIntents. My question is, how do I go about notifying the coordinator about the item move? Should I simply create a new instance in the asynchronous block? Or does it need to be the same coordinator instance? let writeQueue = OperationQueue() public func saveAndMove(data: String, to newURL: URL) { let oldURL = presentedItemURL! let sourceIntent = NSFileAccessIntent.writingIntent(with: oldURL, options: .forMoving) let destinationIntent = NSFileAccessIntent.writingIntent(with: newURL, options: .forReplacing) let coordinator = NSFileCoordinator() coordinator.coordinate(with: [sourceIntent, destinationIntent], queue: writeQueue) { error in if let error { return } do { // ERROR: Can't access NSFileCoordinator because it is not Sendable (Swift 6) coordinator.item(at: oldURL, willMoveTo: newURL) try FileManager.default.moveItem(at: oldURL, to: newURL) coordinator.item(at: oldURL, didMoveTo: newURL) } catch { print("Failed to move to \(newURL)") } } }

The problem is that the iCloud Drive directory of my app does not appear in my iCloud Drive in Finder despite the (I think) correct settings in my info.plist file (see below). In Terminal, I can see the folder and it also contains .txt files. What can I do to make the folder visible in Finder and the Files app? <key>NSUbiquitousContainers</key> <dict> <key>iCloud.vmk.NewsSwiper</key> <dict> <key>NSUbiquitousContainerIsDocumentScopePublic</key> <true/> <key>NSUbiquitousContainerName</key> <string>RSS-Filter</string> <key>NSUbiquitousContainerIdentifier</key> <string>iCloud.vmk.NewsSwiper</string> <key>NSUbiquitousContainerSupportedFolderLevels</key> <string>Any</string> </dict> </dict>

Hi all I have two mystic issues with saving and fetching data to and from iCloud. Both repro only after first launch of an app. 1. [GKLocalPlayer fetchSavedGamesWithCompletionHandler:] After first attempt I can see 0 saved games (but i know that there is at least one saved game) and there is no any error. In case if I try fetch one more time (without any additional actions) even immediately after first attempt I receive saved games correctly (not 0) 2. [GKLocalPlayer saveGameData: withName: completionHandler:] After first attempt I can see error The requested operation could not be completed because local player has not been authenticated. In case if I try save one more time (without any additional actions) even immediately after first attempt I can save data successfully without any error I found the same issue in StackOverflow, but there are no fixes...