With the posted code I just wanted to show the simplified principal structure of the views to get a better picture. Additionally, I have added an image to better illustrate the issue. No setting of widgetAccentedRenderingMode or widgetAccentable with considering widgetRenderingMode makes the contrast between the text and the image better. (When user has transparent mode enabled). And I have really played around a lot! You have mentioned the photos widget, this is the most similar to the one I have. They typically doesn't show any text. Very seldom there is a text but on a dark image. So I guess, they check if the image is dark and only in this case show a white text. What would you do in my case?

Thanks for your quick reply! However, this doesn't resolve the issue. In transparent mode all texts and also background colors (even when they are black) gets converted to white or a very light color, so there is no more contrast between the background (image) and text because it's not possible to add e.g. a black background behind the text to have it better readable. The only workarounds I have found is to darken the images, so that there is more contrast, what I want to avoid. Another option is to save the images with the rendered black texts as a single image object, then the contrast between texts and background images remain. However, I would prefer to have some native solutions within WidgetKit. ZStack { Image(...) // light coloured or white image VStack { Text("Normal") // text gets white or light coloured .foregroundStyle(Color.black) // gets white or very light coloured .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .bottomLeading) // .background(.black) // gets white or light coloured } }

I have filed a feedback report to get clarification from DTS FB17026528 Unfortunately no answer and "Recent similar reports: None".

So, what is the Apple recommended way in dealing with this? Using a type erased NSArray? @DTS Engineer

+1 Seeing the exact same issue The issue happens only on iPadOS 18. To reproduce the user has to open the popover on the iPad and then switch the app to the background (keeping the popover visible). Then the crash occurs. See FB16077587 for a sample project with instructions.

Thank you @Engineer! We were able to resolve the issue (in SwiftUI). The error was caused by presenting the PHPickerViewControllerRepresentable on an adaptiveSheetPresentationController that sometimes lead to the issue. We just had to remove the adaptiveSheetPresentationController and use a fullScreenCover instead. This fixed the issue.

Did you find the root cause, @evilmint45? I'm also facing this issue: https://forums.developer.apple.com/forums/thread/763520

The root cause of this issue that during the update of one view another update for the same view (and others) is triggered (cycle). So as described above you have to check what causes this cycle. To debug it : Start instruments. Under SwiftUI there's a row ‘View Properties’. Select it. Trigger the issue in the simulator and look at all updates that occur (you can switch between Summary, Updates, etc. when View Propertiesis selected). So you can find out which views or variables are being updated. Comment out the related updated views in SwiftUI and see which view and wich parts are causing it. Narrow it down by commenting out parts down your view hierarchy. When you have found the root cause. Find a way how to not trigger a cycle. In my case I used a UIViewRepresentableView with UIView.animate in the updateView(:) what was triggering the cycle.

Btw, also for me the forum is very slow and I have a good internet connection and using a one year old Mac.

I completly agree. Also for me the developer forum is a ghost town. I hope that with the new UX improvements in the forum some Apple engineers find there way here and contribute. The only way to create a vibrant developer community is when at least 5-10 Apple engineers reply to multiple posts on a daily basis. Then also other developers will get attracted and use this forum more often. Let‘s cross fingers that the enthusiasm that was put into the forum recently is continuing the next weeks and months and that other Apple engineers start to use the forum more frequently. But I guess most of them don’t have free time to answer questions here.

@samliu_QPA, I'm receiving the same crashes and can not reproduce them. Have you found a solution to fix this or can give me any hint to find the root cause?

Please file a bug report at https://feedbackassistant.apple.com/ Until now, there are less than 10 bug reports reported for this issue. Otherwise it will not get fixed soon.

Same with SmartlookAnalytics, see FB11506040

@Anton Turvo, thank you very much for your comment! I can see the same error in Console: Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName] MacOS error: -67030 unrecognized status -67030 from codesigning library 0x16b7ab000 +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]: 75: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.97uVqY/extracted/VisionBoard.app/PlugIns/IntentsExtension.appex : 0xe8008001 (An unknown error has occurred.) 0x16b7ab000 -[MIInstaller performInstallationWithError:]: Verification stage failed The solution you proposed to modify the contents of project.pbxprojand adding CodeSignOnCopy didn't work for me. I'm still facing the above error. However, I have found a workaround by enabling Copy only when installing in the main target of the app in the Embed App Extensions (in Build phases section). So, the extensions are not copied to the iOS device and the error is resolved as well.

@jsnee I'm facing the same problem, please have a look at FB10962213