Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums, tagging your thread with Files and Storage so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have four different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. This post is my attempt to clear that up. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it typically generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) Data container protection (macOS 14 beta and later) Data Vaults (see below) Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (“Signed to run locally” in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For all the details about data container protection, see WWDC 2023 Session 10053 What’s new in privacy. On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Preferences under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Revision History 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of data container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

General: DevForums tags: Files and Storage, Finder Sync, File Provider, Disk Arbitration, APFS File System Programming Guide On File System Permissions DevForums post File Provider framework Finder Sync framework App Extension Programming Guide > App Extension Types > Finder Sync Disk Arbitration Programming Guide Mass Storage Device Driver Programming Guide Device File Access Guide for Storage Devices Apple File System Guide TN1150 HFS Plus Volume Format Extended Attributes and Zip Archives File system changes introduced in iOS 17 DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

File system changes introduced in iOS 17 As part of iOS 17, tvOS 17, and watchOS 10, the system has reorganized where applications and their data containers are stored. In previous systems, both lived within the same volume but, starting in iOS 17, they will be stored on different volumes. What does this mean for you? Copying large amounts of data from the app bundle to a data container will take longer than in previous versions of iOS. Previously that copy would have occurred as an APFS file clone, but now the operation will occur as a standard copy, which may take much significantly longer. Because the data will need to be fully duplicated, storage usage will increase more than was the case in previous versions. You should minimize the data they copy out of their app bundle and avoid any unnecessary duplication of data between the app bundle and data container. When upgrading from previous system version, splitting the data into separate volumes may mean that there is insufficient space for all existing apps and their data. If this occurs, the app's data container will remain on the device, preserving the user's data, while the app bundle itself is removed using the same mechanism as "Offload Unused Apps". The user can then restore the app once they've freed sufficient space for the app to install. Revision History 2023-07-11 First posted

Hello, in my Mac Catalyst app, I have detail view with sections modeled as DisclosureGroups. The label view has a button, that shall trigger a file import view when pushed. The label view is defined as follows: swift HStack {         Text(LocalizedStringKey("Documents")).font(.title)         Spacer()         Button {           showFileImporter = false           // fix broken picker sheet           DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {             showFileImporter = true           }         } label: {           Image(systemName: "doc.badge.plus")             .padding(.horizontal, 10)         }         .disabled(!expanded)         .fileImporter(                       isPresented: $showFileImporter,               allowedContentTypes: [.data],           allowsMultipleSelection: false) { result in                       // add fileUrl.startAccessingSecurityScopedResource() before accessing file             NSLog("\(result)")           }       } Unfortunately the file import view is not showing, when the button is pushed, although the state changes to true. Does anybody have any hints? BTW the repo is available at https://github.com/thbonk/repti/tree/ui-refactoring The view in question is https://github.com/thbonk/repti/blob/ui-refactoring/Repti/Source/UI/Views/IndividualDetails/DocumentsSubview.swift Thanks & Best regards Thomas

My test flight application crashed while doing a disk writing operation. I saw the following error in crash log 1073.76 MB of file backed memory dirtied over 705 seconds (1522.14 KB per second average), exceeding limit of 12.43 KB per second over 86400 seconds\ After a little bit of research I found from Apple documentation that System will throw an exception if disk writes from the app exceeds a certain limit in 24 hours window [https://developer.apple.com/documentation/xcode/reducing-disk-writes) But the threshold is not documented. But looking at the crash log we can reverse calculate this threshold as 12.43KB * 86400 ~ 1 GB Does this means that iOS application won't be able to write data more than this limit (1 GB) per day?

This has come up a few times so I thought I’d write it down so that Future Quinn™ could point folks at it. If you have any questions or feedback, please start a new thread and tag it with Files and Storage so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Extended Attributes and Zip Archives In a traditional Unix file system, a file consists of a flat sequence of bytes and a very limited set of metadata. In contrast, a traditional Mac OS file had a second sequence of bytes, the resource fork, and various other bits of Mac metadata. This caused an interoperability problem between Mac and Unix systems because the latter has no place to store the Mac metadata. To resolve this problem Apple introduced the AppleDouble file format. This stores the Mac’s data fork in the Unix file and all the Mac metadata in a companion AppleDouble file. If the file name was foo, this companion file was called ._foo. The leading dot meant that this companion file was hidden by many tools. macOS does not typically need AppleDouble files because Apple file systems, like APFS and HFS Plus, have built-in support for Mac metadata. However, macOS will create and use AppleDouble files when working with a volume format that doesn’t support Mac metadata, like FAT32. Similarly macOS will create and use AppleDouble files when working with archive file formats, like zip, that don’t have native support for Mac metadata. macOS 10.4 added support for extended attributes at the Unix layer. For more on this, see the getxattr man page. As with traditional Mac metadata, this is supported natively by Apple file systems but must be stored in an AppleDouble file elsewhere. Note At the API level the original Mac metadata is modelled as two well-known extended attributes, XATTR_RESOURCEFORK_NAME and XATTR_FINDERINFO_NAME. When creating a zip archive macOS supports two approaches for storing AppleDouble files: By default it stores the AppleDouble file next to the original file. % ditto -c -k --keepParent root root-default.zip % unzip -t root-default.zip Archive: root-default.zip testing: root/ OK testing: root/nested/ OK testing: root/nested/FileWithMetadata OK testing: root/nested/._FileWithMetadata OK No errors detected in compressed data of root-default.zip. Alternatively, it can create a parallel hierarchy, rooted in __MACOSX, that holds all AppleDouble files. % ditto -c -k --keepParent --sequesterRsrc root root-sequestered.zip % unzip -t root-sequestered.zip Archive: root-sequestered.zip testing: root/ OK testing: root/nested/ OK testing: root/nested/FileWithMetadata OK testing: __MACOSX/ OK testing: __MACOSX/root/ OK testing: __MACOSX/root/nested/ OK testing: __MACOSX/root/nested/._FileWithMetadata OK No errors detected in compressed data of root-sequestered.zip. The latter is commonly used for mail attachments because it makes it easy for the recipient to discard all the Mac metadata.

Hi there, I am currently making an app and trying to download content to a user-selected download directory (like how safari does it). However, whenever I set the download directory outside the App's documents, I get the following error when running my code on a real iOS device. downloadedFileMoveFailed(error: Error Domain=NSCocoaErrorDomain Code=513 "“CFNetworkDownload_dlIcno.tmp” couldn’t be moved because you don’t have permission to access “Downloads”." UserInfo={NSSourceFilePathErrorKey=/private/var/mobile/Containers/Data/Application/A24D885A-1306-4CE4-9B15-952AF92B7E6C/tmp/CFNetworkDownload_dlIcno.tmp, NSUserStringVariant=(Move), NSDestinationFilePath=/private/var/mobile/Containers/Shared/AppGroup/E6303CBC-62A3-4206-9C84-E37041894DEC/File Provider Storage/Downloads/100MB.bin, NSFilePath=/private/var/mobile/Containers/Data/Application/A24D885A-1306-4CE4-9B15-952AF92B7E6C/tmp/CFNetworkDownload_dlIcno.tmp, NSUnderlyingError=0x281d045d0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}, source: file:///private/var/mobile/Containers/Data/Application/A24D885A-1306-4CE4-9B15-952AF92B7E6C/tmp/CFNetworkDownload_dlIcno.tmp, destination: file:///private/var/mobile/Containers/Shared/AppGroup/E6303CBC-62A3-4206-9C84-E37041894DEC/File%20Provider%20Storage/Downloads/100MB.bin) The summary of that error is that I don't have permission to access the folder I just granted access to. Here's my attached code (I'm using AlamoFire since it's easier to understand, but I'm having a problem saving files in iOS): import SwiftUI import UniformTypeIdentifiers import Alamofire struct ContentView: View { @AppStorage("downloadsDirectory") var downloadsDirectory = "" @State private var showFileImporter = false var body: some View { VStack { Button("Set downloads directory") { showFileImporter.toggle() } Button("Save to downloads directory") { Task { do { let destination: DownloadRequest.Destination = { _, response in let documentsURL = URL(string: downloadsDirectory)! let suggestedName = response.suggestedFilename ?? "unknown" let fileURL = documentsURL.appendingPathComponent(suggestedName) return (fileURL, [.removePreviousFile, .createIntermediateDirectories]) } let _ = try await AF.download(URL(string: "https://i.imgur.com/zaVQDFJ.png")!, to: destination).serializingDownloadedFileURL().value } catch { print("Downloading error!: \(error)") } } } } .fileImporter(isPresented: $showFileImporter, allowedContentTypes: [UTType.folder]) { result in switch result { case .success(let url): downloadsDirectory = url.absoluteString case .failure(let error): print("Download picker error: \(error)") } } } } To reproduce (Run on a REAL iOS device!): Click the Set downloads directory button to On my iPhone Click the Save to downloads directory button Error occurs Upon further investigation, I found that safari uses the Files and Folders privacy permission (Located in Settings > Privacy > Files and folders on an iPhone) to access folders outside the app sandbox (see the attached image for a visual representation of what I'm talking about). I scoured the web as much as I can and I couldn't find any documentation for this exact permission. I have seen non-apple apps (such as VLC) use this permission, but I cannot figure out how it's granted. I tried enabling the following plist properties, but none of them work (because I later realized these are for macOS only) <key>NSDocumentsFolderUsageDescription</key> <string>App wants to access your documents folder</string> <key>NSDownloadsFolderUsageDescription</key> <string>App wants to access your downloads folder</string> Can someone please help me figure out how to grant the files and folder permission and explain what it does? I would really appreciate the help. Image of the permission in question:

Hey, I'm not sure I'm even in the correct ballpark - trying to allow my app to download largish videos from user's OneDrive and G-Drive to app Is it correct to use NSFileCoordinator in this way? How do I report progress as it downloads the video (is it possible?) Is it correct to dismiss the picker like this? anything else wrong (or, like is....any of it correct? :) it's sort of working with my contrived examples (I created new personal G-drive / Onedrive accounts, and copied vids up there), but...when I use a file from our corporate OneDrive, from shared folder, I get: "NSCocoaErrorDomain Code=3328 "The requested operation couldn’t be completed because the feature is not supported." Is this the NSFileProvider extension (Microsoft's) complaining? public func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) {     guard  let url = urls.first else {       return     }     let isSecurityScoped = url.startAccessingSecurityScopedResource()     print("(#function) - iSecurityScoped = (isSecurityScoped)")     print("(#function) - document at (url)")     let filename = String(UUID().uuidString.suffix(6)) + "_" +  url.lastPathComponent     let newURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent(filename)          let readingIntent = NSFileAccessIntent.readingIntent(with: url, options: .withoutChanges)     fileCoordinator.coordinate(with: [readingIntent], queue: queue) { error in       defer {         if isSecurityScoped {           url.stopAccessingSecurityScopedResource()         }       }       if let error = error {         print("(#function) - (error)")         return       }       let safeURL = readingIntent.url       do {         let fileData = try Data(contentsOf: safeURL)         try fileData.write(to: newURL, options: .atomic)         print("(#function) - SUCCESS - newURL = (newURL)")       } catch {         print("(#function) - NOOOOO - (error)")       }     }     controller.dismiss(animated: true)   }

Hi, I am trying to create a hard link on MacOS(Mac Catalyst App) between files using [self linkItemAtURL:fromURL toURL:toURL error:&error]; Source Path for MacOS - /var/folders/lf/dt_4nxd945jdry2241phx0_40000gn/T/net.appname.AppName/documents/... Destination Path for MacOS - /Users/username/Library/Group Containers/group.net.appname.AppName.shared/Message/Media/... Although the same code works fine on iOS, but getting following error on MacOS Error Domain=NSCocoaErrorDomain Code=513 couldn’t be linked because you don’t have permission to access, Operation not permitted Source Path for iOS - /Users/user/Library/Developer/CoreSimulator/Devices/B4054540-345F-4D90-A3C5-DA6E6469A3FC/data/Containers/Data/Application/B4AB7D70-491C-49E5-9A3F-27E66EC3423D/tmp/documents/... Destination Path for iOS - /Users/user/Library/Developer/CoreSimulator/Devices/B4054540-345F-4D90-A3C5-DA6E6469A3FC/data/Containers/Shared/AppGroup/842B248E-CCA6-4B5C-82BD-2858EADD3A90/Message/Media/... However, interestingly if I try to copy the file, it works perfectly fine on MacOS as well. I am unable to understand if it is the permission issue, it should not work with copy as well. Does anyone have any reason/solution to this behaviour?

Hi, I have an extensive macOS test suite that accesses a lot of files located on an external volume (several Tbytes of databases, images,...). After moving to Ventura this test suite is broken. More specifically, when trying to access .sqlite databases I receive a SQL error 23: unauthorised access. This is just the symptom of the fact that I do not seem to have the access rights on those files from the test suite. I verified that by moving such a .sqlite file to /tmp, it opens fine and the corresponding test succeeds. I tried fixing those rights by giving Full Disk Access (FDA) to Xcode, to xctest...but the problem persists. Anyone out there having the same issue that found a fix ? I should add that this test suite is associated with a framework (Swift package) and I have no Xcode project associated with it...just a plain Package.swift file. So I can't really fiddle with project level settings. They surely must exist a way to access any file from a test suite even if it is located on an external disk, etc... Thanks Matthieu

NSOpenPanel.runModal is returning before the user can select a file. It seemed to get progressively worse as the OS updated. Now with macOS Ventura 13.0 it is completely unusable. Supporting docs https://stackoverflow.com/questions/70050559/nsopenpanel-nssavepanel-runmodal-dismisses-immediately-with-cancel-but-only-on https://stackoverflow.com/questions/28478020/presenting-nsopenpanel-as-sheet-synchronously

Hello, I am currently facing an issue with my iOS app and its associated Preview extension. I am trying to save a file to a shared container using App Groups, so that my main app can read the file. The code works perfectly on the iOS simulator, but when I run the app on a physical device I encounter a "You don't have permission to save the file" error. Here's the relevant code snippet: let appGroupIdentifier = "group.com.yourcompany.yourapp" func saveDataToSharedContainer(fileName: String, data: Data) -> Bool { guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroupIdentifier) else { print("Error: Unable to access the shared container.") return false } let fileURL = containerURL.appendingPathComponent(fileName) do { try data.write(to: fileURL, options: .atomic) print("Data saved to shared container successfully.") return true } catch { print("Error: Unable to save data to shared container. \(error)") return false } } I have already verified the following: App Groups capability is enabled for both the main app target and the extension target. The App Group identifier is consistent in both the main app target and the extension target, as well as in the Swift code. Provisioning profiles and signing certificates are up-to-date, and the issue persists after cleaning the project and resetting the provisioning profiles. Despite trying these steps, the issue remains unresolved. This error is reproducible in a new project with a Preview extension. I would greatly appreciate any insights or suggestions from the community to help me resolve this issue. Thank you in advance!

My app has the App Sandbox enabled and the File Access to Downloads folder is set to Read / Write in XCode. Upon clicking on a button the app should open the Finder displaying the Downloads folder. The following code snippet is used to launch the Finder if let inspirationsDirectory = FileManager.default.urls(for: .downloadsDirectory, in: .userDomainMask).first{ NSWorkspace.shared.open(inspirationsDirectory) } On my MacOS it works well. After releasing the app to the AppStore and installing it on another Mac the following message is received upon clicking the button: The application does not have permission to open "Downloads" Which would be the solution to launch the Finder successfully ? Is it possible to launch the Finder showing the Downloads folder sorted by the Date Added column descending ?

When we try to run our code that uses the containerURLForSecurityApplicationGroupIdentifier function, the returned value is null if the program was run with root privileges. (when we run the code like a normal user, it is works as expected) The following code was run: NSFileManager* fileManager = [NSFileManager defaultManager]; if(!fileManager) { return “”; } NSURL* containerURL = [fileManager containerURLForSecurityApplicationGroupIdentifier:[NSString stringWithUTF8String:group_name]]; if(!containerURL) { return “”; } -> we will receive the right containerURL: /Users/{user}/Library/Group Containers/{group_name} If the same code will be run with root/admin privileges the containerURL will be NULL. With an older version of MacOS the output result was the following: normal user: /Users/{user}/Library/Group Containers/{group_name} root user : /private/var/root/Library/Group Containers/{group_name}

We have an App Group defined in our entitlements file so that two pieces of our software, a management GUI and a VPN extension, can write files to the same location. This is not just for regular log files. There's data we want to record which isn't appropriate for the system logs. What we're seeing on the iOS and macOS betas is that the write() file always fails, and we end up with \0s written to the file instead of the data. This is true both with the shipping versions of our applications on the App Store and with builds made with Xcode 15 and run on the devices in the debugger. Happens from both the Network Extension and the management application. Both macOS and iOS. Shipping apps and freshly built with latest tools. There's nothing we see in the Console logs that would appear to explain this. I didn't see anything in the release notes that would address this, but I could easily have missed something. Anyone else seen this?

I have a question about the file system of macOS and iOS. I tried to play an audio from the local download folder. But I failed because my application seems not to have the permission to read it. I get the error Error Domain=NSOSStatusErrorDomain Code=-54 "permErr: permissions error (on file open)". So I think it's something different from other systems like Windows. How are these permissions handled and how can I get the permission to read a file? I read something about Sandboxing but my app doesn't even start when I turn on "App Sandbox" in the settings.

Hello, I need to get all files (recursively) from an iCloud Drive folder. So I use UIDocumentPickerController with UTType.folder. Then I use FileManager to get all files from the picked folder, but when I try to access it with startAccessingSecurityScopedResource it return false. It's work perfectly if I dont get files by FileManager but directly by the UIDocumentPickerController when configured for multiple files selection. How can I access to all files from a picked directory with permission granted ? Is it at least possible ? Thanks

Which one is the best between Xcode 14.3 and Xcode 15 Beta. As I have the two on my laptop and my laptop is out of storage, which make it run slowly, I don't know which one to uninstall and the one to spare. Your advice will be really appreciated.

I'm working with NSFileProviderReplicatedExtension for macOS app. I want to apply default badge on files(For example, com.apple.icon-decoration.badge.warning, com.apple.icon-decoration.badge.pinned, .. etc). I am unable to see any badge when I open the folder mounted by the Extension. I've defined NSFileProviderDecorations in NSExtension as follows : <dict> <key>NSFileProviderDecorations</key> <array> <dict> <key>BadgeImageType</key> <string>com.apple.icon-decoration.pinned</string> <key>Category</key> <string>Badge</string> <key>Identifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER).cyfile</string> <key>Label</key> <string>CydriveFile</string> </dict> </array> <key>NSExtensionFileProviderDocumentGroup</key> <string>$(TeamIdentifierPrefix)com.example.app-group</string> <key>NSExtensionFileProviderSupportsEnumeration</key> <true/> <key>NSExtensionPointIdentifier</key> <string>com.apple.fileprovider-nonui</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).FileProviderExtension</string> </dict> I have implemented the class Item that's implementing the following Protocols : NSObject, NSFileProviderItemProtocol, NSFileProviderItemDecorating and when returning decorations for that item I'm just doing this : class Item : ... { ... static let decorationPrefix = Bundle.main.bundleIdentifier! static let heartItem = NSFileProviderItemDecorationIdentifier(rawValue: "\(decorationPrefix).cyfile") var decorations: [NSFileProviderItemDecorationIdentifier]? { var decos = [NSFileProviderItemDecorationIdentifier]() decos.append(CyItem.heartItem) return decos } } As far as i can tell I've completed all the requirements for getting the badge to show up.

We have an app that uses NetFSMountURLSync and testing under Sonoma beta 4 all calls fail with EPERM (1). Is there a new entitlement required for Sonoma? Something else?

El error que me da es. File at URL: file:///private/var/mobile/Library/Mobile%20Documents/comappleCloudDocs/Downloads/am401s02.pdf is not reachable. Ensure file URL is not a directory, symbolic link, or invalid url.