“sandbox”

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

We are designing a bounded local macOS operation with a supervisor, controller and helper. All three must be unable to cause prohibited network effects, including attributable delegated requests, before admission and until quiescence. Unrelated applications must retain their normal network access. We are seeking an API contract clarification, not reporting a reproduced OS bug. No NetworkExtension provider has been activated for this design. Our reviewed SDK is MacOSX27.0.sdk; its presence is not a runtime qualification. Please identify the supported macOS versions for your answer. The design must tolerate provider crash, termination, disconnection and unresponsiveness, and operation lease expiry/revocation. Administrative filter disablement or privileged reconfiguration is a separate unresolved threat-model case, not something we assume ordinary failure handling covers. We reviewed content-filter deployment in TN3134 and the nullable/delegated audit tokens in NEFilterFlow. We understand that NEURLFilterManage

Hello, I’m investigating subscription product discovery in my iOS app, BiteTempo. StoreKit 2 completes the product request successfully but returns an empty array for both auto-renewable subscriptions. The issue occurs on a physical iPhone running through Xcode and also in TestFlight. App and products Bundle ID: shehan.NouriJournal App version: 1.0 (4) Monthly: shehan.NouriJournal.plus.monthly Annual: shehan.NouriJournal.plus.annual Reported storefront: USA Device system version reported in diagnostics: 26.6.1 (23G83) Reproduction Run the app on a physical iPhone through Xcode with StoreKit Configuration set to None. Open the subscription paywall. Request both products using Product.products(for:). Inspect the returned array immediately after the awaited call, before filtering. At that breakpoint, returnedProducts contains 0 values. The empty result is not created by application filtering or by converting a caught error into an empty array. Errors are reported separately. Diagnostic output from the Xcode devi

-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@Finsihed %lu of %lu,finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish

Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {iss:a5******---****-3c08,iat:1790134367,exp:1790135567,aud:appstoreconnect-v1,bid:com...Pal} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU******************************************************************************************************************

ExternalPurchaseCustomLink.isEligible always returns false although the documented Japan requirements are satisfied. Environment: iPhone, iOS 26.7 Bundle ID: com.audio.yoho.ios Storefront: JPN (143462) Japan Sandbox account canMakePayments: true AppTransaction: Sandbox, verified Signed entitlement: com.apple.developer.storekit.custom-purchase-link.allowed-regions = [jp] ExternalPurchase.canPresent also returns false. Has anyone successfully tested this API in a development-signed Sandbox build? Feedback Assistant: ExternalPurchaseCustomLink.isEligible always returns false although the documented Japan requirements are satisfied. Environment: iPhone, iOS 26.7 Bundle ID: com.audio.yoho.ios Storefront: JPN (143462) Japan Sandbox account canMakePayments: true AppTransaction: Sandbox, verified Signed entitlement: com.apple.developer.storekit.custom-purchase-link.allowed-regions = [jp] ExternalPurchase.canPresent also returns false. Has anyone successfully tested this AP