Hey Simon. I did try pairing my .intentdefintion file down to the bone and removing just a ton of other code to maybe create an Apple bug report. No help. I will add that my watch and iOS widget code is identical save some conditionalization on widgets to include. I never had any issues with old style recommendations I created and even a sample is still shown. Just the screen to configure gives the "unable to load." Yes, I started migrating to WidgetConfigurationIntent and AppEnum. I was looking for samples to verify configurability on Apple Watch and found a good Medium artcie, but the source code was not directly downloadable. So I created at: https://github.com/t9mike/SimpleStatsWidgetConfigExample But I changed the Water Reminder example to use AppEnum to simplify how the frequency parameter is defined. This does work on Apple Watch no problem.

I am assuming there is a bug in handling .intentdefinition files on watchOS vs iOS/iPadOS. I am going to migrate all my widget configuration to code-based WidgetConfigurationIntent.

iOS 26 Beta 3 resolved the issue.

Any update from Apple?

showswidgetcontainerbackground is iOS15+ according to Apple's docs. But I am seeing crash "Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)" when run on iOS16. I have FB open on this: FB12554533 (showsWidgetContainerBackground Environment variable crashes widget extension on iOS16 with Xcode 15) I was tabling this issue for a few weeks in hopes it gets resolved. Feels like a bug that would hit a lot of people. But perhaps how I am using it is triggering the crash.

Check your runtime warnings in Xcode. I have seen it tell me the SwiftUI environment variables can only be used in a view. In my widgets I already have a wrapper view to handle a lot of common things & bootstrap. I have a view "WidgetSetStuff" that sets global variables -- or it could adjust a class object passed in. struct WidgetEntryView : View { ... @Environment(\.widgetFamily) var widgetFamily @Environment(\.showsWidgetContainerBackground) var showsWidgetContainerBackground var body: some View { ... WidgetSetStuff( family: widgetFamily, noMargins: showsWidgetContainerBackground == false, ... ) ... } WidgetSetStuff constructor sets some globals use elsewhere and has EmptyView() body.

Two of my previous builds made it into TestFlight! One from Wednesday evening and the other from yesterday afternoon. One from this morning did not. Interesting that the Upload timestamp in metadata on the TestFlight tab shows just now. I guess that is process time and not true user upload time.

Yes my new build never did finish processing and stayed "disappeared." I am happy to test upload when you deploy an update. Perhaps something about certain build contents is triggering the issue? FWIW my iOS/iPad app has widget and watch extension. Sundial id976460540.

I've gone ahead and uploaded new version. Showed up as processing for a few minutes in the Web UI. But then disappeared. I am going to take a walk and will check when back.

That is my question too @revoceci.

Yes the UI is terrible. I have a Feedback to allow long press on widget to edit. Crazy it is not supported. I am making a video for my users because I find it so non-intuitive. I encourage everyone to file a FB requesting long press to initiate edit support. My original question was when the intent system was going to be supported on lock screen widgets. It took many betas for it to be added.

Everything is now up-to-date. Gracias.

Oops. Newb to these forums and answered instead of commented below.

Thanks @BabyJ. This one is frustrating because if I could just have a crownSequencer, I could avoid the SwiftUI front-end to the digital crown and I think everything would be much easier. But that is unavailable when using SwiftUI AFAICT.