“sandbox”

Exact same issue as helong here - ensured both my prod account and sandbox account are set to Ireland and that ie is in my list of customlinkregions with no luck. Country detected correctly and I even get a warning about external purchases, but isEligible is always false.

Update with a decisive data point: I ran a real (non-cancelled) sandbox purchase through the minimal repro project. The resulting Transaction.storefrontCountryCode = GBR and Transaction.currency = GBP — correct. But Storefront.current, called immediately after and again 3 seconds later in the same process, still returns countryCode USA, id 143444. This shows StoreKit has the correct storefront information available (it used it to process the transaction correctly) but Storefront.current and the product catalog query are not returning it. This looks like an internal inconsistency between StoreKit's transaction-processing path and its storefront-reporting API, not an account or device configuration issue.

Different from what ? Does it mean that at first there was effectively a problem ? By different I meant different from my previous game and other similar games. I only started explaining that after reading advice from other developers who got 4.3. As for the category it’s already games with simulation and racing as the subcategories. I honestly don’t see what else would even make sense. And I don’t really think this niche is that saturated compared to some others. I can only find around 3 real sandbox car crash games that are actually similar, not counting my older game

The channel is probably encrypted. If it is not, then just write a bluetooth driver, I don't think that the way you are doing it is enough to intercept a modern bluetooth link. At least not the kind of links we have in my country... Sandbox does not block bluetooth. Sandbox does not block kernel extensions. Go to the library and pick up a book if you can't find online, regular pentesting is crucial to even try to maintain your posture in today's world. Just stop speculating and start executing.

Thanks for the post. For privacy considerations and sandboxing rules strictly prohibit apps from directly accessing raw application usage data or Screen Time statistics for other apps. You cannot get a readable list of which apps a user has installed or exactly how much time they spend on each specific app. However, the Screen Time API (introduced in iOS 15), which allows developers to build parental control and digital wellbeing apps. This API consists of three frameworks: FamilyControls, ManagedSettings, and DeviceActivity. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? Albert  WWDR

Thanks for filing FB24412830. [quote='902166022, PrathibhaD, /thread/842397?answerId=902166022#902166022, /profile/PrathibhaD'] As this worked upto Tahoe … [/quote] Right, but that’s only because it was relying on implementation details. We don’t support folks navigating the view hierarchy in order to manipulate system views. So, when you ask about “intentional change” you need to consider what actually changed. The supported API hasn’t changed here. Rather, we’ve changed a bunch of implementation details. Was that intentional? Clearly. Was the intention to break your product? Probably not (although it’s not like I’d admit that if it were :-). My best guess is that these views have moved to a different process. Way back in the day macOS gained support for remote views, that is, a view that looks like it’s in an app’s window but is actually hosted in a completely different process. The canonical example of this is Powerbox, where we host the standard file open and save views in a separate process so that they

That fixed it. Thank you — and thank you for pushing me back to the recommended answer in the referenced thread. I had read the thread but missed that workaround entirely. For anyone finding this later, here is what my case looked like: My app uses CloudKit only indirectly, through NSPersistentCloudKitContainer. It never references a single CloudKit symbol of its own. So the framework was not loaded at launch, the sandbox came up without the iCloud exception, and the kernel denied com.apple.cloudd and com.apple.duetactivityscheduler — resulting in CKError 6 on every launch that did not come from Xcode. Launched by Xcode it always worked, which is what kept me looking in the wrong place. Adding a line that touches CloudKit at the very start of the launch path was enough. Everything else I had compared between a working app of mine and this one — entitlements and their values, embedded profiles and the entitlements they grant, provisioned devices, signing identity, Designated Requirement, quarantine, b

Thanks for the pointer. That thread shows the same two sandbox denials, but the case there is a Store profile. Mine is a development profile, so I ran a controlled comparison of two of my own apps on one machine. The result is a contradiction I cannot explain, and I would appreciate guidance. Setup macOS 26.6.1, Xcode 26.6. Sandboxed macOS app, Core Data with NSPersistentCloudKitContainer, automatic signing, Apple Development certificate, Xcode-managed Mac Team Provisioning Profile. Symptom CloudKit fails with CKErrorDomain Code=6 whenever the app is launched by anything other than Xcode. The kernel logs: Sandbox: NoteManagerPro(44046) deny(1) mach-lookup com.apple.duetactivityscheduler Sandbox: NoteManagerPro(44046) deny(1) mach-lookup com.apple.cloudd Launched by Xcode, the same bundle works perfectly: the profile is evaluated, TCC approves the container, and there is real traffic to gateway.icloud.com with no errors. The control case A second app of mine on the same Mac,

Also reproduces on StoreKit 1 — with daemon logs and server-side confirmation Same behaviour here through a different API. We use StoreKit 1 (SKPaymentQueue.finishTransaction:), not StoreKit 2, so the defect looks like it sits below both API surfaces. Device iPhone 17 Pro, iOS 27.0 from Aug 14, sandbox account, consumables. Transactions survive their own finish, are redelivered on every launch, and repeat buys replay the same transaction id with no sheet and no charge. We had a device log running, so here is where it fails — 8 finish attempts in the capture, 8 identical failures, 0 successes: storekitd [7ae43896_SK1] Starting request FinishTransactionRequest (accountRequirement: required(signIn: false, …), client: eu.nordeus.TopEleven Sandbox, destination: AMSBagKey(p2-in-app-transaction-done), …) storekitd [7ae43896_SK1] Account is required for request. error [7ae43896_SK1] Failed to encode request parameters (Never): Error Domain=NSCocoaErrorDomain Code=3840 JSON text did not start with ar