“DTiPhoneSimulatorErrorDomain Code 2”

@ppwqgtl That “Profile Missing / Provisioning Profile Not Found” line is extremely interesting. We just captured a fresh sysdiagnose from our own recurrence and it now looks very similar. In our latest case, the sequence was: TestFlight installed our iOS app and paired Watch app build. AppConduit/MobileInstallation reported the Watch app install succeeded. The Watch app launched successfully once after the update. A few minutes later, TestFlight queried installed beta Watch apps and found our Watch app still installed. Immediately after that, TestFlight/appconduitd removed two Watch-side provisioning profiles. The next watch app launch failed before our app process started with the same security/profile trust denial. The files where we saw this were: iPhone sysdiagnose: logs/AppConduit/AppConduit.log.0 logs/AppConduit/AppConduit.log.1 logs/MobileInstallation/mobile_installation.log.0 Watch sysdiagnose: logs/AppConduit/AppConduit.log.0 logs/MobileInstallation/mobile_installation.log.0 The most useful

@ppwqgtl Small correction/update from our side: my earlier reply saying reboot fixed this was wrong. In the latest reproduction, a normal Apple Watch reboot did not recover the app. Deleting/reinstalling from TestFlight does recover it. Separately, one affected watch recovered after the battery drained completely, was left dead for hours, then charged/cold-booted. So this seems more persistent than a simple in-memory bad state. Our latest read is still that this is not an app crash. In the failed state, our app process is never created, there are no app startup logs, and launching with devicectl fails before our code runs with the same Security / RequestDenied shape. The strongest evidence we have now is around AppConduit / paired app state. In iPhone sysdiagnose we see AppConduit / ACXRemoteAppList reporting that the “App database is out of sync” around the relevant window. That lines up with the symptoms: the TestFlight watch app was installed, had launched successfully earlier on the same build/de

We’ve now conducted additional tests. We have a 10-year-old app with around 800 downloads per day that has already been migrated to StoreKit 2 for quite some time. With real users in the live app, there are no issues — purchases can be made and restored successfully. However, with a sandbox test user while launching the app from Xcode, neither purchasing nor restoring works. In another 13-year-old app with around 1,800 downloads per day, StoreKit 2 works perfectly both live and with the sandbox test user without any issues. All apps use the exact same code for the StoreKit 2 logic and are tested with the same users. Today we will take the risk and submit the app we were originally talking about for review after switching to StoreKit 2, and test whether it works live without any problems.

Resolved — posting the fix for anyone who hits this later. Root cause An EXAppExtensionAttributes block in our main app's Info.plist was registering the host app itself as an embedded com.apple.appintents-extension carrying our intents: EXAppExtensionAttributes EXExtensionPointIdentifier com.apple.appintents-extension IntentsSupported FeatureAppIntent ... After removing that block: AVCaptureSession.startRunning() with the audio AVCaptureDeviceInput attached no longer fires -11800 / 'what'. currentRoute.inputs is no longer empty — MicrophoneBuiltIn shows up as expected. AVAudioRecorder.record() returns true (we'd also tried that path; same family of bug). The three spurious routeChangeNotification(.categoryChange) events also stop. Why it matters Declaring AppIntents this way registers the main app bundle itself as hosting an appintents-extension extension point. Even though no intent was being invoked, that registration appears to engage the audio HAL pipeline at app launch in a way that conflicts with AV

Thank you for the detailed responses and suggestions. I wanted to follow up with an update: we have identified the root cause of the issue. The problem was a FlutterFlow bug — not a StoreKit or RevenueCat configuration issue. FlutterFlow was generating the main.dart file with an empty string for the App Store API key, even after the key was correctly saved in the platform settings: await revenue_cat.initialize( , // ← App Store key was empty goog_XXXXXXXXXXXXXXXX, loadDataAfterLaunch: true, ); This caused the RevenueCat SDK to initialize with invalid credentials on iOS, returning INVALID_CREDENTIALS (code 11) on every call — including getOfferings() and purchasePackage(). The purchase action returned false not because of a StoreKit issue, but because the SDK was never properly authenticated. Workaround applied Since FlutterFlow does not expose main.dart for direct editing, we implemented a Custom Action called on pgSplash (first action on Page Load) that forces the correct API key at runtime, overrid

@ppwqgtl Thanks for the reply! To your questions first: yes, this started recently for us. And no, we haven't moved the app to a new dev team or changed anything about signing. On WKRunsIndependentlyOfCompanionApp: interesting, thanks for the info. We'll still try a TestFlight build with the flag set, just to be sure. But if you've already had that set to true, then dependent vs independent is probably not the root cause. A few updates from our end: One of our testers hit the exact same thing you originally described. They opened the watch app, it was frozen, they force-quit, and then it wouldn't launch at all. Same shape as your report. So now we have 2 states that resolve to the same thing. App won't launch, can either start with a frozen UI presenting on screen and subsequently cannot launch, or just doesn't present on screen at all. Rebooting the watch is enough to fix it. We don't even need to reinstall. That's a useful clue, because it rules out a lot of things - code signature, certif