Live Activity Shows Only Black Dynamic Island UI (No Content Rendering) — Widget Extension Receives Updates but SwiftUI UI Is Empty

Question

Created Nov ’25

Replies 4

Boosts 0

Participants 4

Hi all, very new "developer" trying to build my own app. The app works, just trying to improve it.

I’m implementing a Live Activity in a widget extension (Swift/SwiftUI) for an app built with Flutter as the host app. ActivityKit is functioning correctly—activities start, update, and end normally, and the widget extension receives all state updates.

However, the Live Activity UI renders as a completely black capsule (both compact and expanded Dynamic Island, as well as the Lock Screen presentation). The system shows the Live Activity container, but none of the SwiftUI content displays.

Verified so far:

ActivityAttributes contains at least one stored property (previously empty).

ContentState fully Codable + Hashable.

All Dynamic Island regions return visible test UI (Text/Image).

No .containerBackground() usage.

Added explicit .activityBackgroundTint() + system foreground colors.

All Swift files included in widget extension target.

No runtime errors, no decode failures, no SwiftUI logs.

Widget previews work.

Clean build, app reinstall, device reboot.

Entitlements and Info.plist appear valid.

Problem:

The widget extension returns a completely black UI on-device, despite valid SwiftUI content in ActivityConfiguration. The Live Activity “shell” renders, so the activity is recognized, but the widget’s view hierarchy is visually empty.

Question:

Under what conditions would a widget extension produce a black, empty UI for a Live Activity even when ActivityKit, previews, and the SwiftUI layout are correct? Are there known cases where:

Widget extension Info.plist misconfiguration,

Incorrect background/tint handling,

Rendering issues in Dynamic Island,

Host app integrations (Flutter),

Or extension isolation issues

cause valid SwiftUI to fail to render in a Live Activity?

Any guidance on deeper debugging steps or known system pitfalls would be appreciated.

Answer 1

beearmy OP

Nov ’25

The Live Activity does launch and when pressed takes user back into the correct app.

Answer 2

DTS Engineer OP

Apple

Nov ’25

Thanks for your post.

Although you have a comprehensive list of questions, such as tint handling without demonstrating the setup process, it appears that you are using Flutter instead of Xcode.

I recommend starting with a tutorial on LiveActivity and configuring it to observe its functionality and the rendering of the Activity UI. This step-by-step approach ensures that you have a thorough understanding of the process and can identify any potential issues. Even thought assumes you are using Xcode.

https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities

Also I would recommend to go to the 3rd party tool support channel and see if they have a sample or a tutorial to go over the issues. You should check with the support resources provided by the 3rd party to get assistance with their software.

Unless another developer in the forums has experience with the third-party and can provide assistance.

Albert Pascual   Worldwide Developer Relations.

Answer 3

beearmy OP

Nov ’25

Thanks for the reply! Just to clarify, even though the main app is built with Flutter, the Live Activity and widget extension are fully native Swift/SwiftUI and built in Xcode. The issue seems to be on the ActivityKit/WidgetKit side rather than the Flutter side.

I’ve gone through Apple’s Live Activity tutorial and everything works except the actual UI rendering (Dynamic Island shows a black capsule even though the regions contain simple Text/Image views with no errors).

I’m mainly hoping someone who’s run into a similar ActivityKit rendering issue can point out anything I may be missing in the widget extension setup. Any insights are appreciated!

Answer 4

henrikn OP

4h

Ran into the same thing and had Claude fix it.

Short version as I understand it is that I had just upgraded my dev account from free to paid, and it didn't rebuild the WidgetKit extension under the new paid profile.

Details from Claude:

I diagnosed this for a user whose app showed these exact symptoms — black Dynamic Island container (tapping it opened the app, so the activity existed), empty expanded view, and no Lock Screen presentation, with the widget extension's SwiftUI content never rendering. Clean builds, a DerivedData wipe, reinstalls, and a device reboot all failed to fix it.

The cause was a stale cached provisioning profile from a free-team era. The user had upgraded their personal Apple Developer membership from free to paid, which keeps the same Team ID — so Xcode's automatic signing saw no reason to regenerate cached profiles. Four of the app's targets carry entitlements (Family Controls, App Groups) whose provisioning needs changed with the upgrade, forcing fresh paid profiles; the WidgetKit extension needs no special entitlements, so Xcode silently reused its cached 7-day free-team profile from before the upgrade. Same team ID, technically valid signature — but the Live Activity would not render.

I found it by comparing the embedded profiles across the built app and all of its appexes:

  for P in Build/Products/Debug-iphoneos/YourApp.app{,/PlugIns/*.appex}; do
    echo "$P"; security cms -D -i "$P/embedded.mobileprovision" | grep -A1 -E "CreationDate|ExpirationDate"
  done

Four profiles showed ~1-year validity (fresh, paid); the widget extension's showed a ~7-day window created days earlier — the tell.

The fix: delete the stale profile from ~/Library/Developer/Xcode/UserData/Provisioning Profiles/ (identify it by security cms -D -i <file> | grep application-identifier), rebuild so Xcode mints a fresh profile, then delete the app from the device and reinstall. The Live Activity rendered immediately. (The same build also adopted .containerBackground(for: .widget) — recommended on iOS 17+ regardless — but the identical view code had rendered fine before the regression, so the profile was the operative fix.)

If you're hitting this: it's worth checking any time an app partially breaks after a free→paid upgrade or any team change that keeps the Team ID — Xcode only re-mints profiles for targets whose entitlement requirements changed, and quietly reuses stale cached profiles for the rest.