“sandbox”

[quote='885413022, DTS Engineer, /thread/823455?answerId=885413022#885413022'] Apps that publishes a scripting target, both app and third-party, are so rare that no one every exercises this case. [/quote] Most likely. [..] by first checking whether any of your target apps publish helpful scripting targets They don't, but the developers could in theory add them. However, then the security model would lay in the hands of those third party devs. Not sure how that would work — devs could just add an access group to all scripting actions to allow other sandboxed apps to access them. Anyway, thanks for your insights!

I observed the following: On a test device, I signed out of the production App Store account. I then created a sandbox account in App Store Connect with a specific region. After signing in on the device using only that sandbox account, and with no production App Store account signed in, Storefront.current?.countryCode started returning the expected store country and matched the sandbox account region. @Apple Given this behavior, can we assume that in production builds downloaded from the App Store, Storefront.current?.countryCode will reliably reflect the user’s actual App Store storefront? Or are there known cases where the returned value may still be stale or inconsistent (e.g. due to caching or account history)?

@GahyunKim Could you please help me understand why only the 6 Months subscription is not being returned? Confirm you set localization for the subscription and its subscription group. For more information, see View and edit In-App Purchase information and TN3186: Troubleshooting In-App Purchases availability in the sandbox.

Please submit a feedback assistant ticket at (http://feedbackassistant.apple.com). Please provide as much information as possible, ie a sysdiagnose, app apple ID, in-app apple IDs, sandbox account apple ID (if applicable), transactions IDs, steps to reproduce and other relevant details. File ticket under iOS & iPadOS, macOS, tvOS, watchOS, or visionOS and ensure you select “App Store” for the question “Which area are you seeing an issue with?” Categorize the type of feedback Please attach all available files needed to verify After submitting the feedback, please regularly check the ticket as we'll only communicate through it from then on. Once you open the Feedback Assistant Ticket report, please post the FB number here for reference. If you have any questions about filing a report, take a look at Bug Reporting: How and Why (https://developer.apple.com/forums/thread/712889)?

Your specific questions are about App Review policy. I don’t work for App Review, and thus can’t offer definitive answers on their behalf. If you want to talk to them about their policy, you can contact them via the various channels described in Developer > Distribution > App Review [1]. However, my experience, based on conversations I’ve had with developers, is that App Review rarely approves folks to use temporary exception entitlements [2]. Depending on your app’s intended user experience, you might be able to approach this differently, as explained in Implementing Script Attachment in a Sandboxed App. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You could also start a thread here on the forums, in the App Store Distribution & Marketing > App Review subtopic, but my experience is that threads that ask questions like this tend to get redirected into one of the above-mentioned channels. [2] Which isn’t to say th

Hello Kevin, and thank you for your answer! Just to clarify, by file manager do you mean that your app is doing its own navigation of the broader file system or that your app is a file provider extension? If you're a file provider extension, why do you need/want access to so much of the system? It is a general-purpose file manager (a Finder replacement for former Windows users), which is why it's essential for the app to have a user-defined, permanently-living bookmark. '/' is just an example - in practice users can (and often do) grant access to one or several specific subtrees. When you relaunch are you presenting the open panel again or are you renewing an existing bookmark? I think you're presenting the open panel again on launch but if you're renewing a bookmark then I'll need to take a closer look at this. I restore an existing bookmark from @AppStorage (UserDefaults-backed), and it always restores all access - including ~/Library/Mobile Documents - without presenting the panel again. The same bookmark

Starting somewhere around macOS 26.3, my sandboxed file manager spontaneously loses access to ~/Library/Mobile Documents mid-session. Just to clarify, by file manager do you mean that your app is doing its own navigation of the broader file system or that your app is a file provider extension? If you're a file provider extension, why do you need/want access to so much of the system? What makes this specific to FP-backed paths: regular paths under the same '/' bookmark (~/Library/Application Support, etc.) stay accessible and recover normally with a fresh start AccessingSecurityScopedResource() call. Only ~/Library/Mobile Documents and its subtree fail - the entire tree, including the parent directory itself. What other directories have you tried? Particularly directories user directories like ~/Documents/ or ~/Downloads/? Looking at the bug, the current theory is that this is actually tied to a difference between the sandbox extension originally issued by the open panel and the new extension

The Synced @ [time] timestamp updating while content stays empty is one of those bugs where everything looks correct and nothing works. A few things that usually fix it: Most common cause: the subscriptions in App Store Connect aren't fully configured. The sync only pulls subscriptions that have localization, pricing, and review info all filled in for at least one language. If any single one of those is missing, that subscription gets silently skipped. Open each subscription in App Store Connect and look for red Missing Metadata warnings. The subscription group itself matters. Xcode pulls the group along with the subscriptions. If the group has no localization (display name, level), nothing under it comes across. Sign out and back into your Apple ID in Xcode > Settings > Accounts. The auth token for the App Store Connect API can go stale and the sync silently fails for one team while appearing to succeed. If none of that helps, just build the .storekit file manually. It's usually faster than fighting th

Classic StoreKit 1 to 2 migration pitfall. A few things worth checking: The sandbox account matters more than you'd expect. When you reinstall, make sure you're signed into the same sandbox Apple ID that actually made the SK1 purchase. If it's a fresh sandbox user or a different one, there's literally no transaction to restore. Settings > Developer > Sandbox Apple Account shows who's currently active. For a non-consumable originally purchased via SK1, after AppStore.sync() completes, the transaction shows up in Transaction.currentEntitlements with its original productID, but the id or originalID might be a legacy numeric identifier rather than a UUID. If you're filtering entitlements by anything other than productID, that could be why you don't see it. AppStore.sync() triggers an Apple ID password prompt. If the user cancels that prompt, it returns without throwing but also without actually syncing. Wrap it in try/catch and log so you can distinguish canceled vs succe

[quote='884993022, rbmanian75, /thread/815676?answerId=884993022#884993022, /profile/rbmanian75'] is it allowed in sandboxed environment? [/quote] I’m not sure the App Sandbox is the main concern there. That code relies on implementation details and is thus unsupported. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In-app purchase is only support for App Store distribution, so Developer ID isn’t a factor here. In general, you can’t run code signed with an Apple Distribution signing identity. See Don’t Run App Store Distribution-Signed Code. [quote='823308021, DexterC, /thread/823308, /profile/DexterC'] Is there any other way to get a properly signed and runnable .app for testing IAP? [/quote] Yes. Use an Apple Development signing identity whose certificate was issued by your paid development team (the same team you used to set up the Apple Distribution signing identity). Apps signed this way will talk the StoreKit sandbox, can use StoreKit Test, and so on. I can’t help you with the third-party tools you’re using, but to do thish in Xcode you: Navigate to Signing & Capabilities. Enable “Automatically manage signing”. Select your paid team is the Team popup. Select Development in the Signing Certificate popup. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1