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.
App Sandbox
RSS for tagApp Sandbox is a macOS access control technology designed to contain damage to the system and user data if an app becomes compromised.
Posts under App Sandbox tag
97 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
Accessibility
App Sandbox
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
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
App Review
Mac App Store
App Sandbox
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 & Privacy > 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
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
Mac App Store
App Sandbox
Privacy
Accessibility
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/<me>/ (the real home).
[[NSFileManager defaultManager] URLsForDirectory:inDomains:] and
URLForDirectory:inDomain:appropriateForURL:create:error: return paths rooted at /Users/<me>/ (not under ~/Library/Containers/<app_id>/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/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_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/<me>/Library/Containers/<app_id>/Data/....
What I tried / diagnostics already gathered
Entitlements & 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/<me>
URLsForDirectory: ( "file:///Users/<me>/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:&err];
NSLog(@"NSItemReplacementDirectory: %@", tmpReplacement.path);
Observed output (example):
/Users/<me>/Library/Containers/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_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/<me>/... 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?
Topic:
App & System Services
SubTopic:
Networking
Tags:
Network Extension
System Extensions
App Sandbox
Developer ID
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 & Security > 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 …
}
I have built an app that does audio analysis. I have stripped the GPL files from these binaries regarding license issues. The binnaries are in the root folder of ny build next to the .app file MacOs/
I can not run this in sandbox mode. Everything works except for the audio analysis. Can I still submit this to the AppStore and get accepted? Will users whom download the app be able to run the audio analysis?
I aaked this on Apple support but they gave me a general answer to appstore documentation
Hope someone here has experience with this.
Hello,
Unable to see the App Sandbox entitlement while creating a new App ID. Have tried to recreate APP ID multiple times. Don't see the option in Developer portal.
Hello everyone,
I'm developing a macOS application that programmatically sets custom icons for folders, and I've hit a wall trying to get Finder to display the icon changes consistently.
The Goal:
To change a folder's icon using NSWorkspace.shared.setIcon and have Finder immediately show the new icon.
What I've Tried (The Refresh Mechanism):
After setting the icon, I attempt to force a Finder refresh using several sandbox-friendly techniques:
Updating the Modification Date (the "touch" method):
try FileManager.default.setAttributes([.modificationDate: Date()], ofItemAtPath: pathToUse)
Notifying NSWorkspace:
NSWorkspace.shared.noteFileSystemChanged(pathToUse)
Posting Distributed Notifications:
DistributedNotificationCenter.default().post(name: Notification.Name("com.apple.Finder.FolderChanged"), object: pathToUse)
The Problem:
This combination of methods works perfectly, but only under specific conditions:
When setting a custom icon on a folder for the first time.
When changing the icon of an alias.
For any subsequent icon change on a regular folder, Finder stubbornly displays the old, cached icon. I've confirmed that the user can see the new icon by manually closing and reopening the folder window, but this is obviously not a user-friendly solution.
Investigating a Reset with AppleScript:
I've noticed that the AppleScript update command seems to force the kind of complete refresh I need:
tell application "Finder"
update POSIX file "/path/to/your/folder"
end tell
Running this seems to reset the folder's state in Finder, effectively recreating the "first-time set" scenario where my other methods work.
However, the major roadblock is that I can't figure out how to reliably execute this from a sandboxed environment. I understand it likely requires specific scripting entitlements, but it's unclear which ones would be needed for this update command on a user-chosen folder, or if it's even permissible for the App Store.
My Questions:
Is there a reliable, sandbox-safe way to make the standard Cocoa methods (noteFileSystemChanged, updating the modification date, etc.) work for subsequent icon updates on regular folders? Am I missing a step?
If not, what is the correct way to configure a sandboxed app's entitlements to safely run the tell application "Finder" to update command for a folder the user has granted access to?
Any insight or alternative approaches would be greatly appreciated. Thank you
Hi,
I want to detect if there is a fullscreen window on each screen.
_AXUIElementGetWindow and kAXFullscreenAttribute methods work, but I have to be in a non-sandbox environment to use them.
Is there any other way that also works? I don't think it's enough to judge if it's fullscreen by comparing the window size to the screen size, since it doesn't work on MacBook with notch, or the menu bar is set to 'auto-hide'.
Thanks.
Topic:
Accessibility & Inclusion
SubTopic:
General
Tags:
Accessibility
Mac App Store
Core Graphics
App Sandbox
Hello, I want to access the Docker socket API from inside the macOS App Sandbox. The method queries the API using curl with --unix-socket. However, the Sandbox blocks the request, as shown by the log: curl(22299) deny(1) network-outbound /Users/user/.docker/run/docker.sock Outgoing network traffic is generally allowed, but access to the Docker Unix socket is denied.
Here’s the code I’m using:
private func executeDockerAPI() -> String {
let process = Process()
let pipe = Pipe()
process.executableURL = URL(fileURLWithPath: "/usr/bin/curl")
process.arguments = [
"--unix-socket", "/Users/user/.docker/run/docker.sock",
"http://127.0.0.1/containers/json"
]
process.standardOutput = pipe
process.standardError = pipe
do {
try process.run()
process.waitUntilExit()
let data = pipe.fileHandleForReading.readDataToEndOfFile()
if let output = String(data: data, encoding: .utf8) {
return output
} else {
return "Error while decoding"
}
} catch {
return "Error running command: \(error.localizedDescription)"
}
}
Is there any entitlement or sandbox configuration I’m missing to allow access to /Users/user/.docker/run/docker.sock from inside the sandbox?
This was working a few days ago, but it has since stopped and I can't figure out why. I've tried resetting TCC, double-checking my entitlements, restarting, deleting and rebuilding, and nothing works.
My app is a sandboxed macOS SwiftUI LSUIElement app that, when invoked, checks to see if the frontmost process is Terminal, then tries to get the frontmost window’s title.
func
getFrontmostWindowTitle()
throws
-> String?
{
let trusted = AXIsProcessTrusted()
print("getFrontmostWindowTitle AX trusted: \(trusted)")
guard let app = NSWorkspace.shared.frontmostApplication else { return nil }
let appElement = AXUIElementCreateApplication(app.processIdentifier)
var focusedWindow: AnyObject?
let status = AXUIElementCopyAttributeValue(appElement, kAXFocusedWindowAttribute as CFString, &focusedWindow)
guard
status == .success,
let window = focusedWindow
else
{
if status == .cannotComplete
{
throw Errors.needAccessibilityPermission
}
return nil
}
var title: AnyObject?
let titleStatus = AXUIElementCopyAttributeValue(window as! AXUIElement, kAXTitleAttribute as CFString, &title)
guard titleStatus == .success else { return nil }
return title as? String
}
I recently renamed the app, but the Bundle ID has not yet changed. I have com.apple.security.accessibility set to YES in the Entitlements file (although i had to add it manually), and a NSAccessibilityUsageDescription string set in Info.plist.
The first time I ran this, macOS nicely prompted for permission. Now it won't do that, even when I use AXIsProcessTrustedWithOptions() to try to force it.
If I use tccutil to reset accessibility and apple events, it still doesn't prompt. If I drag my app from the build products folder to System Settings, it gets added to the system TCC DB (not the user DB). It shows an auth value of 2 for my app:
% sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" "SELECT client,auth_value FROM access WHERE service='kTCCServiceAccessibility' OR service='kTCCServiceAppleEvents';"
com.latencyzero.<redacted>|2
<redactd>
I'm at a loss as to what went wrong. I proved out the concept earlier and it worked, and have since spent a lot of time enhancing and polishing the app, and now things aren't working and I'm starting to worry.