After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering.
Is there a supported way to recover from this state without asking the user to reboot?
Configuration
- Device: iPhone18,1
- OS for the captured reproduction: iOS 27.0.1 (24A446)
- Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store.
- We have reproduced the issue with builds made using both Xcode 26 and Xcode 27.
- Deployment target: iOS 17.0
- The widget extension contains an
ActivityConfigurationfor Live Activities only, with no Home Screen widgets. - Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause.
Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post.
Steps to reproduce
- Install a build of the app containing the Live Activity widget extension.
- Update to a newer build through TestFlight.
- After the update completes, launch the app and start a Live Activity using
Activity.request(attributes:content:pushType: nil). - Check the Dynamic Island and Lock Screen.
This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed.
Expected and observed behavior
We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL.
Instead:
Activity.requestsucceeds andliveactivitiesdstarts the activity.- The Dynamic Island has an empty tappable area and the Lock Screen shows nothing.
- Tapping the empty area opens the app without the activity's
widgetURL. - Updating the activity's content does not restore rendering.
- After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting.
Relevant diagnostic observations
The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted.
During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension:
22:38:45.295 runningboardd
... RBSPreventLaunchLimitation ...
... com.example.internalapp.widgets ... com.example.internalapp ...
22:38:45.549 chronod [com.apple.chrono:extensions]
Ignoring restricted or unknown extension com.example.internalapp.widgets
22:38:47.178 installcoordinationd
-[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete!
22:38:47.292 chronod [com.apple.appinstallation:TransactionLog]
com.example.internalapp ... applicationsDidInstall
When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container:
22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager]
Starting activity: id: <activity-id>; ... state: active ...
22:40:41.254 chronod [com.apple.chrono:descriptor]
Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated
22:40:53.543 chronod [com.apple.chrono:descriptor]
Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated
22:40:55.707 chronod [com.apple.chrono:descriptor]
Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client
The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause.
We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related.
Questions
- Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update?
- Are there known TestFlight installation or extension configuration conditions that could explain this sequence?
- Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue?
The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.