The "immune" TestFlight users are still interesting to me. There are people who it never happens to, and others who get it frequently. My sample size is 10 people. 5 hit, 5 "immune". In the 5 immune, 3 have Apple Watch Ultras. In the 5 hit, none have Apple Watch Ultras. 99% likelihood that it's just coincidence... But I wonder if Carrot or one of the bigger TestFlight beta's can see any patterns in watch models with a larger sample size?

[quote='887896022, JacobJohnston, /thread/821989?answerId=887896022#887896022, /profile/JacobJohnston'] Jumping in to say I've also experienced the same issue over the last week. I was beating my head trying to understand what sort of bug I could have introduced, and then decided to check the forums here. [/quote] Wondering if all of us on this thread should start actively spreading the word to other watchOS developers that this is going on? (Given that Google search isn't getting updates since before we all piled in). Every Watch developer with the problem that shows up here helps to show Apple that this is widespread. And can be another linked feedback ticket.

[quote='887871022, ppwqgtl, /thread/821989?answerId=887871022#887871022, /profile/ppwqgtl'] @tph @developer555 And do you know if there are other victims or we are the only unlucky ones? [/quote] This thread is only indexed by Google up to April 11, so will be hard for others to find us currently.

Wow this is looking an awful lot like a watchOS regression was shipped into TestFlight itself. The next question is, why are we uniquely affected? Why isn't this thread swamped with other watchOS developers with our TestFlight issue? Is there something special about our apps' provisioning profiles? 🤔

It depends what you mean by “production”. Ad hoc is still distribution signing, so it can share production-like pieces such as the Apple Distribution certificate and production APNs environment. But it does not use the same App Store/TestFlight provisioning profile class. In our Bitrise setup, ad hoc export uses distribution_method: ad-hoc, while TestFlight/App Store export uses distribution_method: app-store. Bitrise and Apple docs both say ad hoc export uses an Ad Hoc provisioning profile tied to registered device UDIDs; App Store/TestFlight export uses an App Store Connect provisioning profile. So ad hoc working is encouraging, but it does not prove AppStore installs are safe.

Only been 6 hours, but early signs from our side that dropping TestFlight and doing Adhoc distribution outside of TestFlight fixes this issue. No one on the adhoc (non-TestFlight) build has experienced this issue at all yet. We'll keep monitoring, but our plan is to double down on this approach and wave goodbye to TestFlight. Obviously, it does still leave open the question of: what fixed things, ditching TestFlight or moving to adhoc signing? This is important because it's currently unknown for us if AppStore downloads would behave like TestFlight and our AppStore watch app users would be impacted at random. Very keen to hear from Apple engineers so we can resolve this uncertainty before going to AppStore.

Few updates from our side: We have 1 person internally who seems "immune" from this issue. They're also our longest standing watch app tester (the rest of our testers onboarded this week). We're getting sysdiagnose logs from the immune guy to see what's different. The sysdiagnose logs show TestFlight requesting the removal of profiles shortly before things stop working. We're going to try an experiment where we distribute the app internally outside of TestFlight. If this is a regression in TestFlight itself that should help. (Not a perfect apples to apples experiment, but what else can we do?) Will report back. We've opened a ticket here feedback/22765369

Small extra detail from our latest sysdiagnose, in case it helps compare notes. The suspicious part for us is that the same two Watch-side profile IDs appear to be installed during the TestFlight update, then removed a few minutes later. Rough sequence, with app/profile IDs masked: 16:30:51 - iPhone AppConduit sees as updated/trusted and starts the install path. 16:30:51 - iPhone AppConduit also logs: "ACXRemoteAppList ... App database is out of sync." 16:30:52 - iPhone/TestFlight asks the Watch for its provisioning profile list. 16:30:53 - iPhone/TestFlight requests two installProvisioningProfileWithData operations via AppConduit. 16:30:54 - Watch AppConduit installs profile . 16:30:54 - Watch AppConduit installs profile . 16:31:08 - Watch MobileInstallation starts installing the new Watch app bundle. 16:31:10 - Watch MobileInstallation reports the install succeeded for the new Watch app build. 16:31:11 - iPhone AppConduit marks as installed. 16:32:07 - The Watch app launches successfully after the update. 16:32:44 - iPhone AppConduit logs: "Database UUIDs and sequence numbers match! We're in sync." 16:35:09 - iPhone/TestFlight asks AppConduit for the Watch provisioning profile list again. 16:35:09 - iPhone appstored still reports as installed on the new build. 16:35:09 - iPhone/TestFlight asks AppConduit to remove . 16:35:09 - iPhone/TestFlight asks AppConduit to remove . 16:35:09 - Watch AppConduit removes . 16:35:09 - Watch AppConduit removes . Later - Watch app launch fails before our process starts with the Security / profile trust denial. Maybe this install-then-remove sequence is normal TestFlight cleanup behaviour and the profile IDs are not meant to correspond directly to the app’s embedded provisioning profile UUIDs. But it looks suspicious from the outside, because the Watch receives exactly two profile installs during the update path, the app installs and launches successfully, then a few minutes later TestFlight/AppConduit removes those same two Watch-side profile IDs while the Watch app is still installed. @ppwqgtl, if you still have the sysdiagnose from your affected watch/phone, it would be very interesting to check whether you see the same shape: Watch AppConduit: "_onQueue_handleInstallProfileMessage: Installing profile with UUID ..." Watch AppConduit: "_onQueue_handleRemoveProfileMessage: Removing profile with UUID ..." iPhone AppConduit: "removeProvisioningProfileWithID: Requested by TestFlight ..." Any nearby "App database is out of sync" lines. The thing we still cannot tell is whether TestFlight is correctly removing stale profiles, or incorrectly removing profiles the newly installed Watch app still needs.

@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 lines for us were AppConduit profile install/remove lines like: _onQueue_handleInstallProfileMessage: Installing profile with UUID ... _onQueue_handleRemoveProfileMessage: Removing profile with UUID ... removeProvisioningProfileWithID: Requested by TestFlight ... We also saw ACXRemoteAppList ... App database is out of sync during the install window. Your update makes us less confident that WatchConnectivity or silent pushes are the trigger. Our current best guess is now a TestFlight/AppConduit/watchOS beta-profile cleanup bug: after an update, old and new Watch app/complication profiles are both present, and TestFlight/AppConduit removes profiles in a way that leaves the installed Watch app without the profile it needs to launch. We still do not know why TestFlight decides those profiles are safe to remove. That is the key thing we need Apple to explain.

@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/device, then later became launch-denied locally. We no longer think “dependent vs independent watch app” is the main theory. It may still affect which Apple code paths are involved, but it does not look sufficient as the explanation. The more interesting lead for us is background iPhone-to-watch WatchConnectivity traffic. In our case, the production iOS app receives silent/background pushes and, during those background wakes, can proactively send updated state to the watch using WatchConnectivity while the watch app is not foregrounded. Our local debug build does not have the same production APNs background-wakeup path. The production/TestFlight watch app has hit this launch-denied state multiple times; the local debug watch app on the same hardware has not. So our current theory is: iOS app wakes in the background. It touches WatchConnectivity / AppConduit to find or update the paired watch app. This happens repeatedly while the watch app is suspended/backgrounded/not running. Some Apple-side paired-app database/cache becomes inconsistent. Later watch app launch is denied before our process starts. That is still only a theory, but it fits the AppConduit “database out of sync” log better than anything else we’ve found. A few questions that would be very useful to compare: Does your iOS app receive silent/background pushes? During those background wakes, do you send anything to the watch with WCSession, especially updateApplicationContext, transferUserInfo, or sendMessage? In your iPhone sysdiagnose, do you see AppConduit / ACXRemoteAppList / MobileInstallation logs near the failure window? Does a normal watch reboot actually fix it for you, or only reinstall? We are going to try reducing/removing proactive background iPhone-to-watch sends and see whether the issue stops reproducing. Once more into the deep !

@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, certificates, the TestFlight build itself. Any of those would still be broken after a reboot. So whatever's broken must live in caches or records that get rebuilt at boot. That fits with the AppConduit "App database is out of sync" error we shared earlier. And also matches the fact that this is some intermittent race case inside Apple's frameworks. We tested the watch app a lot in December and never saw this. It only started happening recently. The annoying part is we don't yet have a reliable way to trigger it, which means we can't git bisect our own changes. Finding repro steps is what we're working on next. The current theory we're kicking around: phone-to-watch WatchConnectivity sends that happen while the watch app isn't in the foreground - things like updateApplicationContext and transferUserInfo. Our research suggests that these force the iPhone side to look up the paired watch app every time, which touches the same database that's going out of sync. We added a few of these sends between December and now. It's the biggest change in how our watch app talks to WatchConnectivity over that window. One question back to you: does your app do similar phone-to-watch sends while the watch app isn't in the foreground? If yes, we might have a shared trigger, and that would narrow this down a lot. If no, our theory has a hole in it and we'll need to keep digging.

@ppwqgtl No confirmed solution yet, unfortunately. Reinstalling or rebooting is the only workaround we've found so far, but like you, we're worried the app could lose trust again later. To give a sense of scale: it's intermittent but extremely frequent - today ~10 people were TestFlight testing the watch app and it hit 3 of them. (I still need to get system diagnosis logs out of their watches and phones.) That said, if this were happening to most watchOS apps in TestFlight we'd expect to see far more public reports than just us. Our working theory is that being a dependent companion watch app - rather than an independent watchOS app - is what puts us on an edge-case code path. There are no public numbers on the dependent-vs-independent split, so we can't be sure, but directionally it's plausible. In 2026 independent watch apps could far outnumber dependent watch apps. One clue from our iPhone sysdiagnose: AppConduit / ACXRemoteAppList errors around the failure window, specifically "App database is out of sync." So our current suspicion isn't an app crash, but local Apple platform state going inconsistent between AppConduit / MobileInstallation / LaunchServices / trust evaluation for the paired watch app. That's what we're investigating next. A dependent watch app's launch depends on paired iPhone counterpart state, so we're considering testing a build with WKRunsIndependentlyOfCompanionApp=YES (while still keeping the iOS companion) to see whether removing that launch gate avoids whatever local state is going stale. It would be interesting to know whether your watch app is dependent or independent, and if so, whether your iOS sysdiagnose has any AppConduit / ACXRemoteAppList / MobileInstallation lines near the first failed launch? Finally, has your Feedback case made any progress?

We are seeing what looks like the same issue with our TestFlight watchOS app. In our case the watch app is paired with an iOS app and was installed from TestFlight. The watch app launched successfully earlier on the same device and same installed build, including from a complication, and successfully recorded/transferred data. Later, tapping the app icon or complication did nothing. We reproduced the failure from the Mac with devicectl device process launch and got: The application failed to launch. (com.apple.dt.CoreDeviceError error 10002) BundleIdentifier = FBSOpenApplicationServiceErrorDomain error 1: RequestDenied FBSOpenApplicationErrorDomain error 3: Security Unable to launch because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user. A few details that may be useful: The same TestFlight build had launched successfully earlier on the same watch. The app was still listed as installed by CoreDevice. The companion dev/watch build could still launch on the same watch. There was no app crash and no app startup log from the failed launch, so it appears to be denied before our process is created. The production complication extension still appeared to be present/running in sysdiagnose, but the main watch app launch was denied. Deleting and reinstalling from TestFlight fixed a previous occurrence for us. We also saw MobileInstallation/AppConduit logs showing the TestFlight watch app install succeeded and launch was explicitly enabled before the later launch denial. We have captured a sysdiagnose while the watch was still in the bad state, plus the devicectl launch JSON/log output. This looks consistent with the app becoming untrusted locally on watchOS/TestFlight after it had already been installed and launched successfully. I’m happy to file a Feedback with the sysdiagnose and share the Feedback ID here if that helps correlate this with the case above.