General: Forums subtopic: Privacy & Security > General Forums tag: App Sandbox App Sandbox documentation App Sandbox Design Guide documentation — This is no longer available from Apple. There’s still some info in there that isn’t covered by the current docs but, with the latest updates, it’s pretty minimal (r. 110052019). Still, if you’re curious, you can consult an old copy [1]. App Sandbox Temporary Exception Entitlements archived documentation — To better understand the role of temporary exception entitlements, see this post. Embedding a command-line tool in a sandboxed app documentation Discovering and diagnosing App Sandbox violations (replaces the Viewing Sandbox Violation Reports forums post) Resolving App Sandbox Inheritance Problems forums post The Case for Sandboxing a Directly Distributed App forums post Implementing Script Attachment in a Sandboxed App forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For example, this one archived by the Wayback Machine.

Hello, Apple Developer Community! I am attempting to test a user upgrade scenario from an existing monthly subscription to a yearly subscription, applying a Promotional Offer within the sandbox environment. When trying to process the transaction, I consistently receive the following errors from StoreKit: <SKPaymentQueue: 0x...>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3903 "Unable to Purchase" UserInfo={NSLocalizedFailureReason=Unable to Purchase, client-environment-type=Sandbox, AMSServerErrorCode=3903, storefront-country-code=USA} [...]: Finishing transaction <SKPaymentTransaction: 0x...> with no identifier Additionally, the standard dialog shown to the user displays: Unable to Purchase Contact the developer for more information. [Environment: Sandbox] My Implementation Details: Scenario: The user has an active monthly subscription and attempts to upgrade to a yearly subscription with a Promotional Offer (discount). Signature Generation: I use a custom backend written in Go to generate the signature, nonce, and timestamp. The code follows Apple’s documentation requirements, including proper encoding and formatting. Client (iOS): On the Swift side, I correctly initialize the SKPaymentDiscount and add it to the SKMutablePayment before adding the payment to the queue. The applicationUsername property is used and matches on both server and client sides. What I Have Already Verified and Ruled Out: New Test Accounts: I have created multiple fresh sandbox tester accounts in different regions (USA, Canada, Germany) and used them. Time Synchronization: The time on my server and the test device is synchronized. Parameters: Bundle ID, Product ID, and Offer ID match exactly with the configurations in App Store Connect. App Store Connect Agreements: The Paid Applications Agreement is active. Testing Environment: Testing is conducted on a physical device (iPhone), not a simulator. It seems the issue may not be related to my code but rather a potential glitch within the Apple sandbox environment itself when processing complex upgrade requests with a promotional offer. Has anyone encountered a similar issue when testing Promotional Offers? I would appreciate any help or guidance.

Hi, We have several Apps that use CEF internally for real-time offscreen HTML rendering. Specifically, we have a framework with an embedded XPC service that itself uses CEF to render HTML and sends the resulting IOSurface back to the host App via XPC for rendering in a Metal pipeline. So far our Apps have only been available as a direct download, but recently we have been trying to submit one of them to the MAS and have run into several issues, CEF being one of them. The core of the issue seems to be that submission to the MAS requires that all executables, including XPC services, be signed with the sandbox entitlement. After enabling the sandbox on the host App, my XPC service with CEF continued to function as before. However, after signing the XPC service with the sandbox entitlement, it stopped working. After some research, it seems that the issue here is that the XPC service once signed with the entitlement is running in its own sandbox, and because CEF uses global Mach ports for internal communication, this then fails. Further, I have read from other developers that even if these issues are overcome by e.g. modifying CEF, they have been rejected by the review team because CEF uses some private API calls. So my question is, does anyone have concrete information on whether or not it will be possible to successfully submit an App using CEF in this way (App > Framework > XPC > CEF) for publication on the MAS? Further, as an alternative I have been looking at WebKit, specifically WKWebView and calling "takeSnapshot", as this seems to be the only documented way to retrieve pixels. However, it seems that this method is not designed for real-time rendering. Assuming that CEF is a non-starter for the MAS, is there anything specific that Apple recommends for real-time offscreen HTML rendering? Cheers, Dave Lincoln

Cross post from my post here. https://developer.apple.com/forums/thread/807142 I was advised to post in this category. Will I be rejected if I let users ssh into their own macs to run command line programs. I just got this in an email. Is that relevant to letting users ssh into their own box? Where do we go to get permission from apple? Is that before or after app store review? "4.7.2: Clarifies that apps offering software not embedded in the binary may not extend or expose native platform APIs or technologies to the software without prior permission from Apple." Original post before response from Apple: Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here. I have a blog post describing some of my app's features here: https://blog.greenrobot.com/2025/11/05/codefrog-find-and-fix-bugs-fast-with-macos-and-mobile-apps/

I want to check whether a sandboxed application already has access permission to a specific URL. Based on my investigation, the following FileManager method seems to be able to determine it: FileManager.default.isReadableFile(atPath: fileURL.path) However, the method name and description don't explicitly mention this use case, so I'm not confident there aren't any oversights. Also, since this method takes a String path rather than a URL, I'd like to know if there's a more modern API available. I want to use this information to decide whether to prompt the user about the Sandbox restriction in my AppKit-based app.

Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here.

Dear App Review & App Store policy team, I am writing as an independent macOS developer who has spent more than the last six months building TilesWM, a full‑featured window‑manager that rivals existing products such as Magnet, Divvy and BetterSnapTool. The app works exactly like those solutions: it uses the Accessibility (AX) API to move and resize arbitrary windows, registers global hot‑keys, and stores user preferences locally in ~/Library/Application Support/<bundle‑identifier>. When I attempt to submit TilesWM through App Store Connect the validation process failed with two errors, one of which was relatively easily solvable with the help of "ssmith_c" and "Quinn". The other, the hard blocker: Sandbox not enabled – the app does not contain the required com.apple.security.app-sandbox = true entitlement. but: The same accessibility entitlement is absent from the binaries of Magnet, Divvy, BetterSnapTool and other window‑manager apps that are already available on the Mac App Store. Those applications were on the Store before Apple introduced the mandatory sandbox requirement (≈ macOS 10.7.3-ish). Consequently, they continue to operate without a sandbox while new entrants are forced either to abandon the platform or to distribute outside the App Store. This situation creates an uneven playing field that contradicts Apple’s stated commitment to an open and competitive ecosystem. All developers pay the same $99 annual fee and should follow identical review guidelines; yet legacy window‑manager apps enjoy a privileged exemption that new developers cannot obtain, effectively granting them a perpetual non‑compete advantage. What I am asking for Clarification: Is a missing Sandbox entitlement truly unsupported for Mac App Store distribution or is there a way to "request" an exception? Policy action: Please evaluate an option to provide a concrete path forward so that TilesWM can be submitted without having to abandon the App Store. Point of contact – If this issue falls outside the scope of App Review, kindly direct me to the team or individual responsible for macOS sandbox policy decisions. I remain committed to distributing my app through the Mac App Store because it is the primary channel users trust and expect. I believe that a fair resolution will benefit developers, Apple, and end‑users alike by expanding the selection of high‑quality window‑management tools. Thank you for your attention to this matter. I look forward to a constructive response and to working together toward an equitable solution. Respectfully, Denis Steinhorst Full‑Stack Engineer & macOS enthusiast Bundle ID: dev.steinhorst.tileswm

I am slowly converting an Objective C with C program to Swift with C. All of my menus and dialog boxes are now in Swift, but files are still opened and closed in Objective C and C. The following code is Objective C and tries to open two files in the same directory with two related names after getting the base of the name from a Save Panel. The code you see was modified by ChatGPT 5.0, and similar code was modified by Claude. Both LLMs wrote code that failed because neither knows how to navigate Apple’s sandbox. Does anybody understand Apple’s sandbox? I eventually want to open more related files and do not want the user to have to click through multiple file dialog boxes. What is the best solution? Are the LLMs just not up to the task and there is a simple solution to the Objective C code? Is this easier in Swift? Other ideas? Thanks in advance for any help. (BOOL)setupOutputFilesWithBaseName:(NSString*)baseName { NSString *outFileNameStr = baseName; if (outFileNameStr == nil || [outFileNameStr length] == 0) { outFileNameStr = @"output"; } // Show ONE save panel for the base filename NSSavePanel *savePanel = [NSSavePanel savePanel]; [savePanel setMessage:@"Choose base name and location for output files\n(Two files will be created: one ending with 'Pkout', one with 'Freqout')"]; [savePanel setNameFieldStringValue:outFileNameStr]; if (directoryURL != nil) { [savePanel setDirectoryURL:directoryURL]; } if ([savePanel runModal] != NSModalResponseOK) { NSLog(@"User cancelled file selection"); return NO; } // Get the selected file URL - this gives us security access to the directory NSURL *baseFileURL = [savePanel URL]; // Get the directory - THIS is what we need for security scope NSURL *dirURL = [baseFileURL URLByDeletingLastPathComponent]; // Start accessing the DIRECTORY, not just the file BOOL didStartAccessing = [dirURL startAccessingSecurityScopedResource]; if (!didStartAccessing) { NSLog(@"Warning: Could not start security-scoped access to directory"); } NSString *baseFileName = [[baseFileURL lastPathComponent] stringByDeletingPathExtension]; NSString *extension = [baseFileURL pathExtension]; // Create the two file names with suffixes NSString *pkoutName = [baseFileName stringByAppendingString:@"Pkout"]; NSString *freqoutName = [baseFileName stringByAppendingString:@"Freqout"]; NSURL *pkoutURL = [dirURL URLByAppendingPathComponent:pkoutName]; NSURL *freqoutURL = [dirURL URLByAppendingPathComponent:freqoutName]; NSLog(@"Attempting to open: %@", [pkoutURL path]); NSLog(@"Attempting to open: %@", [freqoutURL path]); // Open the first file (Pkout) globalFpout = fopen([[pkoutURL path] UTF8String], "w+"); if (globalFpout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Pkout file at %@", [pkoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Pkout file opened: %@", [pkoutURL path]); // Open the second file (Freqout) globalFpfrqout = fopen([[freqoutURL path] UTF8String], "w+"); if (globalFpfrqout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Freqout file at %@", [freqoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); fclose(globalFpout); globalFpout = NULL; if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Freqout file opened: %@", [freqoutURL path]); // Store the directory URL so we can stop accessing later secureDirectoryURL = dirURL; return YES; }

Hello Apple Developer Support, I’m writing with a mix of enthusiasm and frustration after more than six months of full‑time development on my macOS window‑manager TilesWM (a feature‑rich competitor to Magnet, Divvy, BetterSnapTool, etc.). I have completed the Application, the product page, a knowledge-base with 90+ entries, an in-app onboarding flow, preparing the feedback-hub for submissions, all required marketing assets and finally; signing up for the $99 Developer Program... I am now blocked at App Store Connect validation. What I’m trying to submit App name: TilesWM Bundle ID: dev.steinhorst.tileswm Core functionality: Detect window movement & resize windows, optional global hot‑keys, persistent user settings are stored in a SQLite-DB located at: ~/Library/Application Support/<bundle‑identifier> Privacy: No analytics, no data collection, no runtime downloads. Tested on: macOS 15.6.1 (Apple Silicon M1) & macOS 26.0.1 (M3‑Max). The app works exactly like the existing mainstream window managers: it runs non‑sandboxed and requests Accessibility (AX) permissions on demand to control other windows dimensions and positioning. Validation errors Validation failed Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, key 'com.apple.security.accessibility' in 'dev.steinhorst.tileswm.pkg/Payload/TilesWM.app/Contents/MacOS/TilesWM' is not supported. (ID: 13b13813-edd6-4be6-b392-9db5bddd39a0) Validation failed App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "dev.steinhorst.tileswm.pkg/Payload/TilesWM.app/Contents/MacOS/TilesWM" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. (ID: 28aa17e8-e7b2-4f3f-8def-15922c68ec8a) . In short, App Store Connect refuses to accept an app that uses the Accessibility API and is not sandboxed. Yet the same capability is openly used by Magnet, Divvy, BetterSnapTool and other competitors that are currently on the Mac App Store. Why this matters to me I am a full‑stack engineer with 15+ years of enterprise experience; side projects keep my skills sharp and give back to the macOS community. This would be my entry to the software-side of MacOS, the next product-ideas are scribbled already. Over the last six months I have designed, coded, documented, created marketing assets, purchased a domain, paid for hosting, and funded the Apple Developer Program, all in good faith that the app could be submitted. What I need help with Clarification – Is the com.apple.security.accessibility entitlement truly unsupported for macOS distribution, how can Magnet and other competitors exist in that case, shouldn't they be able to receive competition? Guidance – If sandboxing is mandatory (even though the competition doesn't use it either, looking at their entitlements with codesign -d --entitlements :-<path>). What is the recommended way to retain full window‑management functionality while remaining within Apple’s policies, I tried sandboxing it, but the only app I was able to "resize" was TilesWM (my App) itself. Additional resources A "basic"-demo video, feature comparisons, FAQ & knowledge-base as well as the feedback hub: https://www.tileswm.app I appreciate any insight you can provide. My goal is to bring a polished, useful tool to the Mac App Store while fully respecting Apple’s security requirements, without having to discard months of work or resort to an external distribution model. Thank you for your time and assistance. Best regards, Denis Steinhorst Full‑Stack Engineer – macOS enthusiast Bundle ID: dev.steinhorst.tileswm

Hi everyone, I am developing a .NET MAUI Mac Catalyst app (sandboxed) that communicates with a custom vendor-specific HID USB device. Within the Catalyst app, I am using a native iOS library (built with Objective-C and IOKit) and calling into it via P/Invoke from C#. The HID communication layer relies on IOHIDManager and IOUSBInterface APIs. The device is correctly detected and opened using IOHIDManager APIs. However, IOHIDDeviceRegisterInputReportCallback never triggers — I don’t receive any input reports. To investigate, I also tried using low-level IOKit USB APIs via P/Invoke from my Catalyst app, calling into a native iOS library. When attempting to open the USB interface using IOUSBInterfaceOpen() or IOUSBInterfaceOpenSeize(), both calls fail with: kIOReturnNotPermitted (0xe00002e2). — indicating an access denied error, even though the device enumerates and opens successfully. Interestingly, when I call IOHIDDeviceSetReport(), it returns status = 0, meaning I can successfully send feature reports to the device. Only input reports (via the InputReportCallback) fail to arrive. I’ve confirmed this is not a device issue — the same hardware and protocol work perfectly under Windows using the HIDSharp library, where both input and output reports function correctly. What I’ve verified •Disabling sandboxing doesn’t change the behavior. •The device uses a vendor-specific usage page (not a standard HID like keyboard/mouse). •Enumeration, open, and SetReport all succeed — only reading input reports fails. •Tried polling queues, in queues Input_Misc element failed to add to the queues. •Tried getting report in a loop but no use.

Our app is unable to write to its own sandbox container on macOS when run via “My Mac (Designed for iPad)”. This is not an issue when the app runs on iPhone or on iPad. This seems to affect all attempts to write to the file system including: UserDefaults Core Data (SQLite) Firebase (Analytics, Crashlytics, Sessions) File creation (PDFs, temp files, etc.) We're seeing the following errors in the console: Operation not permitted / NSCocoaErrorDomain Code=513: Permissions error when writing to disk. CFPrefsPlistSource: Path not accessible: Failure to write to UserDefaults. Cannot synchronize user defaults to disk: UserDefaults write blocked. CoreData: No permissions to create file: Core Data SQLite store can't be created. Firebase: Failed to open database: Firebase can't initialize local storage. CGDataConsumerCreateWithFilename: failed to open ... for writing: PDF generation fails due to temp directory access issues. Created a test project to try and reproduce the issue but unable to do so in the test project, even when setting all the build settings the same as the project having issues.

Hello! My question is about 1) if we can use any and or all accessibility features within a sandboxed app and 2) what steps we need to take to do so. Using accessibility permissions, my app was working fine in Xcode. It used NSEvent.addGlobalMonitorForEvents and localMoniter, along with CGEvent.tapCreate. However, after downloading the same app from the App Store, the code was not working. I believe this was due to differences in how permissions for accessibility are managed in Xcode compared to production. Is it possible for my app to get access to all accessibility features, while being distributed on the App Store though? Do I need to add / request any special entitlements like com.apple.security.accessibility? Thanks so much for the help. I have done a lot of research on this online but found some conflicting information, so wanted to post here for a clear answer.

I'm developing a Share Extension for a macOS Electron application that allows users to share files from Finder to our application using the system Share menu. The extension compiles, signs, and notarizes successfully, but crashes during initialization due to sandbox restrictions blocking hid-control operations required by NSApplication. The Share Extension crashes during initialization with the following sandbox violation: Process: ShareExtension [pid] Identifier: com.xxxxxxxxxxxx.xxxxxxxxx.extension Operation: hid-control I would appreciate guidance on: The proper entitlements for third-party Share Extensions with App Sandbox Alternative approaches if Share Extensions have fundamental limitations for third-party developers Any documentation or sample code demonstrating Share Extensions outside the App Store

Hello, I'm running into an issue with a complex macOS application (non-AppStore) structure involving an unsandboxed system daemon and a sandboxed SSO Extension attempting to communicate via XPC Mach service. The macOS app is composed of three main components: Main App: unsandboxed, standard macOS application. System Daemon: unsandboxed executable installed with a .plist to /Library/LaunchDaemons/ and loaded by launchd. It exposes an XPC Mach Service. SSO Extension: a sandboxed Authentication Services Extension (ASAuthorizationProviderExtension). Main App to System Daemon communication works perfectly. The unsandboxed main app can successfully create and use an XPC connection to the System Daemon's Mach service. But SSO Extension cannot establish an XPC connection to the System Daemon's Mach service, despite using the recommended temporary exception entitlement. I have added the following entitlement to the SSO Extension's entitlements file: <key>com.apple.security.temporary-exception.mach-lookup.global-name</key> <array> <string>my.xpc.service.system.daemon</string> </array> (The name my.xpc.service.system.daemon is the exact name registered by the System Daemon in its Launch Daemon plist's MachServices dictionary.) When the SSO Extension attempts to create the connection, the following log output is generated: default 08:11:58.531567-0700 SSOExtension [0x13f19b090] activating connection: mach=true listener=false peer=false name=my.xpc.service.system.daemon default 08:11:58.532150-0700 smd [0xb100d8140] activating connection: mach=false listener=false peer=true name=com.apple.xpc.smd.peer[1575].0xb100d8140 error 08:11:58.532613-0700 smd Item real path failed. Maybe the item has been deleted? error 08:11:58.532711-0700 SSOExtension Unable to find service status () error: 22 The error Unable to find service status () error: 22. Error code 22 typically translates to EINVAL (Invalid argument), but in this context, it seems related to the system's ability to find and activate the service for the sandboxed process. Questions: Is the com.apple.security.temporary-exception.mach-lookup.global-name entitlement sufficient for a sandboxed SSO Extension to look up a system-wide Launch Daemon Mach service, or are there additional restrictions or required entitlements for extensions? The smd log output Item real path failed. Maybe the item has been deleted? seems concerning. Since the unsandboxed main app can connect, this suggests the service is running and registered. Could this error indicate a sandbox permission issue preventing smd from verifying the path for the sandboxed process? Are there specific sandboxing requirements for Mach service names when communicating from an Extension versus a main application? Any guidance on how a sandboxed SSO Extension can reliably connect to an unsandboxed, non-app-group-related system daemon via XPC Mach service would be greatly appreciated!

I'm having a problem on macOS 26 that has not happened on previous macOS versions. When I call guard url.startAccessingSecurityScopedResource() else { return } try url.bookmarkData(options: [.withSecurityScope]) with url being "file:///", I get an error Error Domain=NSCocoaErrorDomain Code=256 "File descriptor doesn't match the real path." Given that Google returns 0 results on this error, I suppose this is a macOS 26 novelty. (The bookmark data created before upgrading to 26 resolve well). Does anyone already met this or have an idea on how to get around it? The app is a file manager, so having bookmarked access to "/" is crucial.

Is it possible to create a sandboxed app that uses accessibility permission? And if so, how do I ask the user for that permission in a way that is allowed by the App Store? Im creating a small menubar app and my current (rejected) solution is to create a pop-up, with link to Security &amp; Privacy &gt; Accessibility and the pop-up asks the user to manually add the app to the list and check the checkbox. This works in sandbox. Reason for rejection: "Specifically, your app requires to grant accessibility access, but once we opened the accessibility settings, your app was not listed." I know it's not listed there and it has to be added manually. But its the only solution I've found to this issue. Is there perhaps any way to add the app there programmatically? Im a bit confused since I've seen other apps in App Store that work the same way, where you have to add the app to the list manually. Eg. Flycut. :man-shrugging: I know about this alternative solution, and it's not allowed in sandboxed apps. It also adds the app to the accessibility list automagically: func getPermission() { AXIsProcessTrustedWithOptions([kAXTrustedCheckOptionPrompt.takeUnretainedValue():true] as CFDictionary). } Does anyone have a solution for this? Best regards, Daniel

I'm developing a macOS console application that uses ODBC to connect to PostgreSQL. The application works fine when run normally, but fails to load the ODBC driver when debugging with LLDB(under root works fine as well). Error Details When running the application through LLDB, I get this sandbox denial in the system log (via log stream): Error 0x0 0 0 kernel: (Sandbox) Sandbox: logd_helper(587) deny(1) file-read-data /opt/homebrew/lib/psqlodbcw.so The application cannot access the PostgreSQL ODBC driver located at /opt/homebrew/lib/psqlodbcw.so(also tried copy to /usr/local/lib/...). Environment macOS Version: Latest Sequoia LLDB: Using LLDB from Xcode 16.3 (/Applications/Xcode16.3.app/Contents/Developer/usr/bin/lldb) ODBC Driver: PostgreSQL ODBC driver installed via Homebrew Code Signing: Application is signed with Apple Development certificate What is the recommended approach for debugging applications that need to load dynamic libraries? Are there specific entitlements or configurations that would allow LLDB to access ODBC drivers during debugging sessions? Any guidance would be greatly appreciated. Thank you for any assistance!

Problem summary I have a macOS helper app that is launched from a sandboxed main app. The helper: has com.apple.security.app-sandbox = true and com.apple.security.inherit = true in its entitlements, is signed and embedded inside the main app bundle (placed next to the main executable in Contents/MacOS), reports entitlement_check = 1 (code signature contains sandbox entitlement, implemented via SecStaticCode… check), sandbox_check(getpid(), NULL, 0) returns 1 (runtime sandbox enforcement present), APP_SANDBOX_CONTAINER_ID environment variable is not present (0). Despite that, Cocoa APIs return non-container home paths: NSHomeDirectory() returns /Users/&lt;me&gt;/ (the real home). [[NSFileManager defaultManager] URLsForDirectory:inDomains:] and URLForDirectory:inDomain:appropriateForURL:create:error: return paths rooted at /Users/&lt;me&gt;/ (not under ~/Library/Containers/&lt;app_id&gt;/Data/...) — i.e. they look like non-sandboxed locations. However, one important exception: URLForDirectory:... for NSItemReplacementDirectory (temporary/replacement items) does return a path under the helper's container (example: ~/Library/Containers/&lt;app_id&gt;/Data/tmp/TemporaryItems/NSIRD_&lt;helper_name&gt;_hfc1bZ). This proves the sandbox is active for some FileManager APIs, yet standard directory lookups (Application Support, Documents, Caches, and NSHomeDirectory()) are not being redirected to the container. What I expect The helper (which inherits the sandbox and is clearly sandboxed) should get container-scoped paths from Cocoa’s FileManager APIs (Application Support, Documents, Caches), i.e. paths under the helper’s container: /Users/&lt;me&gt;/Library/Containers/&lt;app_id&gt;/Data/.... What I tried / diagnostics already gathered Entitlements &amp; code signature codesign -d --entitlements :- /path/to/Helper.app/Contents/MacOS/Helper # shows com.apple.security.app-sandbox = true and com.apple.security.inherit = true Runtime checks (Objective-C++ inside helper): extern "C" int sandbox_check(pid_t pid, const char *op, int flags); NSLog(@"entitlement_check = %d", entitlement_check()); // SecStaticCode check NSLog(@"env_variable_check = %d", (getenv("APP_SANDBOX_CONTAINER_ID") != NULL)); NSLog(@"runtime_sandbox_check = %d", sandbox_check(getpid(), nullptr, 0)); NSLog(@"NSHomeDirectory = %s", NSHomeDirectory()); NSArray *urls = [[NSFileManager defaultManager] URLsForDirectory:NSApplicationSupportDirectory inDomains:NSUserDomainMask]; NSLog(@"URLsForDirectory: %@", urls); Observed output: entitlement_check = 1 env_variable_check = 0 runtime_sandbox_check = 1 NSHomeDirectory = /Users/&lt;me&gt; URLsForDirectory: ( "file:///Users/&lt;me&gt;/Library/Application%20Support/..." ) Temporary/replacement directory (evidence sandbox active for some APIs): NSURL *tmpReplacement = [[NSFileManager defaultManager] URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:&amp;err]; NSLog(@"NSItemReplacementDirectory: %@", tmpReplacement.path); Observed output (example): /Users/&lt;me&gt;/Library/Containers/&lt;app_id&gt;/Data/tmp/TemporaryItems/NSIRD_&lt;helper_name&gt;_hfc1bZ Other facts Calls to NSHomeDirectory() and URLsForDirectory: are made after main() to avoid "too early" initialization problems. Helper is placed in Contents/MacOS (not Contents/Library/LoginItems). Helper is a non-GUI helper binary launched by the main app (not an XPC service). macOS version: Sequoia 15.6 Questions Why do NSHomeDirectory() and URLsForDirectory: return the real /Users/&lt;me&gt;/... paths in a helper process that is clearly sandboxed (entitlement + runtime enforcement), while NSItemReplacementDirectory returns a container-scoped temporary path? Is this behavior related to how the helper is packaged or launched (e.g., placement in Contents/MacOS vs Contents/Library/LoginItems, or whether it is launched with posix_spawn/fork+exec vs other APIs)? Are there additional entitlements or packaging rules required for a helper that inherits sandbox to have Cocoa directory APIs redirected to the container (for Application Support, Documents, Caches)? *Thanks in advance — I can add any requested logs

In FileProvider framework based app, is it mandatory to make the host-app sandboxed? I think, no, as Google Drive app is non-sandboxed. But when removing sandboxing from my hostApp, even though mount is visible in Finder but extesnion is not being launched and Finder shows a error message saying "MyApp encountered an error. Items may be out of date." And when I add app-sanboxing, then things work fine. Can someone please help how can we remove sandboxing of hostApp and still make it work. Is there any specific entitlement we need to add, or any whitelisting needed for our Developer Team Id?

I'm trying to distribute a sandboxed macOS app with a PacketTunnelProvider (system extension) via direct distribution (outside of AppStore). The app and the extension both use the same app group, using the new group.com.XXXX.YYYY format detailed here for 10.15+ https://developer.apple.com/forums/thread/721701 I've also followed the instructions below to get around the quirk of not being able to directly process it via XCode: https://developer.apple.com/forums/thread/737894 I've re-signed with Developer ID certificate, all that is smooth and successfully notarized. However upon running the app I get: "My.app" would like to access data from other apps. Checking ~/Library/Containers ~/Library/Group Containers I see the correct files folders have been created before I select Don't Allow and Allow. My app does not access any files or folders outside of the sandboxed directories. How can I prevent this from happening? In order to diagnose further, how to diagnose exactly which files/folder the app is trying to access that is causing this problem?

Script attachment enables advanced users to create powerful workflows that start in your app. NSUserScriptTask lets you implement script attachment even if your app is sandboxed. This post explains how to set that up. IMPORTANT Most sandboxed apps are sandboxed because they ship on the Mac App Store [1]. While I don’t work for App Review, and thus can’t make definitive statements on their behalf, I want to be clear that NSUserScriptTask is intended to be used to implement script attachment, not as a general-purpose sandbox bypass mechanism. If you have questions or comments, please put them in a new thread. Place it in the Privacy &amp; Security &gt; General subtopic, and tag it with App Sandbox. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Most but not all. There are good reasons to sandbox your app even if you distribute it directly. See The Case for Sandboxing a Directly Distributed App. Implementing Script Attachment in a Sandboxed App Some apps support script attachment, that is, they allow a user to configure the app to run a script when a particular event occurs. For example: A productivity app might let a user automate repetitive tasks by configuring a toolbar button to run a script. A mail client might let a user add a script that processes incoming mail. When adding script attachment to your app, consider whether your scripting mechanism is internal or external: An internal script is one that only affects the state of the app. A user script is one that operates as the user, that is, it can change the state of other apps or the system as a whole. Supporting user scripts in a sandboxed app is a conundrum. The App Sandbox prevents your app from changing the state of other apps, but that’s exactly what your app needs to do to support user scripts. NSUserScriptTask resolves this conundrum. Use it to run scripts that the user has placed in your app’s Script folder. Because these scripts were specifically installed by the user, their presence indicates user intent and the system runs them outside of your app’s sandbox. Provide easy access to your app’s Script folder Your application’s Scripts folder is hidden within ~/Library. To make it easier for the user to add scripts, add a button or menu item that uses NSWorkspace to show it in the Finder: let scriptsDir = try FileManager.default.url(for: .applicationScriptsDirectory, in: .userDomainMask, appropriateFor: nil, create: true) NSWorkspace.shared.activateFileViewerSelecting([scriptsDir]) Enumerate the available scripts To show a list of scripts to the user, enumerate the Scripts folder: let scriptsDir = try FileManager.default.url(for: .applicationScriptsDirectory, in: .userDomainMask, appropriateFor: nil, create: true) let scriptURLs = try FileManager.default.contentsOfDirectory(at: scriptsDir, includingPropertiesForKeys: [.localizedNameKey]) let scriptNames = try scriptURLs.map { url in return try url.resourceValues(forKeys: [.localizedNameKey]).localizedName! } This uses .localizedNameKey to get the name to display to the user. This takes care of various edge cases, for example, it removes the file name extension if it’s hidden. Run a script To run a script, instantiate an NSUserScriptTask object and call its execute() method: let script = try NSUserScriptTask(url: url) try await script.execute() Run a script with arguments NSUserScriptTask has three subclasses that support additional functionality depending on the type of the script. Use the NSUserUnixTask subsclass to run a Unix script and: Supply command-line arguments. Connect pipes to stdin, stdout, and stderr. Get the termination status. Use the NSUserAppleScriptTask subclass to run an AppleScript, executing either the run handler or a custom Apple event. Use the NSUserAutomatorTask subclass to run an Automator workflow, supplying an optional input. To determine what type of script you have, try casting it to each of the subclasses: let script: NSUserScriptTask = … switch script { case let script as NSUserUnixTask: … use Unix-specific functionality … case let script as NSUserAppleScriptTask: … use AppleScript-specific functionality … case let script as NSUserAutomatorTask: … use Automatic-specific functionality … default: … use generic functionality … }