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.

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!