“sandbox”

It seems like this is still an issue with Sandbox accounts, after release on the AppStore, does this work as expected or does the issue persist? Any updates would be appreciated.

I might have run in to the same problem, though I initially attributed it to the 27 beta of XCode / macOS (reported as FB23688931). (This was with mostly the default SwiftUI + SwiftData + CloudKit template app, though I added the iCloud capability and enabled CloudKit. The app came with the “App Sandbox” capability configured by default). After verifying the fix with the print(CKRecord.self) as suggested above, I worked around the issue by explicitly adding “CloudKit.framework” to the “Link Binary With Libraries” setting under “Build Phases” which also fixed the problem.

Xcode does not do this. A colleague of mine decoded the layers of base64 to eventually arrive at a shell script with a curl command that I won't post here, but it points to a HTTPS URL under the .in top-level domain. Is there a reason your project needs to curl to such a URL during the build? Do you have a history of the project, such as in git, that allows you to backtrack to the point in time where this script was added and why, or by whom or what tool? If additional information such as the Xcode version, macOS version, project sample, or diagnostic logs would help your investigation, I would be happy to provide them. This would be great — if you could zip up your Xcode project file (the .xcodeproj) and attach it to a bug report, I'd appreciate that, along with any other information you can share around the history of your project that lets you trace why this was added to your Xcode project. Please post the FB number back to this thread so I can locate it. One important note for script build phases is that

[quote='897883022, Reishandy, /thread/835400?answerId=897883022#897883022, /profile/Reishandy'] That was it. [/quote] Yay! [quote='897883022, Reishandy, /thread/835400?answerId=897883022#897883022, /profile/Reishandy'] Disabling Enable Debug Dylib Support alone did not fix it [/quote] OK. Thanks for confirm that. After I wrote that response yesterday I dug into how App Sandbox actually learns about the libraries you’re seeing, and my conclusion that the debug dylib thing wouldn’t .debug.dylib wouldn’t affect things, so I’m glad that my theory aligns with your reality (-: [quote='897883022, Reishandy, /thread/835400?answerId=897883022#897883022, /profile/Reishandy'] Debug worked the whole time for probably an unrelated reason. [/quote] Yeah, that’s the only bit I don’t fully understand here. [quote='897883022, Reishandy, /thread/835400?answerId=897883022#897883022, /profile/Reishandy'] would it be worth filing this as a separate, more targeted bug … against the CoreData+CloudKit/App Sandbox i

Oh wow, thank you @DTS Engineer ! That was it. Disabling Enable Debug Dylib Support alone did not fix it, the standalone Release launch still denied. But adding an explicit CloudKit symbol reference did: import CloudKit @main struct YouriBeaconSimulatorApp: App { init() { print(CKRecord.self) } ... } After that, no more deny(1) mach-lookup com.apple.cloudd. Just confirmed it also resolves the issue on an External Distribution build, not just local Release runs. That explains the whole pattern I was seeing. I'm using NSPersistentCloudKitContainer (CoreData+CloudKit), so my code never references any CloudKit symbol directly, CoreData talks to CloudKit dynamically under the hood. With whole-module optimization in Release, the linker had no reason to add a CloudKit.framework load command, since nothing in my source named a CloudKit type. App Sandbox's framework scan never saw CloudKit linked, so it never granted the cloudd exception. Debug worked the whole time for probably an unrelated reason. Enable De

Please make sure you are following instructions in https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox#Sign-in-to-your-Sandbox-Apple-Account-for-a-TestFlight-app If you are and this is still reproducible then please file a feedback assistant with a sysdiagnose and screen recording.

 How to File Feedback assistant ticket? https://feedbackassistant.apple.com/ Login with your developer account, Choose iOS & iPadOS” Choose AppStore “Incorrect & Unexpected behavior Input the issue description and title. Upload attachments Click “Submit” Copy the Ticket ID “FBxxxxxxx” and let us know. To capture a system diagnose log. https://developer.apple.com/bug-reporting/profiles-and-logs/?platform=ios

Those are some interesting results you’ve got there! Still, I’m pretty sure linking is part of the story. I just looked at how App Sandbox mediates access to the com.apple.cloudd Mach service and it’s definitely based on the presence of the CloudKit framework. I’m gonna ask you to run two tests. The first is super easy: Disable the Enable Debug Dylib Support build setting for your target. Does that fix the ‘running outside of Xcode’ case? If that doesn’t fix it, add an explicit link to a CloudKit symbol. If you’re using SwiftUI for your app’s main, you can write this: import SwiftUI import CloudKit @main struct MyApp: App { init() { print(CKRecord.self) } … } If you’re using AppKit, just add the same print(…) call to main or your applicationDidFinishLaunching(_:) method (if you’re using @main). You should then see in the imported library list: % otool -L MyApp.app/Contents/MacOS/MyApp MyApp.app/Contents/MacOS/MyApp: … /System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit … … Does that hel

Hi @tanakaworld-mercari, You wrote: What does PassKit's second Evaluating merchant session using PROD trust policy check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? They are not the same check run twice for redundancy — they're two different stages of PassKit's merchant-session trust verification: 1st occurrence (at completeMerchantValidation) validates the merchant session payload itself — this is a structural/signature check. 2nd occurrence (right before PrepareTransactionDetails) happens once PassKit has a selected payment method (a specific card/token) and is about to actually prepare the transaction for authorization. This is where an environment mismatch (sandbox tester card vs. a payment-processing certificate that was issued for production) would surface. So, the first check validates the envelope, the second validates whether that envelope's certificate can actually be used for this card's environment.

I built a small shortcut with a Run AppleScript action that runs do JavaScript on the front Safari tab. On macOS 26.5.1 with Safari 26.5, I can both reproduce your error and clear it. With Allow JavaScript from Apple Events turned off I get the same message you quote. With it turned on, the script returns its result. So that message is Safari's gate for running JavaScript through Apple Events, which is the path a Run AppleScript action's do JavaScript takes. Since you have enabled that setting and still see the error, two things are worth checking: That the setting has actually taken effect. On Tahoe it lives in Settings > Developer. After you enable it, fully quit and relaunch Safari so the change takes hold, and confirm you enabled it in Safari itself rather than Safari Technology Preview. Automation permission for the app that runs the script. For a shortcut with a Run AppleScript action, that app is Shortcuts. Open System Settings > Privacy & Security > Automation, find Shortcuts, and turn on