This was quite a pain point for me! I left it until most of my app was completed and I had the mind space to deal with the crashing.
I think we can all agree that there’s some pretty awesome stuff with SwifUI but that the debugging can be difficult.
In my opinion, I would say that this is a BUG. Here is my rationale:
-
If you wrap the presentationMode dismiss call in an asynchronous delay of about a half-second, you should find that the program will no longer crash.
DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) { self.presentationMode.wrappedValue.dismiss() } -
This suggests to me that the bug is an unexpected behaviour way down deep in how SwiftUI interfaces with all the other UIKit code to manage the various views. Depending on your actual code, you might find that if there is some minor complexity in the view, the crash actually will not happen. For example, if you are dismissing from a view to one that has a list, and that list is empty, you will get a crash without the asynchronous delay. On the other hand, if you have even just one entry in that list view, forcing a loop iteration to generate the parent view, you’ll see that the crash will not occur.
I’m not so sure how robust my solution of wrapping the dismiss call in a delay is. I have to test it much more. If you have ideas on this, please let me know! I’d be very happy to learn from you!