Could not launch app on watchOS downloaded from TestFlight

Does anyone have the same issue? Recently the app has been transferred to another developer account, not sure if it is related, this TestFlight version was rebuilt with the new team

This is indeed quite strange. Would you mind to file a feedback report, attach your sysdiagnose to the report, and then share your report ID here? I'd hope that looking into the sysdiagnose may find some hints about why the app became untrusted.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Thanks, I have filed feedback, Case-ID: 19339644

@ppwqgtl I have replied to you on the case number. Thanks

Albert
  Worldwide Developer Relations.

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 = <watch app bundle id> 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.

@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?

@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:

1. 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.

2. 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.

3. 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.

4. 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 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:

1. iOS app wakes in the background.
2. It touches WatchConnectivity / AppConduit to find or update the paired watch app.
3. This happens repeatedly while the watch app is suspended/backgrounded/not running.
4. Some Apple-side paired-app database/cache becomes inconsistent.
5. 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 !

@tph No, no silent pushes, we recently added event tracking that collects user actions in watch and send to phone via transferUserInfo, but it does not send anything when in background. It is a sports app, so just a workout processing background mode. And I even made a test build that does not have the event tracking feature, so WatchConnectivity might not be the reason.

And rebooting does not solve the problem, must delete and reinstall.

I did not find AppConduit / ACXRemoteAppList / MobileInstallation related logs, or maybe I am looking at the wrong place, can you tell me which file you saw these logs?

From our watch logs there is another message next to the untrusted line: "signature state: Profile Missing, reason: Provisioning Profile Not Found"

This kind of issue is hard to track the cause, it might took forever😂, what would cause the app lost the Provisioning Profile and become untrusted?

@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:

1. TestFlight installed our iOS app and paired Watch app build.
2. AppConduit/MobileInstallation reported the Watch app install succeeded.
3. The Watch app launched successfully once after the update.
4. A few minutes later, TestFlight queried installed beta Watch apps and found our Watch app still installed.
5. Immediately after that, TestFlight/appconduitd removed two Watch-side provisioning profiles.
6. 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.

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 <watch-app-bundle-id> 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 <watch-profile-id-1>.
• 16:30:54 - Watch AppConduit installs profile <watch-profile-id-2>.
• 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 <watch-app-bundle-id> 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 <watch-app-bundle-id> as installed on the new build.
• 16:35:09 - iPhone/TestFlight asks AppConduit to remove <watch-profile-id-1>.
• 16:35:09 - iPhone/TestFlight asks AppConduit to remove <watch-profile-id-2>.
• 16:35:09 - Watch AppConduit removes <watch-profile-id-1>.
• 16:35:09 - Watch AppConduit removes <watch-profile-id-2>.
• 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.

I’m seeing what appears to be the same issue with my watch app distributed through TestFlight.

For a small subset of users, the watch app icon stops opening entirely after the app has been installed and working for a while. Complications/widgets continue to work, but tapping the app icon does nothing. There’s no normal crash report.

I pulled a sysdiagnose from one affected user, and the watch logs showed repeated launch denials for the main watch app bundle with messages like:

• signature state: Profile Missing, reason: Provisioning Profile Not Found
• Unable to launch because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user
• cannot launch untrusted application

I also saw MobileInstallation log:

• _InstallProvisioningProfile: Could not install embedded profile: 0xe800801f (Attempted to install a Beta profile without the proper entitlement.)

What’s especially confusing is that:

• the same TestFlight build works fine on many other watches
• complications still work on affected watches
• reinstalling sometimes fixes it temporarily, then it can come back later

Have any of you pushed updates to the App Store/production version after seeing this? If so, did you see any similar issues there, or does this seem limited to TestFlight/beta installs? I’m trying to judge whether this is mainly a TestFlight/watch install-trust problem or something that could affect production users after an app update.

I really don't want to submit this update I've been working on to the App Store then have this be an issue for a huge number of users, so if anyone can reassure me on that it would be appreciated!

@tph I do see the installing and removing profile lines in AppConduit logs in mobile and watch But no "App database is out of sync."

@developer555 Does this start recently for you as well?

Few updates from our side:

1. 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.

2. 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.

3. We've opened a ticket here feedback/22765369

I will try delete testflight after install👌 Today the app just keep freezing for me

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.

Ad hoc working is encouraging at least, doesn't that use the production version of the provisioning profile?

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.

Ah that's right, I forgot they had separate provisioning profiles. Been a long time since I did an ad hoc build!

@developer555 @tph Deleting TestFlight seemed to be working as well, so far😄

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?

🤔

For me the issue starts in a very akward time. the time overlapped with our app team transfer and adding a huge feature to the app, I don't even know where to start😄.

Who knows it is caused by TestFlight?

@tph @developer555 And do you know if there are other victims or we are the only unlucky ones?

I dont see any related issue on the internet

@tph @developer555 And do you know if there are other victims or we are the only unlucky ones?

This thread is only indexed by Google up to April 11, so will be hard for others to find us currently.