“sandbox”

Thanks for your question, I suggest you do two separate Build and Archive processes, one for iOS and one for Mac Catalyst. What version of Xcode are you using? Even though Mac Catalyst allows you to use a single codebase and a single Xcode project, the end result is two completely different binaries. I would recommend to use Xcode 27.0 beta X You can also create a multiple platform and then add Mac Catalyst: “For Mac Catalyst builds, this target and its dependencies will link or embed only Mac-compatible content, and the security and App Sandbox settings will be aligned with the iOS app.” Only one native Mac app can be added to the App Store, so make sure you select a Mac Catalyst or a Designed for iPad. If you have Apple Vision on that multi platform will be superseded by the native Apple Vision app in the App Store. You achieve this by ensuring that both your iOS target and your Mac Catalyst target use the exact same Bundle Identifier. Once your Catalyst app is approved and released, it will be the

hanks for the post. This is extremely interesting post. Since you have already ruled out the network environment (by testing multiple Wi-Fi networks and an iPhone hotspot) and user-space configurations, the issue is almost certainly occurring at the daemon level, the network-request level, or is a beta-specific hardware? The correct thing to do should be to filing a bug with a focused simple project showing the issue because at this time I do not think we have seen that issue happening as far as I know. While you mentioned resetting Location Services, macOS can be notoriously stubborn about holding onto corrupted SQLite databases in the /var/db/locationd/ directory. If the local cache is corrupted, locationd might fail to write new ALS responses or read existing ones, defaulting to an unknown state. Location Services can intentionally fail to return a location if the Wi-Fi interface is missing a Country Code or is receiving conflicting 802.11d regulatory domain beacons. In some beta builds, if the system cann

[quote='894813022, DrMiller, /thread/835497?answerId=894813022#894813022, /profile/DrMiller'] 346JXXXXXX is my Team Member ID [/quote] No it isn’t. Rather, it’s your App ID prefix. That much is very clear from my view of your team, but you can prove it for yourself. Do this: Go to the Certificates, Identifiers, and Profiles section of the Developer website Switch to Identifiers. Filter for App IDs containing com.company.app-name (well, your real bundle ID, not the redacted one we’re using here). Open the one you find. At the top right you’ll see your Team ID and in the App ID Prefix field you’ll see your… well… App ID prefix. Here’s an example of what that looks like for an App ID in one of the DTS test teams: If you manually generate a provisioning profile for that App ID and then dump that profile you’ll see something like this: % security cms -D -i AppIDPrefixTest_Mac_Dev.provisionprofile | plutil -p - { … ApplicationIdentifierPrefix => [ 0 => VYRRC68ZE6 ] … Entitlements => { com.apple.application

also unable to add sandbox mastercard to iwatch wallet, no issue for amex. slightly difficult and failed but in the end managed to add visa after several manual input sandbox test card. Please take a look at 23315137

Dears, Several days have passed ... More than 30 developers have seen this, yet nobody replied to me. Please understand that this is not my day job. I have purchased a PERSONAL PRODUCTION version a NEW Macbook M4 air 15inch 2025 together with iPhone 17 standard 2025 in Slovakia as explained above. Yet my macbook and my iphone are setup as an AppleInternal devices with experimental functions and some really important files that I probably should not see .... So please get me somebody to whom I can talk to !!! I guess this is somekind of a leakage that somehow ended in my hands ... There is a lot here, but I dont want to share in forum ..... Some details from my terminal ... echo $PATH /usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/pkg/env/global/bin Here are som

I found out part of my problem involving CloudKit, SwiftData and multiple AppleIDs. It turns out that there is a setting in the Mac version of the AppStore app, called Sandbox Account. (This setting is not available on the Mobile versions of the AppStore app.) It appears that this setting is used to determine what AppleID is associated with an app when it is downloaded. In my case, this setting was set to my old AppleID. So when I loaded my app from the AppStore, it was associated with my old AppleID, which meant that CloudKit stored its synced data is my old AppleID's account. On the mobile side, this setting doesn't exist, so it appears that the AppStore uses the CURRENT AppleID. So my app was associated with one AppleID on the Macintosh and another AppleID on mobile devices. Hence incompatible data and no syncing. Changing this setting on Macintosh and reloading fixes synching, but leaves me with a different problem — before starting all this testing, I saved the SwiftData database from the Mac, w

I took the help of claude code and come to a conclusion like this Summary: IPv4 ARP cache invisible via PF_ROUTE sysctl on macOS 27 — bundled apps only; cause unknown TL;DR: On macOS 27, querying the IPv4 ARP cache via sysctl(CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO) returns an empty result (needed == 0) inside our built .app bundle, with or without the App Sandbox entitlement. The identical query with AF_INET6 returns real data in the same app. arp -a (system binary) shows IPv4 entries fine. Crucially, the identical sysctl code run as a bare, unbundled swift repro.swift script also returns real IPv4 data — so this is not about code-signing or sandboxing in general, it's specific to being a launched, bundled GUI app. We suspected the Local Network privacy permission next (the app had never appeared in System Settings → Privacy & Security → Local Network), added NSLocalNetworkUsageDescription/NSBonjourServices, forced the permission prompt via an NWBrowser Bonjour browse, a