“sandbox”

Our iPad application uses authenticated accounts in our own service. Before enabling access for a member receiving an assigned subscription, we need to establish that the actual assigned Apple member authorized enrollment into the intended account in our service. The unresolved case is another authenticated application account presenting forwarded, genuinely Apple-signed member transaction or app transaction evidence. We need to understand the supported verification boundary that prevents possession of that evidence from being sufficient to acquire another member's access. Personal purchase ownership will remain separate from assigned-member access. Proposed flow for review: The app obtains AppTransaction and the assigned Transaction directly from StoreKit and checks both against the current device using the documented device-verification procedure. It then proposes an App Attest assertion over the exact evidence and a server-issued challenge associated with the authenticated application account. The proposed

My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as S

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is infact giving an empty result The entitlements which I already have added are: com.apple.developer.pass-type-identifiers com.apple.developer.payment-pass-provisioning So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet? Is it possible to redirect user to debug and enterprise builds also as currently the redirection from Apple Wallet is not working for debug and enterprise builds? The PassKit API which I indicated earlier is working in debug build when I sideload from Xcode. But since deepli

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is in-fact giving an empty result So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet?

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network ac

I’m developing a sandboxed macOS app that needs persistent, read-only access to a user-selected folder. We are observing different behaviour between APFS and FAT32/exFAT after renaming the folder or moving it to Trash. The main problem is that the app can still track the folder while running, but cannot reliably restore the connection or identify its location after relaunch. Environment macOS 27.0.1 (26A434) Xcode 27.1 (27A9269) App Sandbox and user-selected file access enabled Folder selection through SwiftUI fileImporter Bookmark creation: .withSecurityScope and .securityScopeAllowOnlyReadAccess Bookmark resolution: .withSecurityScope The selected items are ordinary folders, not volume roots. Filesystem comparison APFS: the tested workflows appear to work as expected, including restoration after relaunch. exFAT: we have reproduced both bookmark renewal failure after a rename and loss of the “in Trash” classification after relaunch. FAT32: we have observed automatic bookmark renewal failure

On macOS 26.6 (25G72), Xcode 26.6 (17F113), xcodebuild -showBuildSettings -json exits naturally with code 74 and reports that the project cannot be read / does not exist. Minimal control: A synthetic three-file .xcodeproj with one iOS application target, one shared scheme and an internal workspace. It contains no app source, package dependencies, extensions or build scripts. Its plist/XML and object references passed static validation. This does not establish that Xcode accepts the project. Reproduction outline: Run xcodebuild for this control under a custom sandbox-exec profile, with a clean environment, isolated HOME/cache/DerivedData, Release configuration, iphoneos SDK, generic/platform=iOS, automatic package resolution disabled, signing disabled, and -showBuildSettings -json. No build or device operation is requested. The profile keeps the control project read-only, restricts access to protected host data, and denies network and Simulator/device services. The exact profile is not attached to thi