Applying this immediately after copying the file resolves the issue: var attributes = try FileManager.default.attributesOfItem(atPath: temporaryItemURL.path) attributes[FileAttributeKey.immutable] = false try FileManager.default.setAttributes(attributes, ofItemAtPath: temporaryItemURL.path) That said, it might be better to preserve the original attributes and only modify them right before deleting the file, as you demonstrated. This approach would also address the issue for files that were copied previously. Thank you for your help, Kevin!

The shared folder must be created by another iCloud user. You can ask someone to share an iCloud folder with you and then test again. The folder must be shared as View Only. Thank you. Giovanni

After updating to iOS 18.2, the issue I’ve been experiencing remains unresolved. To ensure the issue wasn’t related to the temporary folder permissions, I took the following steps: Created a custom temporary folder inside the app’s existing temporary folder. Used the UIDocumentPickerViewController to import a file and copied it into the newly created custom temporary folder. Unfortunately, this approach did not resolve the problem. Even after successfully copying the file into the custom folder, I am still unable to delete it. You have to understand that when I import a file using the UIDocumentPickerController, I expect the provided API to enable me to successfully copy the returned file into the app sandbox in such a way that I am then able to delete it. This operation appears to work correctly. do { let securityScoped = sourceItemURL.startAccessingSecurityScopedResource() try FileManager.default.copyItem(at: sourceItemURL, to: temporaryItemURL) print("INFO: Source item copied to temporary directory successfully") currentItemURL = temporaryItemURL if securityScoped { sourceItemURL.stopAccessingSecurityScopedResource() } } catch { print("ERROR: Could not copy source item to temporary directory: \(error)") return } Naturally, as the owner of the newly copied file, I also expect to be able to delete it without any issues. However this is not happening, because when I do this: guard let currentItemURL = currentItemURL else { return } do { try FileManager.default.removeItem(at: currentItemURL) self.currentItemURL = nil } catch { errorDeletingItem(error: error as NSError, temporaryItemURL: currentItemURL) return } This is the error I get. ERROR: “IMG_6897.png” couldn’t be removed because you don’t have permission to access it. Error code: 513 Error domain: NSCocoaErrorDomain Error userInfo: ["NSUserStringVariant": <__NSSingleObjectArrayI 0x301efc3c0>( Remove ) , "NSUnderlyingError": Error Domain=NSPOSIXErrorDomain ?> Code=1 "Operation not permitted", "NSFilePath": /private/var/mobile/Containers/Data/Application/EB178B53-1BBA-47FF-9DFD-AA4F0419940C/tmp/MyTemporaryFolder/IMG_6897.png, "NSURL": file:///private/var/mobile/Containers/Data/Application/EB178B53-1BBA-47FF-9DFD-AA4F0419940C/tmp/MyTemporaryFolder/IMG_6897.png] Please show me the correct way to copy a file (which belongs to an iCloud readonly shared folder) opened with the document picker initialized as UIDocumentPickerViewController(forOpeningContentTypes: [.movie, .image], asCopy: false), so that I can subsequently delete it. Giovanni

You’re absolutely correct that write permissions on the parent directory are required to delete a file, and your example clearly demonstrates this. I’d like to add to the discussion with another perspective on folder permissions and their impact on file operations. If the directory where I’m copying a file has permissions set to 555, it wouldn’t be possible to copy the file into it because write permissions are not allowed. Here’s an example to illustrate: mkdir test chmod 555 test touch test/file.txt When you run this, you’ll encounter the error: touch: test/file.txt: Permission denied This behavior reinforces your point about needing proper permissions on the parent directory to modify or delete files within it. Similarly, copying or creating new files also requires write access. In my case, I’m working with the temporary directory provided by FileManager.default.temporaryDirectory, which has more permissive settings 755. This avoids the issues seen with 555 permissions. I’ll definitely take a closer look at the "On File System Permissions" post that you linked. Thank you for pointing it out and for your detailed explanation!

I apologize for contradicting you, but I believe there might be a bug. When I use the same code FileManager.default.copyItem(at:to:) with iOS 16.7.10 to copy a file into the app sandbox, the app can successfully delete the copied file. After further testing, I discovered that the issue may not be related to file permissions. When importing files using UIDocumentPickerViewController (regardless of whether the asCopy flag is set to true or false), the files are assigned 600 permissions. This should be sufficient since the app is the owner of the file, granting it both read and write access, including the ability to delete the file. However, in iOS 18.1.1, an issue occurs when the app copies a file imported using UIDocumentPickerViewController with the asCopy flag set to false. When such a file is copied into the app sandbox, the app is unable to delete the file or modify its attributes. Strangely, the group and owner IDs of the file appear identical to those of files imported with the asCopy flag set to true that the app is able to delete. To provide more context, I have created a branch on the GitHub repository that logs the file attributes: https://github.com/giomurru/FileDeletePermissionBug/tree/permissions-log. This inconsistency in behavior is perplexing and suggests there may be an underlying issue beyond permissions or ownership. I believe this warrants further investigation. Have a nice day, Giovanni

I’d like to add that I tested the same code on an iPhone X running iOS 16.7.10, and the bug does not occur on that version.

This is the answer of ChatGPT.

@endecotp Yes you're absolutely right about Section 3. My mistake. However section 4, Article 30, Traceability of traders. is the one that we should look at. They are talking about the documents that Apple should request to the traders that do not qualify as micro or small enterprises. (a) the name, address, telephone number and email address of the trader; (b) a copy of the identification document of the trader or any other electronic identification as defined by Article 3 of Regulation (EU) No 910/2014 of the European Parliament and of the Council (40); (c) the payment account details of the trader; (d) where the trader is registered in a trade register or similar public register, the trade register in which the trader is registered and its registration number or equivalent means of identification in that register; (e) a self-certification by the trader committing to only offer products or services that comply with the applicable rules of Union law. The paragraph in Article 29 has no commas so I think you should read it like this: This Section shall not apply to providers of online platforms allowing consumers to conclude distance contracts with (traders that qualify as micro or small enterprises)

Hi there, I am posting here what I have found and understood of the DSA law. Be advised that I am NOT a lawyer, so please understand that this is just what I understood by reading parts of the law and is not a legal advice. Nonetheless I encourage you to discuss and criticize my findings. Article 3, Definitions. Paragraph (f). ‘trader’ means any natural person, or any legal person irrespective of whether it is privately or publicly owned, who is acting, including through any person acting in his or her name or on his or her behalf, for purposes relating to his or her trade, business, craft or profession; Article 30, Traceability of traders, Paragraph (1) Providers of online platforms allowing consumers to conclude distance contracts with traders shall ensure that traders can only use those online platforms to promote messages on or to offer products or services to consumers located in the Union if, prior to the use of their services for those purposes, they have obtained the following information, where applicable to the trader: (a) the name, address, telephone number and email address of the trader; (b) a copy of the identification document of the trader or any other electronic identification as defined by Article 3 of Regulation (EU) No 910/2014 of the European Parliament and of the Council (40); (c) the payment account details of the trader; (d) where the trader is registered in a trade register or similar public register, the trade register in which the trader is registered and its registration number or equivalent means of identification in that register; (e) a self-certification by the trader committing to only offer products or services that comply with the applicable rules of Union law. In the article 30 "Providers of online platforms" above, I think the law refers in our case to Apple Inc that provides the App Store platform to the traders, while traders refers the traders that allow consumers to conclude distance contracts. The distance contracts are defined in L 304/73 as (7) ‘distance contract’ means any contract concluded between the trader and the consumer under an organised distance sales or service-provision scheme without the simultaneous physical presence of the trader and the consumer, with the exclusive use of one or more means of distance communication up to and including the time at which the contract is concluded; The definition of distance contract is not very clear. But again I am not a lawyer. I do not understand if the word contract refers to subscriptions, in-app purchase, single-purchase, or if it just refers to contracts stipulated with the clients outside the App Store platform. Anyway, the crucial part I found is that the article 30 is contained within Section 4 that starts with the following article: Article 29 Article 29. Exclusion for micro and small enterprises. This Section shall not apply to providers of online platforms allowing consumers to conclude distance contracts with traders that qualify as micro or small enterprises as defined in Recommendation 2003/361/EC. This Section shall not apply to providers of online platforms allowing consumers to conclude distance contracts with traders that previously qualified for the status of a micro or small enterprise as defined in Recommendation 2003/361/EC during the 12 months following their loss of that status pursuant to Article 4(2) thereof, except when they are very large online platforms in accordance with Article 33. So in my understanding if you have a small business you should not provide the phone number address and other information requested in article 30, because article 30 is inside Section 4 which starts with article 29 that is exonerating micro os small enterprises from the requirements of the law. Do you think my conclusion is accurate? Please let's discuss about that.

I am facing the same problem here, but luckily I didn't install iOS 16.4 yet. I have an old mac and I can't install Mac OS Ventura. I'd like to know if it's possible to use an iPhone running iOS 16.4 as testing device with Xcode 14.2. I don't want to update and then find out that I can't use Xcode 14.2 with a device running iOS 16.4. Any suggestion?

As far as I know you can't. I read somewhere (I don't recall where) that they were going to improve appstoreconnect to include this kind of information. Hopefully soon.

Hi there, UIAlertView has been deprecated long time ago (iOS 9). You should migrate to UIAlertController. Read the docs for a usage example. https://developer.apple.com/documentation/uikit/uialertcontroller

Zuckerberg recently announced that Whatsapp will prevent screenshots on view once messages. Is there some new API am I missing? Or is it just some private API that only Facebook can access?

Just do input = fopen("/Users/joe schmoe/namedata.txt", "r"); It will work! I have tested it with the default compiler (Apple Clang) and gnu11 language dialect.

I was hoping that they would support Monterey forever. Ahahah. Guess I need to upgrade my mac. -__-'