“sandbox”

We recently received a 14-day compliance notice regarding Guideline 3.1.2(c) for one of our live apps. We promptly submitted an updated build addressing the subscription flow. However, the build received a Guideline 2.1 (Information Needed) rejection, requesting navigation paths and sandbox reproduction steps for specific In-App Purchase product IDs. Following their instructions to simply reply with the requested information without uploading a new binary, we provided a comprehensive step-by-step PDF navigation guide and submitted our response via App Store Connect yesterday. Because no new binary was uploaded, the submission status remains Rejected, and our 14-day compliance grace period is expiring in less than 48 hours. We are quite concerned about potential disruption to the live app's availability while waiting for the team to pick up and review our response. Has anyone experienced a similar situation right near the 14-day deadline? Does having an active reply pending review under a Rejected sta

Hello, I'm desperately looking for a way to purge the contents of the Local Network allowlist in System Settings. Every version of a test app I've ever used gets an entry in there, and apparently so does each build of Chrome and Claude Code. Claude recommended I include the following context, and if there's a specific answer to that, great, but any way of purging this list would make me very happy. ==== Caution: slop below this line ==== macOS 27.0 (26A428), Apple silicon. The Local Network list has 471 entries, many dead: Chrome code_sign_clone paths that no longer exist, old ad-hoc builds, uninstalled apps. The pane can't remove any. Is there a supported way to remove entries or reset the list, short of Recovery? Editing /Library/Preferences/com.apple.networkextension.plist as root fails with EPERM, both rename-over and open-for-write. New files in that directory work. SIP is on, the file has no flags or xattrs, Full Disk Access didn't help, and there are no Sandbox/TCC denials in the log. What pro

We are seeing a consistently reproducible StoreKit Sandbox issue involving Apple’s refund request sheet. Our app uses: Transaction.beginRefundRequest(for:) The refund sheet is successfully presented, but instead of loading the refund reason form, the Apple-provided sheet consistently displays: “Cannot Connect” This prevents the Sandbox refund request from being submitted. Environment: App: BTY Norebang Admin iOS: 26.6.1 Physical iPhone StoreKit environment: Sandbox Product type: Consumable Product: BTY Room – 1 Hour Development-signed build We have confirmed: Normal consumable purchase succeeds Transaction retrieval succeeds beginRefundRequest successfully presents Apple’s refund sheet App Store Server API calls succeed App Store Server Notifications V2 TEST delivery succeeds Get Test Notification Status reports sendAttemptResult = SUCCESS The problem persists after rebooting the device The problem persists after signing out and back into the Sandbox Apple Account Different

What supported public API and verification contract should a sandboxed macOS file manager use to preserve a copied file's quarantine/provenance metadata? We observe different results in App Sandbox versus Finder and an otherwise-matched non-sandbox diagnostic. We want to keep App Sandbox and all security protections enabled, not remove quarantine or invent undocumented flag masks. Environment: macOS 26.6.2 (25G83), Apple Silicon, local APFS. Optimized Foundation-only diagnostic, Apple Development signing, Hardened Runtime, launched directly as an executable. The sandbox variant has app-sandbox, user-selected read/write and app-scope bookmark entitlements. This is not a notarized distribution-build comparison. Reproduction: Use an existing regular JPEG with naturally present com.apple.quarantine metadata identifying Chrome, raw flags 0283 and a nonempty event field. Keep the original read-only. Record SHA-256, length, full raw extended attributes and fresh

I've implemented Apple Pay payments in my website. I'm using live environment and real card and not the sandbox. Everything works fine till the last step. When I have to make payment it does not show the pay button or Pay with Touch ID option on Apple paysheet.

On macOS 26.6.2 (build 25G83), arm64, I am using the Security framework through JXA, executed by a static /usr/bin/osascript helper launched from the Codex desktop application's local command environment. A dummy-only test attempts to add one generic-password item to the local file-based login keychain. SecItemAdd returns OSStatus 100001. The system's security error 100001 command describes this as UNIX[Operation not permitted]. The helper explicitly opens the login keychain and selects it using kSecUseKeychain for the add operation. Synchronizable and Data Protection Keychain options are false. It supplies an access object created by SecAccessCreate with an empty trusted-application array. What I have confirmed: Keychain open/status calls succeed and report unlocked, readable, and writable. I understand these flags do not establish permission for this individual operation. Attribute-only exact lookups report the dummy item as not found before and after each failed add. Granting narrowly scoped filesystem wri

I am investigating a repeatable StoreKit 2 restore failure in SommPal, TestFlight 1.0.0 (20), on a physical iPhone running iOS 26.6.2. Feedback report FB24795995 has been submitted with attachments. An explicit user tap calls try await AppStore.sync(). Apple presents an Apple Account password prompt. The tester enters the password for the displayed account and presses OK; no visible authentication error appears. The call then throws typed StoreKitError.unknown, bridged as NSError domain StoreKit.StoreKitError, code 2. Traversal through NSUnderlyingErrorKey exposes no nested cause. This is not SKErrorDomain code 2, and we are not interpreting it as user cancellation. The tester reports Media & Purchases signed out and a dedicated Sandbox Apple Account configured under Developer settings. The prompt displays the personal Apple Account rather than the dedicated sandbox account. Sandbox subscription management loads successfully. Controlled tests on September 15, 2026: Isolated refr

We are testing version 1.0 Build 29 through TestFlight after a Guideline 2.1(b) rejection: Purchase did not respond on iPad Air 11-inch (M3). Paid Apps Agreement is Active, and subscription price, availability, localization and review screenshot are present. Restores worked, but a fresh purchase is not yet verified. On iPhone 13, Build 29 is installed, Developer Mode is on, and Media & Purchases was signed out. The tester reports signing into Developer > Sandbox Apple Account, then trying to sign into the app. During this sequence an email verification prompt was followed by: iTunes account creation not allowed. This Apple account cannot be used with iTunes Store at this time. Please try again later. The app uses Sign in with Apple separately from StoreKit. We have not isolated which system authentication flow produced the error. What is the supported sequence for regular iCloud/Sign in with Apple alongside a Sandbox Apple Account for TestFlight purchases? Which diagnostics distinguis

I’m designing a macOS utility that needs to run a bounded, one-shot diagnostic and collect its result. The lifetime problem is: A controller asks for the diagnostic to start. The diagnostic may begin successfully. The controller can then fail immediately — potentially before it has retained the child’s PID or established output collection. The diagnostic may close stdin/stdout/stderr while continuing to run. The diagnostic must not become an unmanaged orphan if the controller disappears. A focused test case uses Foundation.Process: Controller launches Child. Controller immediately exits with _exit(42), without waiting for Child or retaining its process identifier. Child calls setsid(), closes stdin/stdout/stderr, stays alive for up to 120 seconds, then exits. What I’m trying to establish is the supported macOS lifecycle boundary, rather than inventing a cleanup scheme around PIDs. Is there a supported per-user launchd or other OS-managed mechanism where the OS assumes responsibility for the job before the dia

I am troubleshooting a reproducible StoreKit product discovery issue in a TestFlight build of my iOS application. App: Bundle ID: com.aileguvende.app Version: 2.9.59 Build: 97 On a physical iPhone using the TestFlight build, opening the subscription/paywall screen reproduces the issue. StoreKit availability is true and canMakePayments is true, but Product.products(for:) requests six auto-renewable subscription identifiers and returns: Requested products: 6 Returned products: 0 Not found products: 6 The query reports product_query_error with the plugin error code storekit_no_response. No purchase or Restore operation is required to reproduce the issue. The applicable TN3186 checks completed successfully: the App ID is explicit, In-App Purchase capability is enabled, the bundle ID and signing profile match, all six product identifiers match App Store Connect, all six products are available in Türkiye, pricing is configured, Turkish and English localizations are present, and the Paid Apps Agreement, banking, and

CTFontManagerCreateFontRequestRunLoopSource does not receive any font requests on macOS 27, since beta 5. This API worked fine until macOS 27 beta 4, including previous macOS releases. It looks like this is caused by the App Sandbox. When the com.apple.security.app-sandbox entitlement is disabled the font request source does receive events. Report including sample project: FB24764122 let source = CTFontManagerCreateFontRequestRunLoopSource(0, { (dict, pid) in /* does not receive events when sandboxed */ } CFRunLoopAddSource(CFRunLoopGetCurrent(), source, .defaultMode) Is this a deliberate change or is this a bug in macOS 27? Is there an entitlement that can be set to enable the API in sandboxed apps? My application is distributed on the Mac App Store and as standalone app. Both are properly sandboxed for added security. Disabling the App Sandbox for this specific API would be very undesirable as users will lose all Sandbox benefits.