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.

I'm seeing a recurring issue on macOS 26.5.2 (build 25F84) where the kernel's Sandbox/System Policy layer intermittently denies file access on NFS mount points from local network servers. Posting here in case anyone recognizes this pattern or has a workaround, and flagging it since I've also filed a Feedback Assistant report (with a live-captured sysdiagnose) for the same issue. WHAT HAPPENS Two independent NFS mounts to two separate, unrelated servers on my LAN start failing simultaneously with "Operation not permitted." The kernel log shows: kernel: (Sandbox) System Policy: mount_nfs(PID) deny(1) file-mount /path/to/mount Critically, it's not limited to the mount syscall - within the same few-second window, System Policy also denies ls, perl, diskutil, and even umount -f on the exact same path, for otherwise unrelated processes. So it looks like a transient, path-scoped kernel decision rather than something specific to NFS or the mount syscall. It self-heals anywhere from seconds to ~30 minutes later, then recurs - documented 30-80+ occurrences/day via a background watchdog script. WHAT I'VE RULED OUT Server-side cause: two independent servers on different hardware fail identically at the same instant. Network issue: checked network logs in the same window, no correlated connectivity event. Third-party kext conflict: kextstat shows zero third-party kexts loaded. syspolicyd database corruption: no "ASP: Validation category" signature present. TCC/Full Disk Access: already granted; the denying layer is kernel Sandbox "System Policy," not TCC. QUESTION Has anyone else run into System Policy denying file-mount/file-read-data/file-unmount on network volume paths intermittently like this? Is there any userland way to inspect or reset whatever internal state drives this decision (I haven't found one - no spctl/tccutil/sysctl lever that touches it)? Happy to share more log excerpts if useful.

A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal. Environment macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container. Actual Result Console shows repeated kernel sandbox denials followed by CloudKit setup failure: kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon." Key Diagnostic Finding When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds: cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary: codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true Conclusion The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.

Hi Team, If I want to create a command line app in swift which needs to be invoked using sudo, will I be able to sandbox this app?

I'm building a music-recognition app for the Mac App Store that uses ShazamKit (SHSession / SHManagedSession) against the default Shazam catalog. In a sandboxed build, SHSession.match(_:) fails with: com.apple.ShazamKit error 202 — "The connection to service named com.apple.shazamd was invalidated" The root cause is a sandbox denial of the mach-lookup to the ShazamKit matching daemon: kernel (Sandbox): deny(1) mach-lookup com.apple.shazamd What I've established: Enabling the ShazamKit App Service on the App ID does not add com.apple.shazamd to the sandbox mach-lookup allow-list on macOS — the denial persists and matching returns error 202. The iOS entitlement com.apple.developer.shazamkit is rejected by the macOS validator at upload ("not supported on macOS"), so it isn't an option here. Adding com.apple.security.temporary-exception.mach-lookup.global-name = [com.apple.shazamd] to the app's entitlements removes the denial, and ShazamKit then matches correctly under the sandbox (verified end-to-end: real api.shazam.apple.com/v1/catalog/.../match requests complete and tracks are identified). Removing that exception reproduces error 202 on every probe. So the temporary-exception appears to be the only way to make ShazamKit's default-catalog matching work inside the macOS App Sandbox today. Questions: Is there a sanctioned, non-temporary-exception way to use ShazamKit default-catalog matching in a sandboxed macOS app (a proper entitlement, an App Service configuration, or a supported API usage)? If not, is the com.apple.shazamd mach-lookup temporary-exception the intended approach on macOS? My actual SHSession.match runs in a nested helper that inherits the app's sandbox (com.apple.security.inherit). Is it correct to place the exception on the main app (which the inherited helper then picks up), rather than on the helper itself? Environment: macOS 26.1, ShazamKit App Service enabled on the App ID, signed App Sandbox build installed via TestFlight (valid _MASReceipt present). Happy to share entitlement plists and a focused sample on request. Thanks!

I'm dragging existing files from a SwiftUI List (a search result list in a sandboxed, document-based Mac app), and I want drop targets to receive the actual file URL — the same behavior as AppKit's NSOutlineView with outlineView(_:pasteboardWriterForItem:) returning an NSURL: the Finder copies the file, browsers load it, and text views insert its path. My current implementation is Transferable-based: FileRepresentation(exportedContentType: .data) { item in SentTransferredFile(item.fileURL, allowAccessingOriginalFile: true) } .suggestedFileName(\.fileURL.lastPathComponent) With this, what receivers get is a temporary copy in the app's own container (Caches/com.apple.SwiftUI.Drag-<UUID>/), not the actual file URL — despite allowAccessingOriginalFile: true. Dropping on the Finder or onto an application icon works through the copy, but receivers that interpret the URL itself — a browser window, or a text view that inserts the dropped file's path — see the temporary container path. Note that the dragged files live inside a folder the user has opened as a document (the app is NSDocument-based), so the app already holds security-scoped access to them. Alternatives don't help either: DataRepresentation(exportedContentType: .fileURL) returning the URL bytes of the actual file: the pasteboard data is likewise replaced with the copy's URL, and moreover, drops onto application icons (e.g. Safari in the Dock) are no longer accepted at all. onDrag with NSItemProvider(object: url as NSURL): same substitution. I've already filed this as FB23578716, with detailed reproduction steps and drag-pasteboard dumps. My questions: Is there any way in current SwiftUI (macOS 26/27 SDK) to put the real file URL of an existing file on the drag pasteboard? Is the rewriting to a temporary copy intended behavior (for sandbox safety), or a bug? If it's intended, is embedding an AppKit view that calls beginDraggingSession(with:event:source:) with an NSURL pasteboard writer the recommended workaround for now? It does write the real URL, but making it coexist with List's selection and click handling has proven fragile. Environment: macOS: macOS 27 Beta 2 / Version 26.5.2 Xcode: Version 27.0 Beta 2 App Sandbox enabled

After updating the application following an upgrade from a previous macOS version to macOS Tahoe 26.5.1 (25F80), the sandboxed app immediately crashes on launch. The crash occurs during dyld library initialization, before any application code (including main()) is executed. The crash report identifies that libsystem_secinit.dylib rejects the existing app sandbox container with the following signature: "failed integrity checks for container at /Users/apptest/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data: Invalid argumen" Clearing out the old sandbox container data (e.g., rm -rf ~/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data) resolves the crash. Please help analyze the possible causes of this issue: 1.Could this be a compatibility issue between the new macOS 26.5.1 system and Mac Catalyst apps? 2.Could this be caused by certain APIs used by the app or specific project configuration settings? If so, please provide some relevant hints to help narrow down the scope of analysis. Crash Log excerpt.txt

I have a sandboxed Mac App Store app that uses Apple’s MultipeerConnectivity framework for a local peer-to-peer “mesh” feature. The app advertises itself as a nearby peer and accepts inbound invitations from other nearby devices so users can do local collaboration, chat, shared workspace sync, and multiplayer game sessions. This is local peer-to-peer only; the app is not running a public web server, FTP server, or similar service. When I remove the App Sandbox Incoming Connections entitlement: com.apple.security.network.server nearby peer discovery / inbound connections stop working in the sandboxed Mac build. Is com.apple.security.network.server the correct entitlement for this MultipeerConnectivity use case on macOS, assuming the app clearly exposes this local peer-to-peer feature in the UI?

I'm trying to submit a macOS window manager app to the Mac App Store. The app uses the Accessibility API (AXUIElement) to read and write window positions, which requires the user to grant Accessibility permission in System Settings. My submission is being rejected by the automated checker with error 90296: "App sandbox not enabled." If we enable App sandbox then the app does not work at all. However, I can see at least one currently-shipping Mac App Store app in the same category (window management) that does not have the com.apple.security.app-sandbox entitlement set to true, yet it was clearly approved and continues to receive updates built with current versions of Xcode. The AXUIElement write API (AXUIElementSetAttributeValue) does not function correctly within the App Sandbox, even when the user has granted Accessibility permission. This makes the sandbox requirement incompatible with the core functionality of window manager apps. My questions: Is there an entitlement or exception available for apps that require Accessibility API write access? Is there a way to request a sandbox exemption for this category of app? I cant even upload it. Is the existing app on the store grandfathered, and if so, how do new window manager apps get approved? Any guidance appreciated. Thanks

My app is sandboxed and for one feature listens for an incoming connection on a user selected port. When the firewall is enabled and block incoming (all, this app, or signed apps) is enabled, I want to be able to not offer this feature with a brief explanation. I tried using /usr/libexec/ApplicationFirewall/socketfilterfw but that fails when used in a sandboxed app. I have an XPC module, which is also sandboxed, and the call fails there as well. If I remove the sandbox from the XPC then the call succeeds but then is unable to communicate with the main app. Is there an API to determine if the firewall is enabled and all connections blocked? I've submitted a Feedback request (FB23378402) as well.

Hello, What are the restrictions on submitting apps to the mac App Store that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt and manipulate TLS traffic? To be more specific, I'm not talking about a Safari extension. I'm talking about system-wide traffic. So that the app can detect and block ads and trackers from all apps, not just Safari. I'm aware that such an app can be distributed using an unsandboxed Developer-ID signed app. But I wonder if such an app also breaks Sandbox requirements for AppStore distributed apps? Also, is there a way for a sandboxed app to install and trust a root CA? SecTrustSettingsSetTrustSettings does not work in Sandboxed apps from what I found. Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-ditributed apps? Is doing any of these things possible on AppStore-distributed apps? Thanks in advance for your reply.

Are there specific Entitlements (com.apple.security.temporary-exception.files.absolute-path.read-write or network exceptions) required to allow App Intents to talk to local UNIX sockets or loopback interfaces (127.0.0.1) without triggering sandbox violations?

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.

Hi there, I have an SwiftUI app that opens a user selected audio file (wave). For each audio file an additional file exists containing events that were extracted from the audio file. This additional file has the same filename and uses the extension bcCalls. I load the audio file using FileImporter view modifier and within access the audio file with a security scoped bookmark. That works well. After loading the audio I create a CallsSidecar NSFilePresenter with the url of the audio file. I make the presenter known to the NSFileCoordinator and upon this add it to the FileCoordinator. This fails with NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for; Error Domain=NSPOSIXErrorDomain Code=3 "No such process" My Info.plist contains an entry for the document with NSIsRelatedItemType set to YES I am using this kind of FilePresenter code in various live apps developed some years ago. Now when starting from scratch on a fresh macOS26 system with most current Xcode I do not manage to get it running. Any ideas welcome! Here is the code: struct ContentView: View { @State private var sonaImg: CGImage? @State private var calls: Array<CallMeasurements> = Array() @State private var soundContainer: BatSoundContainer? @State private var importPresented: Bool = false var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") if self.sonaImg != nil { Image(self.sonaImg!, scale: 1.0, orientation: .left, label: Text("Sonagram")) } if !(self.calls.isEmpty) { List(calls) {aCall in Text("\(aCall.callNumber)") } } Button("Load sound file") { importPresented.toggle() } } .fileImporter(isPresented: $importPresented, allowedContentTypes: [.audio, UTType(filenameExtension: "raw")!], onCompletion: { result in switch result { case .success(let url): let gotAccess = url.startAccessingSecurityScopedResource() if !gotAccess { return } if let soundContainer = try? BatSoundContainer(with: url) { self.soundContainer = soundContainer self.sonaImg = soundContainer.overviewSonagram(expectedWidth: 800) let callsSidecar = CallsSidecar(withSoundURL: url) let data = callsSidecar.readData() print(data) } url.stopAccessingSecurityScopedResource() case .failure(let error): // handle error print(error) } }) .padding() } } The file presenter according to the WWDC 19 example: class CallsSidecar: NSObject, NSFilePresenter { lazy var presentedItemOperationQueue = OperationQueue.main var primaryPresentedItemURL: URL? var presentedItemURL: URL? init(withSoundURL audioURL: URL) { primaryPresentedItemURL = audioURL presentedItemURL = audioURL.deletingPathExtension().appendingPathExtension("bcCalls") } func readData() -> Data? { var data: Data? var error: NSError? NSFileCoordinator.addFilePresenter(self) let coordinator = NSFileCoordinator.init(filePresenter: self) NSFileCoordinator.addFilePresenter(self) coordinator.coordinate(readingItemAt: presentedItemURL!, options: [], error: &error) { url in data = try! Data.init(contentsOf: url) } return data } } And from Info.plist <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeExtensions</key> <array> <string>bcCalls</string> </array> <key>CFBundleTypeName</key> <string>bcCalls document</string> <key>CFBundleTypeRole</key> <string>None</string> <key>LSHandlerRank</key> <string>Alternate</string> <key>LSItemContentTypes</key> <array> <string>com.apple.property-list</string> </array> <key>LSTypeIsPackage</key> <false/> <key>NSIsRelatedItemType</key> <true/> </dict> <dict> <key>CFBundleTypeExtensions</key> <array> <string>wav</string> <string>wave</string> </array> <key>CFBundleTypeName</key> <string>Windows wave</string> <key>CFBundleTypeRole</key> <string>Editor</string> <key>LSHandlerRank</key> <string>Alternate</string> <key>LSItemContentTypes</key> <array> <string>com.microsoft.waveform-audio</string> </array> <key>LSTypeIsPackage</key> <integer>0</integer> <key>NSDocumentClass</key> <string></string> </dict> </array> Note that BatSoundContainer is a custom class for loading audio of various undocumented formats as well as wave, Flac etc. and this is working well displaying a sonogram of the audio. Thx, Volker

I'm developing a sandboxed clipboard history manager for macOS. When a user selects an item from their clipboard history, the app: Writes the data to NSPasteboard.general Posts a ⌘V keystroke via CGEvent.post(tap: .cgSessionEventTap) This requires the user to grant permission under System Settings > Privacy & Security > Accessibility (kTCCServicePostEvent). The app does not use any Accessibility framework APIs (AXUIElement, AXIsProcessTrusted, etc.) — only Core Graphics event posting. The app has been rejected twice under Guideline 2.4.5, with the reviewer stating that Accessibility features should not be used for non-accessibility purposes. My understanding is that kTCCServicePostEvent (used by CGEvent.post) is a separate TCC service from kTCCServiceAccessibility (used by AXUIElement APIs), but both appear under "Accessibility" in System Settings, which may be causing confusion. My questions: Is there an approved way for a sandboxed Mac App Store app to simulate a keystroke (specifically ⌘V) after writing to the pasteboard? If CGEvent.post is not appropriate for App Store apps, what alternative API should clipboard managers use to provide a "paste" action? Is there a way to use CGEvent.post that is compliant with Guideline 2.4.5? I have a minimal sample project (single Swift file, sandboxed) that demonstrates the behavior. I can share it if helpful. I was referred here by DTS (Case-ID: 19088416).

I first started observing this behaviour through the crash logs of one of my App Store apps which are downloaded by Xcode. Then 3 days ago the same crash happened when launching one of my other apps on my own Mac. On the next try, the app launched correctly. The crash logs don't show any of my app's symbols, only a single thread that does something with libsecinit. I have no idea what the problem is, and since these crashes are also downloaded by Xcode, one would get the impression it’s a fault in my programming… but without any hint as to what I’m doing wrong, I have no chance to fix it, and so I get the feeling that it’s actually a macOS bug. I created FB22712334. crash

Hello, I am experiencing a specific authorization error on macOS Tahoe when trying to discover all available service types on the local network. While the implementation works perfectly on iOS and macOS Sonoma, it fails on Tahoe with a specific error code. The Issue When calling DNSServiceBrowse with the meta-query string _services._dns-sd._udp, the function immediately returns kDNSServiceErr_NoAuth (-65555). // This call fails on macOS Tahoe DNSServiceErrorType err = DNSServiceBrowse( &ref, 0, kDNSServiceInterfaceIndexAny, "_services._dns-sd._udp", // Meta-query for all services domc, probe_browse_reply, (__bridge void *)self ); Important Findings & Observations Specific Services Work: If I change the service type to a specific one (e.g., _http._tcp or _ssh._tcp) using NWBrowser, it works correctly and returns results. The error only occurs when browsing for _services._dns-sd._udp using DNSServiceBrowse. Local Network Permission: I have confirmed that the Local Network toggle is ON for my app in System Settings > Privacy & Security > Local Network. Entitlements: My app has the com.apple.developer.networking.multicast entitlement. Info.plist: Both NSLocalNetworkUsageDescription and NSBonjourServices (including _services._dns-sd._udp) are properly configured. Sandbox: The issue persists regardless of whether the App Sandbox is enabled (with incoming/outgoing connections) or disabled. Environment Not Working OS: macOS Tahoe 26 Working OS: macOS Sonoma, iOS 26 Question It seems macOS Tahoe has introduced a stricter policy regarding Network Reconnaissance or meta-service browsing. Is there a new requirement or a specific entitlement needed in macOS Tahoe to browse for _services._dns-sd._udp? Any guidance on how to restore this functionality for network utility apps on macOS Tahoe would be greatly appreciated. Best regards.

Starting somewhere around macOS 26.3, my sandboxed file manager spontaneously loses access to ~/Library/Mobile Documents mid-session. Setup: at launch, the user grants access to '/', '/Users', or '~' via NSOpenPanel; I store a security-scoped bookmark and call startAccessingSecurityScopedResource(). This works fine - including iCloud Drive - until some point mid-session. When it breaks, two things happen simultaneously: Enumeration fails: NSCocoaErrorDomain Code=257 (NSFileReadNoPermissionError)< NSPOSIXErrorDomain Code=1 (EPERM) Console shows the kernel refusing extension issuance: couldn't issue sandbox extension com.apple.app-sandbox.read for '/Users//Library/Mobile Documents': Operation not permitted And probing NSFileProviderManager confirms the process has been rejected system-wide: NSFileProviderManager.getDomainsWithCompletionHandler > NSFileProviderErrorDomain Code=-2001 "The application cannot be used right now." (underlying Code=-2014) What makes this specific to FP-backed paths: regular paths under the same '/' bookmark (~/Library/Application Support, etc.) stay accessible and recover normally with a fresh startAccessingSecurityScopedResource() call. Only ~/Library/Mobile Documents and its subtree fail - the entire tree, including the parent directory itself. Relaunch always restores access. What I've tried and ruled out: Re-resolving the bookmark + startAccessingSecurityScopedResource() - returns stale=false, granted=true but access is not restored; the kernel still refuses extension issuance for FP-traversing paths. NSFileCoordinator coordinated read - doesn't help; the coordinator depends on the same sandbox extension the kernel is refusing. Instantiating NSFileProviderManager(for: domain) per domain - fails with -2001 for every domain, confirming the rejection is process-wide, not path- or domain-specific. My working theory: when a FileProvider daemon (bird/cloudd/fileproviderd) restarts mid-session, the process's FP-client XPC registration is invalidated, and the kernel subsequently refuses to issue sandbox extensions for any path served by FP - even with a valid bookmark. The process seems to have no API path to re-register its FP-client identity without relaunching. Current workaround: I detect the -2001 response and prompt the user to relaunch, then do a programmatic self-relaunch if they confirm (which is obviously horribly intrusive). Questions: Is there an API that lets a sandboxed consumer app reconnect its FP-client identity mid-session, short of relaunching? Is there an entitlement or capability that would make the kernel's extension issuance resilient to FP daemon restarts? Has anyone else hit this on 26.x and found a workaround? Filed as FB22547671.

I have this code in my Virutalization application let process = Process() process.executableURL = URL(fileURLWithPath: "/usr/sbin/diskutil") process.arguments = ["image", "create", "blank", "--fs", "none", "--format", "ASIF", "--size", "2GiB", url.path ] try process.run() process.waitUntilExit() if process.terminationStatus == 0 { print("✅ Disk image creation succeeded.") } else { print("❌ Disk image creation failed with exit code \(process.terminationStatus)") } } catch { print("Process failed to launch: \(error.localizedDescription)") return } this code was working fine until Tahoe 26.2. with the update of 26.3 the system freezes at process.waitUntilExit() The code never exits and i get beech balls. This is working fine with intel macs. i am getting the problem in apple silicon m4 mac mini. Any help would be appreciated.

We're developing a Mac App Store application that embeds the V8 JavaScript engine (via Electron). The application has shipped successfully on macOS 15.x with the following entitlements: com.apple.security.app-sandbox = true com.apple.security.cs.allow-jit = true com.apple.security.cs.allow-unsigned-executable-memory = true com.apple.security.cs.disable-library-validation = true On macOS 26 Tahoe, the exact same signed binary crashes deterministically within ~1.5 seconds on Apple Silicon with EXC_BREAKPOINT (SIGTRAP), ESR 0xf2000000. The crash is in V8's background JIT compilation thread when it attempts to manage memory page protections (transitioning pages between Read-Write and Read-Execute states via mprotect). The crash does not occur in these configurations: macOS 26 + App Sandbox + Intel x86_64 — works macOS 26 + Hardened Runtime (no sandbox) + ARM64 — works macOS 15.x + App Sandbox + ARM64 — works This appears to be a regression in how the XNU kernel handles mprotect calls for sandboxed processes on ARM64 under macOS 26, specifically in the context of the allow-jit entitlement. Has the behavior of allow-jit changed in macOS 26 with respect to runtime code generation memory management on ARM64? Is there a new API or entitlement that V8-style JIT engines should use instead of mprotect-based RW↔RX page transitions?

These days I've observed a strange behavior in my document-based app on macOS: Its NSDocument class implementation is overwriting "saveToURL:ofType:forSaveOperation:completionHandler:", performing some additional checks and calling super by passing the original parameters. As my app is supporting various file formats for writing (and exporting those UTIs) the user can open a file in one format and save it to another. NSDocument is calling the mentioned methods implicitly after completing the "Save as..." dialog. If this happens, the passed-on fileType is still the one of format #1, although the file is saved with the file name extension of format #2. This hick-up is not directly obvious to the user. But if the file is re-saved (e.g. after modifications), Cocoa is trying to extend the sandbox for the URL of type #1, and fails with the following error message at the Xcode console: -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process" -[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef I'm currently fixing this issue by determining the UTType for the new file name extension and passing it to super. Unfortunately I have no idea how long this issue was already present, and cannot replicate it with a sample app based on Apple's Xcode 26 template (too many differences to my >15 years old app) - so I won't file a bug report. Take this post just for information in case someone else is facing a similar situation...