“sandbox”

At a technical level, I don’t see anything that stops you doing this. If you enable the hardened runtime (which you should :-), you’ll need to disable library validation because the plug-in won’t be signed by you. You’ll also need to dynamic extend your sandbox to allow access to the bundle, including its main executable. Typically you do that using the open panel, and persist that access using a security-scoped bookmark. After that, use your dynamic loading API of choice (NSBundle, CFBundle, dlopen) to load the bundle’s executable and call code in it. I prototyped this here in my office and it worked a treat. I’ve pasted in some code below. I tested this with Xcode 26.6 on macOS 26.6.1, but I don’t think this story has changed since the very early days of the App Sandbox. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com This is the code within my bundle: @c func entryPoint() { print(Hello Cruel World!) } Note It uses @c, as

[quote='845522021, DredChed, /thread/845522, /profile/DredChed'] Is there a supported public API … that allows a sandboxed macOS app to read the built-in ambient light sensor in real time? [/quote] No. AFAIK sandboxing isn’t a factor here; a non-sandboxed app would have the same problem. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Update — confirmed with additional diagnostics Since posting, we added temporary diagnostic logging to the app and reproduced the issue on the affected device. Sharing the findings in case they help others hitting the same problem, and to add data for Apple's investigation: Both the legacy API and StoreKit 2 return the same wrong value We logged SKPaymentQueue.default().storefront (StoreKit 1) and await Storefront.current (StoreKit 2) side by side, at the same point in the app, on the same TestFlight build/session: StoreKit 1: countryCode = USA, identifier = 143462 StoreKit 2: countryCode = USA, identifier = 143462 So this is not limited to the deprecated API — Storefront.current shows the identical wrong result on the affected device. The storefront identifier is correct; only countryCode is wrong 143462 is Apple's storefront identifier for Japan (JP) — and it matches exactly what a normal, unaffected device on the same build reports. So the storefront the device is actually associated with is correctly Japa

Resolved — the root cause was on our side: we were discarding event.validationURL. Thank you, the two-stage description was what made this findable. Posting the resolution in case it helps someone who lands here with sessionError.code: unknown. What was wrong Our onvalidatemerchant handler ignored the event argument entirely and asked our own backend for a merchant session using only the domain name: session.onvalidatemerchant = async () => { const merchantSession = await validateMerchant(); // event.validationURL dropped session.completeMerchantValidation(merchantSession); }; The backend then requested that session from a hardcoded production host: POST https://apple-pay-gateway.apple.com/paymentservices/paymentSession Signed in with a Sandbox Tester account, Safari was handing us a different URL — https://apple-pay-gateway-cert.apple.com/paymentservices/startSession. By overriding it with the production host, we were requesting a production-trust session for a sandbox DAN. The fix Use t

https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox This is the official documentation that helped me. Follow these steps to access sandbox controls for TestFlight in iOS: Download your beta app from TestFlight. You need to be signed in with a production Apple Account to download a beta app. For more information, see TestFlight Overview. Open Settings and select your Apple Account. Select Media & Purchases. On the pop-up menu, select Sign Out. Next, open Settings and select Developer. (This option is available when you enable Developer Mode). Scroll to the bottom of the screen, and select Sign In under Sandbox Apple Account. Enter your Sandbox Apple Account credentials.

Clearing purchase history resets intro offer eligibility. https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox#Clear-the-purchase-history-for-a-Sandbox-Apple-Account Please file a feedback assistant with a sysdiagnose and screen recording.

 Also please add the notification payload to the ticket. Thank you 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

Sign in with Apple — ASAuthorizationError 1001 immediately after sheet, same AKSQLError -6003 pattern as other threads Adding our case to this thread, matches the pattern already confirmed for other teams here (e.g. GW7XA5CX69, FRL3DTJQ62). App / Team info: Bundle ID: de.schonwiedernudelnapp.iosApp Team ID: 7JX3TW8R6B Sign In with Apple capability: enabled on the App ID (APPLE_ID_AUTH), configured as Primary (APPLE_ID_AUTH_APP_CONSENT → PRIMARY_APP_CONSENT), confirmed via the App Store Connect API. Distribution provisioning profile carries com.apple.developer.applesignin = [Default] and aps-environment = production (verified via codesign -d --entitlements). Entitlements file (iosApp.entitlements) correctly embedded in the signed build. Symptom: Native ASAuthorizationController flow (Sign In with Apple button in our app). The system sheet appears correctly, user authenticates with Face ID successfully. Sheet then dismisses with Sign Up Not Completed, and our app receives: com.apple.AuthenticationServices.Autho