Live Activity works perfectly on Simulator but fails on physical device: "No asset provider bundle ID provided"

Thanks for the post. This is very interesting.

Since the Live Activity works perfectly on the Simulator but fails on a physical device with the error "No asset provider bundle ID provided" and entitlement warnings, this heavily points to a Code Signing / Provisioning Profile mismatch in my modest opinion.

The error "No asset provider bundle ID provided" often means liveactivitiesd cannot trace the extension back to its host app to fetch the required assets (like the App Icon). Go to your Main App Target in Xcode and select the General tab. Scroll down to Frameworks, Libraries, and Embedded Content and make sure your Widget Extension is listed here. If it is missing, the physical device won't install the extension properly alongside the app. It should be set to Embed Without Signing?

Because the error explicitly mentions is not entitled to specify a scene target, your provisioning profile might be missing the implicit entitlements required. Ensure your App ID has the correct capabilities enabled.

If you are starting the activity with a push token you must have the Push Notifications capability enabled.

The Simulator is very forgiving with memory and payload sizes, but physical devices are strictly enforced the context must not exceed 4KB (let me check on that number). If you are passing large strings, raw image data, or deep nested objects in your attributes, the device will silently fail to start the activity or throw obscure daemon errors.

Let me know how the exploration goes and if we need to check the project step by step. There are a few resources I always recommend to go over.

https://developer.apple.com/design/human-interface-guidelines/live-activities/

Albert Pascual
  Worldwide Developer Relations.

Similar post: https://developer.apple.com/forums/thread/787053

Hi Albert,

Thank you so much for the detailed response and the excellent pointers! I deeply appreciate you taking the time to look into this.

I went through your suggestions step-by-step:

Embedded Content & Code Signing: I verified that the Widget Extension is correctly listed under Frameworks, Libraries, and Embedded Content. By inspecting the compiled app container, I confirmed the .appex is successfully sitting inside the PlugIns folder.

Push Notifications Capability: Great catch. I added the Push Notifications capability to the main app target. Unfortunately, the behavior remained the same.

4KB Limit: For testing, I am using an absolute minimal payload (just a single short string and an integer) and a barebones Text("Test") UI, so we are well under the limit.

However, we ran some aggressive isolation tests over the weekend and discovered something fascinating that points to a completely different root cause. Here is what we found:

Completely New Minimal App: We created a brand new, minimal iOS project and pasted our exact same Live Activity code. It worked perfectly on the physical device. (This rules out any device/OS-level hardware bugs).

Direct Invocation: Inside our main app, we bypassed all complex logic (like AVFoundation/Camera views) and triggered Activity.request directly from a simple button on the initial Home screen. It still failed. (This rules out our calling code/SwiftUI context).

Build Dependencies: We scrubbed the build logs and confirmed the Explicit dependency is intact, and Xcode is perfectly building, signing, and embedding the widget for the physical device.

The Breakthrough (Bundle ID Change): We temporarily changed the main app and widget Bundle IDs (e.g., from com.mycompany.app to com.mycompany.app.test), deleted the app, restarted the iPhone, and rebuilt. The No asset provider bundle ID provided error completely disappeared.

When testing with the temporary Bundle ID, liveactivitiesd finally tried to mount the extension! It eventually threw a Public XPC connection invalidated error (likely because we temporarily stripped out the dummy widget and triggered the iOS 17 transparency bug, or due to a missing App Group on the new ID), but the core asset provider error was gone.

My new question based on this: Is it possible that liveactivitiesd or ExtensionKit heavily caches invalid states, or aggressively "quarantines/blacklists" a Bundle ID if it previously crashed or failed to mount on a specific physical device? Since this is an existing App Store app, it feels like the physical device's OS is holding onto a corrupted cache for our specific Bundle ID, blindly refusing to acknowledge it as a valid asset provider anymore.

If iOS does quarantine Bundle IDs like this, is there a way to forcefully purge this daemon cache for a specific Bundle ID during development, short of completely factory resetting the physical device?

Any insights into this specific caching or quarantine behavior would be incredibly helpful. Thank you again!

Just a quick follow-up to my previous post with a new discovery that unfortunately invalidates my "daemon caching/quarantine" theory.

It turns out the temporary Bundle ID test (.test) was a false positive. Because the temporary ID wasn't linked to our production backend services and entitlements (like RevenueCat, CloudKit, etc.), the extension crashed immediately upon launch, throwing a Public XPC connection invalidated error.

Because the XPC connection died so early in the lifecycle, liveactivitiesd simply never reached the stage where it attempts to resolve the asset provider. So, the No asset provider error didn't disappear because a cache was cleared; it disappeared because the process didn't survive long enough to trigger it.

We are officially back to square one.

To rule out a few other obscure Xcode build traps, I have also double-checked the following:

Info.plist Generation: Ensured Generate Info.plist File is not overwriting our manual NSSupportsLiveActivities flag. The flag is 100% making it into the compiled binaries for both the app and the widget.

Version/Build Strings: Verified that the Version and Build numbers between the main app and the widget are exact string matches (e.g., both "2.0" and "1"), with no hidden type mismatches.

NSExtension: Verified the widget's Info.plist correctly contains NSExtensionPointIdentifier set to com.apple.widgetkit-extension.

Given that the payload is tiny, the capabilities (including Push) are correct, the binary is embedded and signed, and the Simulator works flawlessly... what else could cause the physical device's OS to fail to link the extension to the host app's assets?

Still scratching my head over this one. Any deeper OS-level insights would be a lifesaver.