“sandbox”

Hi Joycity, thank you for your question! The ageRatingCode API should be used to observe changes to your app's age rating over time by comparing to its last known value. If your app's age rating code has changed, consider informing parents or guardians by using the Significant Change API. A value of 0 is expected during development of your app when it is built and run from Xcode and Sandbox environments (including TestFlight).

I've already added a reveal probe alongside the existing raw-read and open -g probes, using open -g -R , which goes through the same Finder-reveal service you described rather than opening the file's content. Unfortunately, I'm not sure this will work or not. While open -g -R does eventually call activateFileViewerSelectingURLs, what it actually does is: Perform its own existence checks (which could conceivably fail). Calls NSWorkspace.selectFile(_:inFileViewerRootedAtPath:), which does its own existence checks. ...and then calls activateFileViewerSelectingURLs. Depending on the process state, it's possible that 1 or 2 might fail, even though the Finder might actually still be able to access the file. What's different about activateFileViewerSelectingURLs itself is that it doesn't actually implement ANY checks, but just sends the input directly to the Finder. There's no Finder interaction anywhere in that path; a human isn't browsing these files. One minor clarification here. The Finder itself isn't necessar

Kevin, Thanks for the clarification on open vs. NSWorkspace.activateFileViewerSelectingURLs / Show in Finder — that's a useful distinction I hadn't considered (preflighting + the event-emission restrictions). I've already added a reveal probe alongside the existing raw-read and open -g probes, using open -g -R , which goes through the same Finder-reveal service you described rather than opening the file's content. It's wired into the same sentinel locations and fires on the next confirmed deny(1) cluster. One cluster hit today right after I deployed it, but the timing meant the new probe only got a clean result on the control location outside any mount (not denied, as expected) — no denial data on the mount points themselves yet. I'll follow up with real numbers once a few more clusters accumulate, same as the raw/open() data I posted last time. To answer your question directly — what do we actually need to work: the process driving most of this is a background daemon (launchd, no interactive session, no Term

Like Albert, I’m curious as to what you’re actual goal is here. Can you take a step back and explain more about the big picture here? Some random thoughts: You can’t distribute a command-line tool in the App Store, so you have the option of disabling App Sandbox. Is there a specific reason you need to enable it? It is possible to sandbox a command-line tool, but it’s quite unusual. It is possible for combine App Sandbox and running as root [1] but, again, it’s quite unusual. When you run a tool using sudo it ends up in a mixed execution environment. Trying to combine that with App Sandbox puts you fare off the beaten path. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] One place you see this is when you package a Network Extension as a sysex.

One more wrinkle worth flagging: for test_pi_root, the two probe methods disagreed at least once — at 2026-07-11 10:23, the raw open() call was denied but the open -g (LaunchServices) call succeeded. Unfortunately, after taking a closer look, open doesn't quite do the test I wanted. It basically works the way I described but it also preflight the paths it's given. There are also some tricky issues around exactly what event a process is allowed to emit, both of which mean open can end up failing even if the user/app target would be allowed to access the file. The better test here would be to see if the Finder by calling NSWorkspace.activateFileViewerSelectingURLs. That method actually works through the Show in Finder service (which you could also use instead), which means it avoids all sandbox/security issues. The Finder is directly given the path as a string, so all that matters is its own access restrictions. The control mount I set up specifically to test your workaround suggestion (relocate outsid

@TataChaitanya Thank you for your post. Is your question related to submitting a terminal application to the App Store? I believe but I have been wrong before, the App Sandbox is enforced at the kernel level. Even if you execute your application as root using sudo, the kernel will still enforce the sandbox restrictions. If your application requires sudo to access system files (such as /etc), read other users’ data, or bind to low ports, the sandbox should block these actions regardless of whether the application is running as root. If this is a standalone command-line tool intended to be run by administrators via sudo, simply do not enable the App Sandbox capability. Command-line tools are not required to be sandboxed unless they are being bundled within a sandboxed Mac App Store application. Additionally, please review the types of applications accepted at the store. Is this a Mac App? If your Swift application genuinely requires root privileges to functi

[quote='897181022, Reishandy, /thread/835400?answerId=897181022#897181022, /profile/Reishandy'] full output in the next comment [/quote] App Store install Executable=/Applications/YouriBeaconSimulator.app/Contents/MacOS/YouriBeaconSimulator [Dict] [Key] com.apple.application-identifier [Value] [String] 6H8PJSZGXA.id.reishandy.YouriBeaconSimulator [Key] com.apple.developer.aps-environment [Value] [String] production [Key] com.apple.developer.icloud-container-environment [Value] [String] Production [Key] com.apple.developer.icloud-container-identifiers [Value] [Array] [String] iCloud.id.reishandy.YouriBeaconSimulator [Key] com.apple.developer.icloud-services [Value] [Array] [String] CloudKit [Key] com.apple.developer.team-identifier [Value] [String] 6H8PJSZGXA [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.device.bluetooth [Value] [Bool] true [Key] com.apple.security.files.user-selected.read-only [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Boo