“sandbox”

I’m trying to diagnose a StoreKit issue with an auto-renewable subscription in my iOS app. The subscription is called “Lighthouse Plus” and is $9.99/month. The app is currently being tested through TestFlight. When the user taps the Lighthouse Plus subscription button, the app begins the purchase process/loading state, but the Apple purchase sheet never appears. The UI then remains stuck loading indefinitely. This has continued across multiple TestFlight builds, including our current Build 11. What happens: Install/open the app through TestFlight. Sign into the app. Navigate to Lighthouse Plus. Tap the subscription/purchase button. The app enters a loading state. No Apple purchase confirmation sheet appears. The loading state never resolves. We have also been investigating Restore Purchases and Manage Subscription behavior as part of the same StoreKit implementation. The subscription product has been configured in App Store Connect and associated with the app. We have repeatedly tested new builds while trying

Our first submission has now been rejected under Guideline 2.1(b), with the message: the in-app purchases do not load successfully. Each review was performed on an iPad Air 11-inch (M3) running iPadOS 26.6. The app sells only auto-renewable subscriptions. We cannot reproduce the failure, and we have verified every part of the configuration we can think of. WHAT WE VERIFIED (via the App Store Connect API, not just the UI) Two subscriptions in one group, state READY_TO_SUBMIT Product IDs exactly match what the app requests Available in 175 territories, including the United States Prices set, en-US localizations present for both products and for the group App review screenshots attached to both, state COMPLETE Both subscriptions are included in the review submission (READY_FOR_REVIEW) Paid Apps Agreement: Active. Bank account: Active. Tax forms: Active. WHAT WORKS On our own devices, installed via TestFlight (sandbox environment), the products load correctly and a purchase completes and activates as exp

I have reproduced an issue with AVSpeechSynthesizer on macOS 26.6.2 (25G83) using a minimal Mac Catalyst application. Environment macOS 26.6.2 (25G83) Apple Silicon Xcode 26.x Mac Catalyst AVSpeechSynthesizer Enhanced voice: com.apple.voice.enhanced.en-GB.Daniel The problem is specifically related to App Sandbox. Reproduction I created a completely new minimal Mac Catalyst application. With App Sandbox disabled: let synthesizer = AVSpeechSynthesizer() let utterance = AVSpeechUtterance(string: Hello, this is a test.) utterance.voice = AVSpeechSynthesisVoice(identifier: com.apple.voice.enhanced.en-GB.Daniel) synthesizer.speak(utterance) The Enhanced voice works normally. With App Sandbox enabled, with no other sandbox capabilities enabled, the same code no longer produces audible speech.

We have 5 consumable in-app purchase products (Product IDs: localshadows_support_099, _499, _999, _2499, _4999) currently in Prepare for Submission status. Our app's first version (1.0) has also not yet been submitted for App Review. Question: Does sandbox testing of these consumable IAPs require the app to be fully approved through App Review first, or is it sufficient for the products to be attached to a version that has been submitted (even if still pending review)? What we've tried: We're using react-native-iap v16.4.1 for a real native StoreKit 2 purchase flow (not RevenueCat, which was masking this issue via its Test Store simulation mode). Calling fetchProducts() for these SKUs returns an empty array, and calling requestPurchase() for them results in an indefinite hang with no error. We want to complete sandbox testing before deciding on our actual App Review submission timeline.

Hi everyone, I'm encountering an issue where the storefront country code returns USA unexpectedly in TestFlight builds, and I'd appreciate any insights from the community. Issue Description When executing SKPaymentQueue.default().storefront?.countryCode in our TestFlight builds, the property returns USA. However, we expect it to return JPN because both the Sandbox test user account and the Apple Account region configured on the device are set to Japan. Behavior Across Environments Xcode Debug & Ad Hoc Builds: Returns JPN as expected. TestFlight Builds: Returns USA unexpectedly. Related Threads I've noticed several threads reporting similar issues without a clear resolution: https://developer.apple.com/forums/thread/660817 https://developer.apple.com/forums/thread/794932 https://developer.apple.com/forums/thread/800078 https://developer.apple.com/forums/thread/814178 https://developer.apple.com/forums/thread/810860 Questions Is this USA value a known TestFlight/Sandbox-specific limitation

Summary On macOS 26.6.2 (25G83) (Tahoe), Chrome fails to load pages hosted on private/local IP addresses (e.g. http://192.168.0.43/, a home AV receiver's web setup page) with ERR_ADDRESS_UNREACHABLE, while Safari loads the identical URL without issue on the same Mac, same network. ping to the target IP succeeds normally. System Settings > Privacy & Security > Local Network shows Allow for Chrome — but this is not what's actually being enforced. Traced the root cause to nesessionmanager stuck in an infinite retry loop when attempting to install/update NetworkExtension path-rule policies. Because the daemon never completes a successful policy install, nehelper (the actual enforcement point) continues serving a stale cached denied decision indefinitely, regardless of what the Settings UI shows or how many times the toggle is flipped. Key evidence Chrome netlog (chrome://net-export/) shows a genuine TCP connect attempt (not an early permission rejection): text TCP_CONNECT_ATTEMPT --> address = 192.16

I have spent the last few months working on a new app, Jelly Music — by JellyLabs, which is a music client for Apple Music users. It has 100+ TestFlight users who are using it daily and sharing great feedback. The app does not include any template code and is not overly similar to any existing apps on the App Store, as far as I know. It includes lots of unique features, like a personal dj (like Spotify), radio stations from playlists (with different station discovery modes), custom app themes, lots of view options for your playlists/songs/artists/albums, bump song to top of library option, Sonos speaker controls, Mac Bridge Sync which allows you to view/edit your song metadata from your iPhone/iPad while your Mac writes the changes to your library, etc. See video here: https://www.reddit.com/r/AppleMusic/comments/1vwkp0n/jelly_music_a_new_apple_music_client_with_full/ The app did previously include one third party open source dependency, FluidAudio (a voice model that powered a live dj feature), so my latest