“sandbox”

We test Apple Pay in the sandbox on supervised iPhones in a device lab (Apple Configurator supervision, no MDM enrollment, no SIM, iOS 26.x). Since late September two of the test cards from the Sandbox Testing page no longer add to Wallet. Discover test cards still add fine on the same devices and accounts. Filed as FB24994276 (Visa) and FB24994258 (Mastercard), with device logs and timestamps. Visa 4622 9431 2318 9285 (FB24994276), only on our lab devices: eligibility → 412 → TSM sync → 200, received eligibility status: 1 terms shown and accepted provision → HTTP 403 → PKProvisioningErrorDomain Code=3 → Invalid Card Same result on two different lab iPhones, including one signed in to a brand-new sandbox account. The same new account and the same card add successfully on an unsupervised iPhone on a home network (iOS 18.2.1). Neither side sends location data. Mastercard 5204 2452 5046 0049 (FB24994258), on every device we tried, lab and home, iOS 18.2.1 and 26.x: eligibility → 412 →

App Store Server API: Sandbox returns 200, Production returns 401 with the same JWT We are seeing a reproducible authentication issue with the App Store Server API for our app FYRT. Bundle ID: com.fyrt.Fyrt We performed a fresh read-only test on September 29, 2026 using our In-App Purchase key BJ5HR5GSY6. Both requests used: the same In-App Purchase key the same Issuer ID the same Bundle ID ES256 the same JWT structure 300-second token lifetime correct system time with no relevant clock skew Only the environment changed. Sandbox: HTTP 200 Apple Request ID: 458b3b32-8e0d-1404-19fe-6c92ba2ccd27 Production: HTTP 401 Apple Request ID: 193406ac-80d2-d135-8cc8-34e4ebe76fc5 The Production response does not include an additional Apple error code. The request is read-only and requests notification history. No purchase is triggered and no Production data is changed. We verified: correct Key ID correct Issuer ID correct Bundle ID ES256 signing current iat valid exp correct Sandbox and Producti

Short version: we run a sandboxed helper as a hidden service account, started at boot by an SMAppService daemon. It works, even before login. But when the user turns our app off in Background App Activity, only the daemon stops. The helper keeps running. Is this setup supported, and what's the right way to manage the helper? What we want A Developer ID signed, notarized app (not Mac App Store) with a helper that parses untrusted input. The helper should: run as a dedicated, hidden, non-login local account; use App Sandbox, with its own container; be available before anyone logs in (after FileVault unlock). What we built An unsandboxed root LaunchDaemon, registered with SMAppService.daemon, runs this at boot: launchctl bootstrap user/ The agent plist uses LimitLoadToSessionType=Background. The helper is a nested app in the same bundle, with com.apple.security.app-sandbox=true. We don't create a GUI session, change UID after the sandbox starts, or use private APIs. What we m

Update: I clarified the intended behavior after posting. The destination is the text input that has keyboard focus when the finished dictation is delivered, even if the user changed fields or apps while speaking. We do not need to return to the field where dictation started. I’m building a macOS dictation app for the Mac App Store, so it must run with App Sandbox enabled. For example, a user might start dictating with an input in Chrome focused, then click into a ChatGPT input while speaking. When the result is ready, it should insert at the ChatGPT caret. Moving the caret within one app should likewise change the destination. In an isolated signed sandboxed prototype, I write a marker to the general pasteboard and post Command–V with CGEvent.post after the user grants event-posting access. This inserts successfully in TextEdit at the current caret, including after a same-document caret move. That result is now consistent with the intended behavior. The prototype also has a frontmost-process

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a Restore Purchase or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank

Hello, I would like to clarify the best practices and timing for our backend server to transition its main connection to the production App Store Server API. Currently, we are considering the following approach: We plan to switch our backend’s primary API endpoint from Sandbox to Production once our app passes the App Store review and its status changes to Ready for Sale. Could you please confirm if this timing is standard and correct? Additionally, to handle App Store reviews (which run in the Sandbox environment) and TestFlight tests seamlessly without manual configuration changes, we are planning to implement an automatic fallback mechanism: Our backend always requests the Production App Store Server API first. If it returns a TransactionNotFound (e.g., 4040010) error, the backend automatically retries the request using the Sandbox API. Is this automatic fallback from Production to Sandbox considered a safe and recommended practice by Apple, especially for App Store revi

Hi, During the App Review process, a test purchase was made using what appeared to be a production Apple account. When our app server sent this transactionId to the Production App Store Server API, it returned the error code 4040010 (TransactionIdNotFoundError). To handle this gracefully and prevent review rejections, we are considering implementing a dynamic fallback mechanism on our app server. Specifically, when the Production API returns 4040010, the server will automatically retry the request using the Sandbox App Store Server API URL. Could you please clarify the following points regarding this design? Is it expected behavior for an App Review purchase to return 4040010 on the Production API, and can it be successfully verified by routing it to the Sandbox API? Is this dynamic fallback logic (Production API ➔ if 4040010 ➔ Sandbox API) a recommended and officially supported best practice for handling App Review and TestFlight transactions? Any confirmation or advice from Apple

Hi, I am designing a database schema to store App Store transaction data for our backend system, and I have a question regarding the uniqueness of transactionId. According to the documentation (apple.com), transactionId is a unique identifier for a transaction. However, it is not explicitly clear whether this uniqueness is guaranteed across different environments.Could you please clarify the following points? Is transactionId guaranteed to be unique across both the Production and Sandbox environments? (i.e., Is there any possibility that the exact same transactionId is generated in both environments?) For database design, is it safe to use transactionId alone as a Primary Key? Or is it strongly recommended to use a composite key consisting of both environment and transactionId? Any insights or best practices from Apple engineers or the community would be highly appreciated.Thank you.

I am evaluating a local diagnostic design before implementation or deployment and need to identify a public, supported macOS confinement mechanism. Proposed arrangement: A privileged custodian remains outside a separate privileged guardian's process group. The guardian launches a fixed diagnostic parent under a dedicated unprivileged identity. That parent sequentially launches three fixed sandboxed Python workloads, one child at a time. The current termination design targets the guardian's process group. It must not rely on whole-host process scans or indiscriminate killing. The proposed sandbox profiles are allow-default with file/network restrictions; the test-child profiles deny process-fork. We have not established that these restrictions prevent an existing process from changing its own group or session. Is there a public, supported interface or configuration that keeps all workload descendants within the supervisor's termination boundary from the initial child transition through final

HDMI and DisplayPort audio devices expose no kAudioDevicePropertyVolumeScalar or kAudioDevicePropertyMute, so System Settings disables the volume slider and the media keys do nothing when such a display is the default output. Users end up installing virtual audio drivers or DDC/CI tools, and DDC does not pass through many HDMI paths at all. I wanted to check whether the behavior users expect can be provided with public API only, and it can: AudioHardwareCreateProcessTap with a CATapDescription that excludes the app's own process and uses CATapMutedWhenTapped, a private aggregate device with the tap as a sub-tap and the display as the main sub-device, and an IOProc that scales the tap input into the device output. The volume keys are captured with a session-level CGEvent tap. Source (three files, Swift and Objective-C): https://github.com/mevlut-geredeli/MonitorKeys Observations that may be useful to others using taps: The tap delivers IOProc callbacks only while some process is rendering; at idle there are no