Still experiencing this issue on macOS 26 (Tahoe). We are seeing the same storefront region mismatch when testing IAP via TestFlight on macOS. Our observations: Machine-dependent: some macOS 26 machines can complete sandbox purchases, others cannot. Observed working on some 26.2 machines and failing on some 26.3 machines, though we have not confirmed OS version as the sole factor. The workaround of signing out of System Settings > Apple Account > Media & Purchases works, but it also signs out the system account, which is disruptive. The issue appeared after we submitted our build for TestFlight external testing review (public beta). Before that, with internal TestFlight testing only, this was not reported. This follows the same regression pattern others have reported: fixed in 15.2, regressed in 15.3+, and now recurring in macOS 26. Filed as FB22050500 with sysdiagnose logs.

Thank you, Quinn. Your suggestion about using app group IDs worked. After investigation, I found that adding my Team ID-prefixed app group (XXXXXXXXXX.com.mycompany.myapp) to com.apple.security.application-groups in my entitlements resolves both mach-register and mach-lookup without needing any temporary exceptions. Looking at /System/Library/Sandbox/Profiles/application.sb, I can see why this works: (sandbox-array-entitlement "com.apple.security.application-groups" (lambda (suite) ... (allow mach-lookup mach-register (global-name-prefix (string-append suite "."))) ...)) With XXXXXXXXXX.com.mycompany.myapp as the app group, the sandbox allows any Mach service name starting with XXXXXXXXXX.com.mycompany.myapp., which matches Chromium's naming pattern: XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.<pid>. My Developer ID provisioning profile already included XXXXXXXXXX.* in its application-groups, which authorizes any Team ID-prefixed app group. I just needed to explicitly claim it in my entitlements. For Electron developers, here are the specific changes I made to migrate a MAS build to direct distribution with App Sandbox: Set preAutoEntitlements: false in @electron/osx-sign options - The default preAutoEntitlements behavior automatically adds com.apple.developer.team-identifier to entitlements. Even though my Developer ID provisioning profile contains this entitlement, AMFI rejects it: AMFI: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: com.apple.developer.team-identifier This appears to be another certificate-based restriction - com.apple.developer.team-identifier is only honored for Apple Distribution certificates, not Developer ID, regardless of what the provisioning profile authorizes. Add Team ID-prefixed app group to entitlements: <key>com.apple.security.application-groups</key> <array> <string>group.com.mycompany.myapp</string> <string>XXXXXXXXXX.com.mycompany.myapp</string> <!-- Added --> </array> Patch @electron/osx-sign to bypass provisioning profile platform check - By default, osx-sign rejects provisioning profiles that don't match the build platform. I patched util-provisioning-profiles.js to remove this check, allowing my Developer ID provisioning profile to be used with the MAS build. Download Developer ID provisioning profile - When using fastlane sigh, add the --developer_id flag: sigh --platform macos --readonly -a com.mycompany.myapp --developer_id

A further but less important question is that why temporary path is not affected by missing environment variables? If macOS can figure out correct sandbox paths without environment variables, why not all of them doing so?

I finally solved it! It is environment variables that determine the behavior. The helper app was designed to accept some environment variables given by caller, but in our latest developement implementation, only those environment variables are given, without those from electron app. After I added them back, those APIs work as expected. Thanks for your helpful assistance!

Thanks for your kind instructions. I have tried the following steps: I followed your step and reproduced correct behavior. I replaced my helper app with child.app and child.app got /Users/<me> for home. I replaced child.app with my helper app and my helper app got expected home at /Users/<me>/Library/Containers/<app_id>/Data. Now it looks like to have something to do with how helper app is launched by electron app.