Sorry! I also could not see what was happening in this thread, since there is no notification system or even an ability to see what conversations a person has participated in, haha.
If you change your target, then remove the @if flags around it, usually that will help. At that point, clear your build cache and derived data and reopen the project. If you still can't get it to happen, you may be stuck for now by nature of some piece of older code in your project that is simply too complex to check with the way the preview system works.
The good news is that if you are using the Xcode beta, incremental builds and running is so fast now that you can probably continue to get work done without those previews and still have an excellent experience. In fact, even when I have access, I'll frequently hide the preview window.
natlaw
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
From
Columbia, MO, United States
Post
Replies
Boosts
Views
Activity
What's the iOS version attached to your build target? If you boost to 14, does this go away?
A very common reason I've seen this happen in older projects is that SwiftUI Previewing just does not seem to support code tucked behind older iOS versions and #if flags.
It sounds a little like you may somehow be preserving the fact that the user has navigated into that detail page, then when the user goes back to the page before, that information somehow does not get updated, so when SwiftUI updates your UI after the fetch request has completed, it just navigates the user back to where it thinks they belong.
To explore how this could be happening, we'd probably need to see some code, but perhaps this can give you a starting point of what to explore already.
In this case, the initializer you are using has this method signature:
List<Data, RowContent>(_ data: Data, selection: Binding<SelectionValue?>?, rowContent: @escaping (Data.Element) -> RowContent) where Content == ForEach<Data, Data.Element.ID, HStack<RowContent>>, Data : RandomAccessCollection, RowContent : View, Data.Element : Identifiable
And the glitch you're experiencing comes from the type selection expects. You're binding it to the state of selectedFooBar, which is of type FooBar (Binding<FooBar>), but it actually takes a binding of an optional value (Binding<FooBar?>). So if you change line 13 to read @State var selectedFooBar: FooBar? = .bar, you should be back on track!
It seems to me that control statements in general are breaking data binding. And this in my opinion is a show stopper. I'd love to explore this further with you if you're still around, abzy! There are some gotchas to working with control statements, especially in situations like this, where the types of views you are passing in get involved, but they generally do not break data binding at all as long as you're aware of how the views are being used.
In the example above, I think the big problem is that when you loop over an object in SwiftUI, you need it to return something every single time. This is sort of a consequence of the way that Swift's syntax around builders works. So wrapping it in something like a group or stack works, but it would also work to wrap it in a special kind of view that actually does have the power to contain any number of elements, and you do that with @ViewBuilder.
So you could make something like:
struct ConditionalTwoControl: View {
@Binding var effect: TwoControlEffect
@ViewBuilder var body: some View {
if effect.isDisplayed {
TwoControlTemplate(title: "Low Pass Filter",
																	 isBypassed: $effect.isBypassed,
																	 knobModel1: $effect.control1,
																	 knobModel2: $effect.control2)
}
}
}
and then have that ForEach look like:
ForEach(noise.twoControlEffects.indices){ i in
		 ConditionalTwoControl(effect: self.$noise.twoControlEffects[i])
}
And this would also work (with a little situational tweaking, of course).
More at hand to the situation here, I would consider trying to avoid looping over just an index if you can find a way around that, especially if you can just make your object conform to Identifiable. That's going to give you much more straightforward results with much more trace-able data binding.