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 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.

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>

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 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

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 have my both app and fskit sandboxed <key>com.apple.security.app-sandbox</key> <true/> Which means that I can read files only in app container. First, is sandboxing required for fskit modules? Second, there are docs which implies that it's possible to explicitly allow fskit module to access external files, by passing their paths to mount params. https://developer.apple.com/documentation/fskit/fstaskoptions/url(foroption:) and also options: Options to apply to the activation. These can include security-scoped file paths. There are no defined options currently. I've tried this, but haven't success. My Info.plist is <key>FSActivateOptionSyntax</key> <dict> <key>shortOptions</key> <string>g:m:</string> <key>pathOptions</key> <dict> <key>m</key> <string>file</string> <key>g</key> <string>directory</string> </dict> </dict> I'm mounting with mount -F -t MyFS -o -m=./build.sh,-g=./ /dev/disk5 /tmp/TestVol Getting them via options.url(forOption: "m"), options.url(forOption: "g") Both nulls. I also see that options are presented in options.taskOptions But they are not expanded to absolute pathes or urls, which makes me think that pathOptions declaration is incorrect. Docs says This dictionary uses the command option name as a key, and each entry has a value indicating what kind of entry to create. What entry kind means in this context? Can you send example of correct pathOptions?

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 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.

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

Security scoped bookmarks that were created before updating to macOS 14.7.5 cannot be resolved anymore after updating to macOS 14.7.5. Reproduction: Sandboxed app on macOS version 14.7.4 Create and store a security scoped bookmark to a user selected folder: let url: URL = <user selected url from NSOpenPanel> let data = try url.bookmarkData(options: [.withSecurityScope], includingResourceValuesForKeys: nil, relativeTo: nil) <persistently store data> Update to macOS 14.7.5 Resolve the previously stored bookmark: let data: Data = <restore data from persistent storage> var stale: Bool = true let url = try URL(resolvingBookmarkData: data, options: [.withSecurityScope], relativeTo: nil, bookmarkDataIsStale: &stale) Expected: The bookmark is resolved correctly and the resulting url can be used to access the folder/file in the sandboxed app after starting access. Observed: URL(resolvingBookmarkData:) throws an error: Error Domain=NSCocoaErrorDomain Code=259 "The file couldn’t be opened because it isn’t in the correct format." New security scoped bookmarks created on macOS 14.5.7 can be resolved without issue. The same appears to happen with macOS 13.7.5. Entitlements: com.apple.security.app-sandbox com.apple.security.files.bookmarks.app-scope com.apple.security.files.user-selected.read-write This is very disruptive, as it appears that Sandboxed apps cannot access any previously stored bookmarks anymore. Particularly after the recent ScopedBookmarkAgent issues in 14.7.1 and 15.0, which were resolved in 14.7.3/15.1 respectively: https://developer.apple.com/forums/thread/764435

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!

macos 15.4 beta claims to support FSKit. Is there an FSKit sample available? I don't see anything useful in the published docs.

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 want to implement quota feature to my file provider extension. I am able to keep track of materialized files total size. (Content download and edit operations) However I cannot detect file eviction operation (User right click to file and select "Remove Download"). Is there anyway to detect this action Or any suggestion to keep track of materialized files total size?

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

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?