“sandbox”

[quote='896948022, DANgerous25, /thread/837008?answerId=896948022#896948022, /profile/DANgerous25'] it's an Xcode Debug build, so the executable only imports the debug-dylib stub [/quote] Oh, that’s an interesting wrinkle! [quote='896948022, DANgerous25, /thread/837008?answerId=896948022#896948022, /profile/DANgerous25'] if a child's own static import doesn't extend an inherited sandbox is something you'd consider a gap rather than intended behaviour [/quote] I can see arguments either way. But I think you should file a bug about it so that the sandbox engineering team can have a proper think about this case. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Well, I need more than a refresher course, since I've just been trying to understand how each piece of SwiftUI works when I come to it. I never been so stymied and angry at a language in all my 48 years of programming. Here's the relevant code. Comments say what works and what doesn't: @main struct SpeakotronikApp: App { @State public var contentView = ContentView(); @State var showFileImporter:Bool = false; var body:some Scene { WindowGroup { self.contentView .environment(langModel) } .commands { CommandGroup(after:.newItem) { Button(Import…) { self.showFileImporter = true; } .fileImporter(isPresented:$showFileImporter, allowedContentTypes:[.text], allowsMultipleSelection:false) { result in switch result { case .success(let urls): for url in urls { // Tell the content view to read the file and add new terms that will be translated: self.contentView.importTerms(url:url); } case .failure(let error): print(Error selecting file: (error.localizedDescription)); } } } } } } struct ContentView: View { @Environment(L

Thank you for the post. I have tried that API and I do not see any crash, however I’m very interested in seeing where it crashes for you. May I ask you to provide the Xcode you are using, macOS, iOS (simulator or physical device) as well as the focused sample code to reproduce it and the crash file? To view the version of Xcode, select Xcode > About Xcode. do { let response = try await AgeRangeService.shared.isEligibleForAgeFeatures // Handle response if response { logger.info(Eligible for age features.) } else { logger.info( Not eligible for age features.) } } catch { logger.error(Fail to check eligibility for age features.) } Sandbox https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox A focused Xcode project that builds and demonstrates the issue. Ideally this will be a new Xcode project created specifically to demonstrate this issue, and which includes only the minimal code and API necessary to reproduce the issue. This focuses on the important code path

Thanks for confirming. I had a look at the source of this failed integrity checks for container error and it’s not as complicated as I first thought. Moreover, each of the integrity checks that it runs has an accompanying log point, so you should be able to learn more from the system log. Try this: Run Console and start stream log entries. Reproduce the problem. Switch to Console and pause the log. Search the log for log entries from the secinitd process (past process:secinitd into the search field) where the Subsystem column is blank and the Category column says [1]. What do you see? For example, in my tests I did this: I created a sandboxed test app. I ran it. I quit it. I replaced its Data/Library/Images directory with a file (mwa ha ha!). % rm -r ~/Library/Containers/com.example.apple-samplecode.Test836638/Data/Library/Images % touch ~/Library/Containers/com.example.apple-samplecode.Test836638/Data/Library/Images I ran the app. It crashed, with the crash report saying: failed integrity checks fo

Thanks Quinn — your explanation of the framework-linkage trick was exactly the pointer we needed. To answer your question first: no, ShazamKit didn't appear in otool -L on that executable — it's an Xcode Debug build, so the executable only imports the debug-dylib stub, and ShazamKit is imported one hop down by that dylib. That prompted two more controls, and they solved it: Rebuilding the helper with a direct static ShazamKit import (confirmed via otool -L) and spawning it as an inherit child: still error 202, same shazamd deny. The child's own linkage doesn't matter. Linking ShazamKit into the parent executable instead (a tiny sandboxed fork/exec launcher, no exception anywhere): the unmodified inherit child now matches — including through two levels of nesting. So the sandbox extension appears to be derived from the profile owner's linkage and flows down to inherit children. That explains my app exactly: my main executable never linked ShazamKit (only the spawned helper does), hence the de

Have you tried setting shouldAllowToOpenInPlace to true? Unfortunately, the shouldAllowToOpenInPlace flag doesn’t help solving my issue. Setting that flag prevents the file from being copied by dragging it in Finder. Also, FileRepresentation doesn’t seem to be involved when passing a file URL to another app such as Safari. It appears that other representations need to be provided as well. For example, if I add ProxyRepresentation(exporting: .fileURL.absoluteString) afterward, I can drop the item onto Safari’s Dock icon. However, dropping it onto Safari’s address bar passes the URL of the sandbox container instead, and dropping it onto Safari’s content view does not interact with the page at all. struct FolderFindDraggedFile: Transferable, Identifiable { var fileURL: URL static var transferRepresentation: some TransferRepresentation { FileRepresentation(exportedContentType: .data) { item in SentTransferredFile(item.fileURL, allowAccessingOriginalFile: true) } .suggestedFileName(.fileURL.lastPathCompon

[quote='896837022, DANgerous25, /thread/837008?answerId=896837022#896837022, /profile/DANgerous25'] I ran a set of controls to answer your question [/quote] Nice! I’m not 100% sure why this is failing, but I want to explain a little bit about how App Sandbox works, so that you can understand why I’m asking my next question. When it comes to Mach service lookup, App Sandbox applies a clever trick to ensure that your app can only access its expected services. Let’s look at ShazamKit as example of this. Normally an app can’t access the com.apple.shazamd Mach service because the App Sandbox blocks such lookups by default. However, if the app links to the ShazamKit framework, App Sandbox extends its sandbox to allow that lookup. Your tests indicate that this extension isn’t working for a spawn subprocess. Before I send you off to file a bug, I’d like to confirm one thing. You wrote: [quote='896837022, DANgerous25, /thread/837008?answerId=896837022#896837022, /profile/DA

Seeing the same deny(1) mach-lookup com.apple.cloudd on a sandboxed Mac app (SwiftUI, CloudKit via the standard com.apple.developer.icloud-services/icloud-container-identifiers entitlements, not SwiftData). Environment: macOS 26.5.1, Xcode 26.5 — same as OP. What I've confirmed so far: codesign -d --entitlements - on the App Store–downloaded binary shows correct entitlements: icloud-container-identifiers, icloud-services: [CloudKit], icloud-container-environment: Production, matching App ID/container config in the Developer Portal. App ID in the portal has iCloud capability enabled with the correct container assigned (1 of 1 selected) — ruled out a portal-side misconfiguration. Reproduced independently on a second Mac (different machine, App Store install) with the same deny. One difference from the OP's report: in my case, a local Release-scheme build run via Xcode also gets denied, while the Debug-scheme build works fine. So the discriminator for me looks like Debug vs. Release configuration, not s

Our sandbox accounts don't work now, too. We are testing our IAP product now, so we needed our sandbox accounts to be logged in, for purchaise test. Settings -> Developer -> Sandbox Apple Account screen - > log in : Not working Logged out status -> test app -> purchasing IAP product : Not working our 4 members of dev team have same problem now.

Found it — and it's more than a timestamp coincidence. I extracted system_logs.logarchive from the sysdiagnose I already had (2026-07-05, attached to FB23576006) and searched for the StorageKit/SKManager signature around that timestamp. Your log line is there exactly as shown (10:52:14.292554+0200, PID 28562). But the line immediately preceding it, 16 microseconds earlier, same PID, is this: 10:52:14.292538 kernel: (Sandbox) System Policy: diskutil(28562) deny(1) file-read-data /Users/Shared/Stefan-Hem 10:52:14.292554 diskutil: (StorageKit) [SKManager _diskForPath:isNetworkMount:]: open() failed: errno=1 Same process, same microsecond, errno=1 = EPERM. This isn't a separate bug that r.171126338 introduced — it's diskutil's own StorageKit code logging the exact kernel Sandbox denial I've been reporting, at the moment diskutil itself got caught in a deny(1) window. So r.171126338 (whatever it changed) likely just added visibility into an open() call that was already going to fail — it didn't c

Thanks for the reply, Quinn — and good instinct: the helper turns out to be exactly the factor. I ran a set of controls to answer your question, and I have to correct my original post in the process. Same machine (macOS 26.1 / 25B78), same binary, same Apple Development signing: When the sandboxed app calls SHSession.match directly (entitlements: just com.apple.security.app-sandbox + com.apple.security.network.client — no exception, no ShazamKit-related entitlement at all), it matches successfully. No shazamd denial. So point 1 of my original post was wrong: a directly-sandboxed process can reach com.apple.shazamd out of the box. The same binary signed app-sandbox + com.apple.security.inherit and spawned as a child of that same sandboxed parent (parent has no exception) fails with error 202 (connection to com.apple.shazamd was invalidated). Same result one level deeper (parent → inherit child → inherit grandchild, which is my production shape). The same nested chai