Here is a link to a small public github repo that contains two .zip files of the 2 implementations in small test project formats. There are some comments to point you all towards in the ContentView in each. Any insights are greatly appreciated!

Thanks for the reply! We added the enumerated list separately and used a local variable to do the looping in the list. The issue seems to persist. We've been trying to apply what you told us for the focusedValue but we don't see how it could be used in our case. In the FocusCookbook RecipeGrid.swift example provided, focusedValue is used to change the macOS commands that will appear to the user depending on the context provided (in this case a recipe). We don't see how applying focusedValue to our screen would solve our issue. We're already passing the focus state to each view in the List. Also, how would we change the onChange in there? To reiterate on our use case, we have multiple cells that the user can focus onto but we want for only one cell to be focused at a time. Because of that, we added a @FocusState property to the main screen and sent bindings to all the rows in our list, so they can summon focus for themselves and also have a way of blocking the other cells to regain focus. Could you be more specific on how could we apply focusedValue to our solution and what would it improve?

Hello thanks for your help in investigating this. Additional context here is that our application is Swift 6, SwiftUI only. The min deployment target was set at 17.0 and we only started witnessing this crash for iOS devices on 18.4+. I reviewed the documentation for debugging techniques linked. I believe the most relevant common crash referenced is a language exception. I verified that I have at least a partially symbolicated crash report via the presence of function names. Its hard to 100% confirm if it is a partial vs fully symbolicated as all the frames included in the crash are low level library/internal apple frameworks and I am not sure how much is supposed to be exposed. Some additional nuggets here is that the application is distributed via enterprise (so no crashes support in Xcode organizer / App Store Connect) and the crash is not easily reproduced (3 occurrences within the past 2 1/2 weeks). The steps list here to import a crash to the Devices and Simulators do not look to allow for drag and drop anymore. From the threads / error message witnessed in logging it (Cannot form weak reference to instance (%p) of ""class %s. It is possible that this object was ""over-released, or is in the process of deallocation.", (void*)referent, object_getClassName((id)referent))) seems related to 4 libobjc.A.dylib 0x000000019499acbc weak_register_no_lock + 396 in the obj-c runtime To me the threads/frames are all around internal frameworks. It seems like somehow it blew up when trying to layout constraints for a button in the view hierarchy deep between the inner workings of SwiftUI and the UIKit / obj-c layer.. One thing that sticks out is that thread 0 frame 35 is all question marks ??????. 35 ??? 0x00000001bdebbad8 0x0 + 7481309912 Could it signal that it was potentially a third party integration that initiated this chain of events. Or is that somewhat expected. Crash log as txt file Appreciate any guidance or insights you can provide!

FWIW here - we updated our app's minimum deployment target to be iOS 18 and we have not seen this issue anymore