I got the same issue. I have a primary language DE with all screenshot submitted and other language FR where I also have specific screenshot. I did create a new language EN and added all needed screenshots (and double checked all other required fieds like what's new, etc). I can switch my primary language from DE to FR but not to newly create EN. From my point of view, what is needed is that all screenshot are submitted "for each version in this language" that means that even the published version also need to have the screenshot in that language (and is not using the one from the current Primary language). That means that, for some of us, it will need two update to change the language. A first one to add screenshot on the published version, and another one to switch primary language because you can't change default language on a published version. I think that is because, even if you can only change the primary language when preparing a new version, "The Primary Language will be immediately made available on App Store" as it is said on info (?) juste above the field.

Did you try to use the contentShape() modifier. .clipShape(#yourShape#) will clip the view but don't the modify the shape for hit testing. .contentShape(#yourShape#) will defines the content shape for hit testing.

Has mentionned by @archy88 for me replacing inner VStack with LazyVStack did fix the issue. Expect that will help some of you.         ScrollViewReader { scrollProxy in           ScrollView(.vertical) {               VStack (spacing: 0) {                   ForEach(parents) { parent in                       Text(parent.name)             .padding()                       LazyVStack (spacing: 0) { // With VStack Scroll issue                             ForEach(parent.childs) { child in                              ChildView(child)                 .id(child.uuid)                 .padding()             }           }           .id(parent.id)         }       }               Spacer()     }     .onAppear() {       if let selectedChild = selectedChild {         scrollProxy.scrollTo(selectedChild.uuid, anchor: .center)       }     }   }   .padding() }

Does Xcode 14.0 beta 4 did fix the issue for you ?

Since Xcode 14.0 beta 4, I have have a different error but still facing a black Widget on iOS 15.x

Perhaps only on some specific conditions? Zoomed display seems to produce a 320 x 693 screen size. Perhaps there is another setting that can make it switch to 390x844.

Thanks to geoffhackworth (https://twitter.com/geoffhackworth) it seems that Xcode-14 TestFlight builds are treated as Xcode 13 builds and are scaled to the 12/13 Pro layout. So the issue will only occurs for TestFlight build. Thank you geoffhackworth (https://twitter.com/geoffhackworth) More about this here: https://twitter.com/geoffhackworth/status/1573652281848905728

Same issue here. I have this warning even in the Widget Library Preview when adding a new Widget. I suppose there is something (like a prompt?) is missing in the beta 1 but can't see any related issue in the release notes.

It seems to be related to our projets. I tried the Emoji Rangers Apple sample code and there is not this warning on the widgets.

So same issue here. I missed a log message in the console: The widget background view is missing. Please ensure that you have called the `containerBackground(for: .widget) {…}` modifier in your widget view. Just add the new .containerBackground(for:) in your widget view and it will resolve the issue. https://developer.apple.com/videos/play/wwdc2023/10027?time=180

What about putting a big button calling a AppIntent that do nothing as background? I didn't try to put an overlay a button on another button but if it works it may be your solution. Otherwise you'll have to put some inactive buttons around your active button I think.

Hi! I have still exactly the same behavior on iOS 17 beta 4. It is absolutely unpredictable when the tap on an interactive item (button or toggle) will pass through and will open the app. I did put a background interactive button (with an intent) doing nothing to try to catch miss click. It improve behavior but some tap still open the app with no reason. It looks like a bug but I am afraid it will persist for a while... :(

I have still exactly the same behavior on iOS 17 beta 4. It is absolutely unpredictable when the tap on an interactive item (button or toggle) will pass through and will open the app. I did put a full size interactive background button (with an intent) doing nothing to try to catch missed click. It improve behavior but some tap still open the app with no reason. It looks like a bug but I am afraid it will persist for a while... :(

It seems to occurs less often with iOS 17 beta 5 but it still happens :(

OK! I have found solution by myself using the showsWidgetContainerBackground Environment Value. I don't detect directly the StandBy mode but I detect that the WidgetContainerBackground has been removed. In widgetRenderingMode fullColor that means its the StandBy mode. At least it's true currently in iOS 17.0 @Environment(\.showsWidgetContainerBackground) var showsWidgetContainerBackground @Environment(\.widgetRenderingMode) var widgetRenderingMode ... ZStack { // If ContainerBackground will be removed, show the light background if (!showsWidgetContainerBackground && widgetRenderingMode == .fullColor) { Color.white.opacity(0.1).cornerRadius(cornerRadius) } WidgetContentView() .containerBackground(for: .widget) { backgroundView(viewSize: panelSize) } }