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. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. 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) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems 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 more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Fight! 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 Settings 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 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 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 app 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

This is with SDL2 and C++ Due to the new security design of Sequoia involving the sandboxed helper processes (via ViewBridge) to show open/save panels, my existing code for invoking Open/SaveAs/FolderSelect dialogs no longer works and instead terminates with ViewBridge Code=14 "(null)" error. Even in the simplest of forms such as; nfdresult_t NFD_OpenDialogN_With_Impl(nfdversion_t version, nfdnchar_t** outPath, const nfdopendialognargs_t* args) { nfdresult_t result = NFD_CANCEL; NSOpenPanel* dialog = [NSOpenPanel openPanel]; if ([dialog runModal] == NSModalResponseOK) { result = NFD_OKAY; } return result; } ...Will no longer work. My Question is essentially, how can I resolve this NSUserDefaults domain empty/nil issue ( currently I don't pass anything for sharing defaults during the process ). Dump of fault provided in crash.txt ( the program doesn't actually crash, it just doesn't invoke the file-open dialog ) crash.txt

A filesystem of my own making exibits the following undesirable behaviour. ClientA % echo line1 >>echo.txt % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n 6c 69 6e 65 31 0a 0000006 ClientB % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n 6c 69 6e 65 31 0a 0000006 % echo line2 >>echo.txt % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n l i n e 2 \n 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 000000c ClientA % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n l i n e 2 \n 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 000000c % echo line3 >>echo.txt ClientB % echo line4 >>echo.txt ClientA % echo line5 >>echo.txt ClientB % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n l i n e 2 \n l i n e 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 6c 69 6e 65 0000010 3 \n l i n e 4 \n \0 \0 \0 \0 \0 \0 33 0a 6c 69 6e 65 34 0a 00 00 00 00 00 00 000001e ClientA % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n l i n e 2 \n l i n e 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 6c 69 6e 65 0000010 3 \n \0 \0 \0 \0 \0 \0 l i n e 5 \n 33 0a 00 00 00 00 00 00 6c 69 6e 65 35 0a 000001e ClientB % od -Ax -ctx1 echo.txt 0000000 l i n e 1 \n l i n e 2 \n l i n e 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 6c 69 6e 65 0000010 3 \n \0 \0 \0 \0 \0 \0 l i n e 5 \n 33 0a 00 00 00 00 00 00 6c 69 6e 65 35 0a 000001e The first write on clientA is done via the following call chain: vnop_write()->vnop_close()->cluster_push_err()->vnop_blockmap()->vnop_strategy() The first write on clientB first does a read, which is expected: vnop_write()->cluster_write()->vnop_blockmap()->vnop_strategy()->myfs_read() Followed by a write: vnop_write()->vnop_close()->cluster_push_err()->vnop_blockmap()->vnop_strategy() The final write on clientA calls cluster_write(), which doesn't do that initial read before doing a write. I believe it is this write that introduces the hole. What I don't understand is why this happens and how this may be prevented. Any pointers on how to combat this would be much appreciated.

When creating a folder in the code, it prompts that the file creation is successful, but when the folder does not exist in the "Download Container" file, do you have any permissions when creating the folder in VisionOS? static func getFileManager() -> URL { let documentsDirectory = FileManager.default.urls( for: .documentDirectory, in: .userDomainMask ).first! return documentsDirectory.appendingPathComponent("SGKJ_LIBRARY") } static func createFileLibrary() { let folderUrl = getFileManager() let fileManager = FileManager.default do { try fileManager.createDirectory( at: folderUrl, withIntermediateDirectories: true, attributes: nil ) print("Folder created successfully: \(folderUrl.path)") } catch { print("Failed to create folder: \(error.localizedDescription)") } }

I folks, I have an application that is already available in production and I would like to store some logs to the app, so that on real device I will see outputs for better tracing. iOS13 would be fine, but I can migrate it into e.g. iOS 14. The next question is where to find logs on real devices, so that users can send me for tracing. Thanks Petr

I'm developing a TTS Audio Unit Extension that needs to write trace/log files to a shared App Group container. While the main app can successfully create and write files to the container, the extension gets sandbox denied errors despite having proper App Group entitlements configured. Setup: Main App (Flutter) and TTS Audio Unit Extension share the same App Group App Group is properly configured in developer portal and entitlements Main app successfully creates and uses files in the container Container structure shows existing directories (config/, dictionary/) with populated files Both targets have App Group capability enabled and entitlements set Current behavior: Extension can access/read the App Group container Extension can see existing directories and files All write attempts are blocked with "sandbox deny(1) file-write-create" errors Code example: const char* createSharedGroupPathWithComponent(const char* groupId, const char* component) { NSString* groupIdStr = [NSString stringWithUTF8String:groupId]; NSString* componentStr = [NSString stringWithUTF8String:component]; NSURL* url = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:groupIdStr]; NSURL* fullPath = [url URLByAppendingPathComponent:componentStr]; NSError *error = nil; if (![[NSFileManager defaultManager] createDirectoryAtPath:fullPath.path withIntermediateDirectories:YES attributes:nil error:&error]) { NSLog(@"Unable to create directory %@", error.localizedDescription); } return [[fullPath path] UTF8String]; } Error output: Sandbox: simaromur-extension(996) deny(1) file-write-create /private/var/mobile/Containers/Shared/AppGroup/36CAFE9C-BD82-43DD-A962-2B4424E60043/trace Key questions: Are there additional entitlements required for TTS Audio Unit Extensions to write to App Group containers? Is this a known limitation of TTS Audio Unit Extensions? What is the recommended way to handle logging/tracing in TTS Audio Unit Extensions? If writing to App Group containers is not supported, what alternatives are available? Current entitlements: <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.<company>.<appname></string> </array> </dict>

I'm trying to construct a URL that, when tapped, would launch Files app and open the Downloads folder on the iPhone (not in iCloud Drive). I know the URL scheme is shareddocuments but I can't figure out the path. I have tried a few things including writing a simple iOS app and using Scriptable app. But I always get a sandboxed path such as /private/var/mobile/Containers/Data/Application/87CC2F48-AF1C-4C80-8D75-B6CC1FC642E3/Downloads/. But that wouldn't work across devices. Does anyone happen to know the path or a method to obtain the non-sandboxed path? Thanks. PS I already figured out the Downloads folder in iCloud Drive, which is shareddocuments:///private/var/mobile/Library/Mobile%20Documents/com~apple~CloudDocs/Downloads. But what I need is the one on the iPhone.

We have a launch daemon which can check for team identifier and some other signing information of any application on machine and match it with provided information to confirm the validity of the application/binary. We use SecStaticCodeCreateWithPath to read the signing information of the app/binary which works in most cases. However, for some third party daemon processes, the static code creation fails with error "Operation not permitted". We are having difficult time identifying why static code creation would fail specially when our process is running with root privileges. Can you please help us understand in what scenario can this API fail with this error? Can there be any process or rule which can deny creating static code of a process like endpoint security extensions/daemon? We are using default flags in SecStaticCodeCreateWithPath.

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 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)") } } }

I am using macOS virtualization farmework and able to create nad and run VMS. I need to resize the disk images using hdiutil in app sandbox environment. Is that possible? i tried disabling sandbox and it worked ok. But with sandbox i get the error message device is not configured. If this cant be done in sandbox what could be the alternative way to to achive this in sandboxed app. thanks

We have an enterprise mac OS X application which uses the UserDefaults to store the onboarding states. The strange part here is that the newly installed mac OS X app is still be able to access the UserDefalus data of removed application. Because of this, the application never becomes as a freshly installed app. Is it any limitation to Enterprise mac OS X apps? Could you please provide us the resolution for this issue.

It seems like this is not supported in the Simulator because when I run my Unit tests and I try to read protection key-value the value is always nil, even if I set the data protection level when I write the file. On device this key returns the expected value. Is it possible to have the simulator support the data protection classes to run my unit tests? FYI Im testing on iOS

We’re receiving increasing user reports that our macOS app is unexpectedly terminated in the background—without crash reports or user action. Our app is a sandboxed status-bar app (UIElement, NSStatusItem) running continuously, syncing data via CloudKit and Core Data. It has no main window unless opened via the status bar. Observed patterns: Happens more frequent on macOS 15 (Sonoma), though earlier versions are affected too. Often occurs when disk space is limited (~10% free), but occasionally happens with ample free space. System logs consistently show: CacheDeleteAppContainerCaches requesting termination assertion for <our bundle ID> No crash reports are generated, indicating macOS silently terminates our app, likely related to RunningBoard or CacheDelete purging caches during disk pressure. Since our app is meant to run persistently, these silent terminations significantly disrupt user experience. We’re seeking guidance on: Can we prevent or reduce these terminations for persistently running status bar apps? Are there recommended APIs or configurations (e.g., NSProcessInfo assertions, entitlements, LaunchAgents) to resist termination or receive notifications under low disk conditions? What are Apple’s best practices for ensuring sandboxed apps reliably run during disk pressure? We understand macOS terminates apps to reclaim space but would appreciate recommendations to improve resilience within platform guidelines. Thank you!

Hello all, I'm the developer of REHex, a hex editor which I have been distributing as an app bundle outside of the app store for a few years. REHex allows assigning various bits of metadata (comments, data types, etc) which get stored as filename.rehex-meta alongside the original filename, this works fine when the app is just a standalone bundle, however, when distributed via the app store, sandboxing seems to be mandatory, and there doesn't appear to be any obvious way to get permission to read/write such files. As fallbacks, I've considered adding support for storing the metadata as an extended attribute instead (which breaks compatibility, and won't translate when the file is on a FAT/etc filesystem or network share), or popping up the save/load dialog a second time for the user to select a .rehex-meta file, adding it to the list of whitelisted files for the application (keeps compatibility, but UX is clunky). Are there any ways I can work around this, or perhaps other methods I should consider for storing the metadata in an Apple-tolerant manner? Thanks

Hi everyone, I'm facing an issue where I cannot write a file to a shared App Group container in my tvOS app when running on a real device. My code works perfectly on the simulator, but fails on a physical device with a permissions error. I’ve set up an App Group with a custom identifier (e.g., group.<my.identifier>), and it’s correctly configured in the Capabilities section of Xcode for both my main app and widget targets. Here’s the code I’m using to save a test file: func saveTestFile() { guard let groupURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.<my.identifier>") else { print("Couldn't access the Group URL.") return } let containerURL = groupURL.appendingPathComponent("Library", isDirectory: true) if FileManager.default.isWritableFile(atPath: containerURL.path) { print("Directory IS writable") } else { print("Directory IS NOT writable") } let fileURL = containerURL.appendingPathComponent("test.txt") let content = "Hello App Group!" do { try content.write(to: fileURL, atomically: true, encoding: .utf8) print("File test.txt is saved at: \(fileURL.path)") } catch { print("Error while saving the file: \(error)") } } Console: Directory IS NOT writable Error while saving the file: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “test.txt” in the folder “”." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup//Library/test.txt, NSURL=file:///private/var/mobile/Containers/Shared/AppGroup//Library/test.txt, NSUnderlyingError=0x14387fbe0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} I’ve tried saving the file in different subdirectories within the App Group container: Directly in groupURL (root of the container). In groupURL.appendingPathComponent("Library"). In groupURL.appendingPathComponent("Caches"). Do you have any ideas what is the problem? Thanks in advance for any help!

I'll preface by saying I am new to MacOS development. I've struggled with this issue for several days and have nowhere else to go for help. My MacOS app is an Electron build. It needs application-groups entitlement for IPC. But the developer portal, when generating the provisioning profile, always appends "groups." to the start and I am unable to remove it. This renders my provisioning profile invalid and causes my app to be rejected by Transporter because it is not supposed to start with "groups", but with my team identified for MacOS. Maybe I can still use the provisioning profile as is, but I've not found any way to do that. So I'm stuck unable to deliver. Any help with this is appreciated.

I have an app with two file types with the following extensions: gop (an exported type), sgf (an imported type). The Save command fails after the following sequence of events: I open a gop file, say the file "A.gop". I save this file as an sgf file, say "A.sgf". This Save As works perfectly and the document name in the document’s title bar has changed to "A.sgf". I change something in the document and then try to Save this change. This should just resave the document to "A.sgf", but "A.sgf" remains untouched. Instead I get a system alert with the message The document “A.sgf” could not be saved. A file with the name “A.gop” already exists. To save the file, either provide a different name, or move aside or delete the existing file, and try again. In the Xcode console I get the following diagnostic: NSFileSandboxingRequestRelatedItemExtension: an error was received from pboxd instead of a token. Domain: NSPOSIXErrorDomain, code: 2 [NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/francois/Desktop/A.sgf, newURL: file:///Users/francois/Desktop/A.gop The problem seems to relate to the sandbox. But I am at a loss to find a solution. (After closing the alert, I check that A.sgf did not register the change.) If I open an sgf file, say "B.sgf", save it as "B.gop", make a change in the document and then try to save this change (into "B.gop"), I hit the same problem, with "gop" and "sgf" interchanged. If, instead of saving "A.gop" as "A.sgf", I save it as "B.sgf", make a change in the document and then try to save this change into "B.sgf", I get the following system alert: The document “B.sgf” could not be saved. You don’t have permission. To view or change permissions, select the item in the Finder and choose File &gt; Get Info. And in the Xcode console I get the following diagnostic: NSFileSandboxingRequestRelatedItemExtension: an error was received from pboxd instead of a token. Domain: NSPOSIXErrorDomain, code: 2 [NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/francois/Desktop/B.sgf, newURL: file:///Users/francois/Desktop/B.gop Again the sandbox ! (After closing the alert, I check that B.sgf did not register the change.) It’s clear my code is missing something, but what?

I have a DocumentGroup working with a FileDocument, and that's fine. However, when someone creates a new document I want them to have to immediately save it. This is the behavior on ipadOS and iOS from what I can understand (you select where before the file is created). There seems to be no way to do this on macOS? I basically want to have someone: create a new document enter some basic data hit "create" which saves the file then lets the user start editing it (1), (2), and (4) are done and fairly trivial. (3) seems impossible, though...? This really only needs to support macOS but any pointers would be appreciated.

Hi Is there a way to check if a file at a specified URL is open and being edited by another application. Assuming that we have permission to access the file at the URL.

I'm trying to write a Mac OS swift application that perform some processing each time a file is added to a directory (std folder automation is very slow ...). I want the application to run in background without GUI. I created an AppDelegate.swift with an applicationDidFinishLaunching function which seems to be never called. As a newbie I'm completely struggling : could someone help or guide me to any relevant resource (book, blog ...) Thx in advance code.txt