“sandbox”

Hello! Is it possible to test in Sandbox the flow of pending purchase request changes to succeed for Advanced Commerce API? As StoreKit configuration file can not be used with Advanced Commerce API, how to test for example flow Ask to Buy when child account ask parent account to buy generic consumable product? And also does Advanced Commerce API supports feature Ask to Buy?

Dear Apple Developer Support and App Review Team, I am contacting you regarding a recurring issue that has prevented my application from successfully passing App Review despite extensive testing and multiple attempts to investigate and resolve the problem. The application has been rejected under Guideline 2.1 – Performance because the subscription plans reportedly fail to load during review. According to the review notes, the In-App Purchase product list appears empty on the review device, preventing the paywall from displaying correctly. The main challenge is that this behavior cannot be reproduced outside of the App Review environment. The exact same binary reviewed by App Review has been thoroughly tested through TestFlight on multiple physical iPhone and iPad devices using multiple Sandbox tester accounts, different network conditions, fresh installations, and repeated purchase cycles. In every test, StoreKit successfully retrieves the configured products, RevenueCat offerings load correctly, loc

Is this the right way to pass data to a sheet for editing? struct Detail: View { ... // The single atomic source of truth for our sheet presentation @State var editorConfig: EditorConfig? // Completely encapsulated local configuration package struct EditorConfig: Identifiable { var id: PersistentIdentifier { item.persistentModelID } let context: ModelContext let item: Item } var body: some View { ... Button(Edit) { // 1. Spin up a separate scratchpad container layer let context = ModelContext(modelContext.container) context.autosaveEnabled = false // 2. Safely resolve our model inside the new isolated playground if let sandboxItem = context.model(for: item.persistentModelID) as? Item { // 3. Package it up to trigger the sheet presentation editorConfig = EditorConfig(context: context, item: sandboxItem) } } } } // 4. SwiftUI tracks value replacement accurately without ghost state bugs .sheet(item: $editorConfig) { config in // Inject the isolated context into the sheet's environment chain EditorView(item: conf

Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there exi

Are there specific Entitlements (com.apple.security.temporary-exception.files.absolute-path.read-write or network exceptions) required to allow App Intents to talk to local UNIX sockets or loopback interfaces (127.0.0.1) without triggering sandbox violations?

We are designing a macOS utility that runs a local background agent via launchd (managing a local SQLite database and Unix socket). We want to expose controls (start/stop, status checks, CLI command invocation) to Siri via the App Intents framework. Since App Intents typically execute within a sandboxed App Extension or a sandboxed App wrapper container: What is the recommended IPC mechanism (e.g., Unix domain sockets, local HTTP/TCP ports, XPC) to securely communicate between a sandboxed App Intent extension and a non-sandboxed launchd helper daemon on macOS? Are there specific Entitlements (com.apple.security.temporary-exception.files.absolute-path.read-write or network exceptions) required to allow App Intents to talk to local UNIX sockets or loopback interfaces (127.0.0.1) without triggering sandbox violations? Can an App Intent directly invoke a helper command-line tool or launch a plist-configured service without bringing up the main application UI?

I guess this is in parts a multiplatform / SwiftData / WidgetKit and SwiftUI question. my usual problem is I start an app and then quickly find myself wanting to add widgets / controls / AppIntents and expand across multiple targets. for example I start with an iOS only target and expand to watchOS, iPadOS and visionOS. But since this targets and the apps I want to build are very distinct, I don’t find myself using the multiplatform target but instead a target per platform. This (at least from my understanding) then also comes with the benefit that I can add a WidgetKit extension and all targets use it. now this is the base idea, but here come the many questions I have had issues finding a clear answer and guidance on over the last years. When sharing SwiftUI views and business logic for DRY, whats the actual best way to do that? A „core“ swift package, or a library? what are the implications of choosing one over the other? I understand that widgets are separately scoped and sandboxed from my main ap

In my sandboxed app, if a bookmarked network source is unavailable, is resolving the source/root security-scoped bookmark the recommended way to way to trigger a remount of the network volume? Thanks!

Can the new FSClient.mountSingleVolume along with the com.apple.developer.fskit.mount entitlement be used to mount a block device resource from a sandboxed GUI app? I ask since FSBlockDeviceResource doesn’t seem to have a public initializer other than init(coder:) and using Disk Arbitration (e.g. DADiskMount or DADiskMountWithArguments) has been finicky with the App Sandbox (FB16728800). I'm interested in making an easy workaround e.g. for users who have an internal partition supported by my file system extension that isn't automounting (FB21729650).