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.

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

Everything is now up-to-date. Gracias.

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.

That is my question too @revoceci.

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.

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.

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.

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.

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.

Any update from Apple?

iOS 26 Beta 3 resolved the issue.

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.

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.

@OmarShahine have you had any luck with workarounds or your feedback? I see similar issue with app I am developing.