“sandbox”

You need to sign in to your Sandbox Apple Account in Settings > Developer. A Sandbox Test Account was subsequently created, but has not been signed in on the device. The user could not find the Sandbox Apple Account entry. From Sign in to your Sandbox Apple Account for a development-signed app: In iOS and iPadOS, the sandbox account appears in Settings > Developer after the first time you use the device to attempt a purchase in a development-signed app. There’s no need to sign out of the non-Sandbox Apple Account. Sign in using a Sandbox Apple Account.

[quote='847615021, Alihan1, /thread/847615, /profile/Alihan1'] Does the documented client-lifetime relationship cover client termination, including SIGKILL, during service startup before the first reply? [/quote] Yes. There’s an obvious race condition here, leaving potentially four potential outcomes: The service does not start. The service starts but doesn’t get any messages. The service starts but the connection is invalidated before it replies. (Note that this can only happen in the escaping case, see below, because messages to the service are serialised on the services queue.) The service starts and replies but the reply fails. There’s no explicit indication of this, although the service will see the connection be invalidated. [quote='847615021, Alihan1, /thread/847615, /profile/Alihan1'] Does it also cover an already running service that is blocked or stopped with SIGSTOP? [/quote] SIGSTOP isn’t part of the XPC service world and you should not be using it in this context. As to what happens if the servic

Thank you. I confirmed that this Mac is running macOS 26.6.2 (build 25G83). This is a new Keychain integration. We have not tested it on earlier macOS versions, so we cannot confirm whether this is an OS regression. What diagnostic logs or checks would you recommend to distinguish an inherited App Sandbox restriction from MAC?

Would a Mac App Store application be permitted to: Apple never pre-approves apps. Sometimes it's obvious (to everyone except the developer) that a given app idea would be immediately rejected. I'm not familiar with any of these AI platforms. Can you explain more about what this thing does? It sounds like you'll need to explain that to App Review too. The .mcpb and the helper executable it contains From what I've heard, I doubt the bundled helper executable would be sandboxed. If not, then you can't include it. And even if it is sandboxed, it would still have to comply with Mac App Store guidelines. If that leads the user to a situation where the app presents its own installation, then that would be right out.

I’m not sure why you had problems with this, but I’ve done this myself and it worked for me. Your relationship to these technologies and APIs is much different than mine. I will only ship, and recommend, those techniques that I can get to work. It took me about 2 years, 1.5 apps, significant effort, and many attempts to get a sandboxed app to talk to a sandboxed launch agent via XPC. I have utterly no idea why I couldn't get it working at first. As far as I know, I'm not doing anything differently now. There must have been some subtle difference or bug, but I don't know what. I just tried turning sandbox off on my launch agent on macOS 27 and it worked! So I guess I've continued to make subtle improvements. It will be a few days before I can test that on 13-26 and remove the XPC service. This stuff ain't rocket science. In my experience, putting satellites in orbit is much easier than this.

I’m seeing the same thing with my app in TestFlight. My sandbox account is set to Japan, and the storefront returns JPN, but the product price comes back as $4.99 in USD. When I tap Buy, Apple’s purchase sheet correctly shows ¥800. I checked the response used by my paywall, so the dollar price isn’t hardcoded. Installing a development build on the same iPhone returns the correct Japanese price through both StoreKit 1 and StoreKit 2. I’ve already tried reinstalling and signing out of Media & Purchases, but TestFlight still returns USD. I’m using Flutter’s in_app_purchase package. Have you heard anything back from Apple or found a workaround?

[quote='906056022, floorish, /thread/845853?answerId=906056022#906056022, /profile/floorish'] The API has been deprecated since macOS 11, not 10.6. [/quote] Indeed. Sorry for the confusion. I’ve gone back and corrected my previous post. [quote='906056022, floorish, /thread/845853?answerId=906056022#906056022, /profile/floorish'] You seem to imply that this XPC connection is not always allowed? [/quote] At a technical level, sandboxed apps are allowed to make IPC connections via an app group, regardless of whether the other end of the IPC connection is sandboxed or not. That’s what’s expected (per that doc you found) and it matches my experience. [quote='906045022, Etresoft, /thread/845853?answerId=906045022#906045022, /profile/Etresoft'] I could not get a sandboxed app to talk directly to a non-sandboxed launch agent [/quote] I’m not sure why you had problems with this, but I’ve done this myself and it worked for me. I’ve also seen other developers take advantage of it. I’m

Adding a data point since our config is a step further than the OP's and still fails — might narrow this down. Setup: NEFilterDataProvider system extension, Developer ID Application signed, fully notarized (Accepted) and stapled, running on macOS 27.0 Golden Gate (26A428) — the public GM release, not a beta. Unlike the OP, our entitlements already use the -systemextension suffix on both sides: Container app: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], com.apple.developer.system-extension.install = true Extension: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], app-sandbox = true, application-groups set And unlike the OP's finding, our Developer Portal-issued profiles DO contain content-filter-provider-systemextension — confirmed by decoding the embedded provisioning profile directly (security cms -D) on both the container and the extension. So in our case the portal is generating the right entitlement value;

The API has been deprecated since macOS 11, not 10.6 Sorry. I read it wrong. But that's still Big Sur. The oldest reasonable OS these days is Ventura. many users (designers) depend on this functionality What's the functionality? Why does your app need this function? How would you do whatever this functionality is on iOS? Just curious: in the proposed workaround the sandboxed app submitted to the Mac App Store would only try to create an XPC connection to a mach service with the app group identifier (user opt in). My understanding was that this is allowed, due to the app group. The app is still fully sandboxed and the user can optionally download an external Helper. Setting aside the App Review complications, that's a bit tricky. I tried to see if I could implement something like this in an app I'm developing. I could not get a sandboxed app to talk directly to a non-sandboxed launch agent, even if both were in the same app group. This was a technical limitation. If the laun

[quote='906035022, DTS Engineer, /thread/845853?answerId=906035022#906035022'] I was hoping to see an obvious sandbox violation [/quote] I couldn't see those either, that's why I filed a bug report. Thanks again for looking into it though! The API has been deprecated since macOS 11, not 10.6. I understand that it may be removed in the future, but: There seems to be no alternative and many users (designers) depend on this functionality. The API still works fine for non-sandboxed apps. It appears that both requesting app and the listening app need to be non-sandboxed. So this indicates it's a sandboxing issue, not an API deprecation/removal issue. I can’t offer any opinions as to what App Review will think about it. Totally understand you're not part of App Review. Just curious: in the proposed workaround the sandboxed app submitted to the Mac App Store would only try to create an XPC connection to a mach service with the app group identifier (user opt in). My unders