Seeing the same thing and can't figure it out.Using `@EnvironmentObject`, but shouldn't matter.And can confirm changing orientation, and likely most environment value, does trigger `updateUIView` to call.

You've probably already solved this, but for anyone else having issues with slide transition.One thing to consider is that if the view you want to slide is already tightly bound inside the outer view,there's no room to slide around in. So it looks like it's not doing anything.

Any updates to this? I'm having the same issue. Xcode 12.2. My case the ScrollView has a vertical axes and I'm using the .updating gesture modifier to capture changes. Dragging the View inside the ScrollView horizontally works fine. Dragging the View inside the ScrollView vertically (same as the axes) calls updating exactly once, then the ScrollView takes over. Dragging starting horizontally then continuing vertically (like a J gesture) works fine, updating throughout the whole gesture. I would expect high priority gesture with .gesture mask would be what works, but it doesn't. I'm not sure how adding it simultaneously can be done without having access to the ScrollView's gesture.

It seems around 40G is the free space needed, at least on my Intel based MacBook. I tried with 37G free and it wasn't enough, tried with 41G and it now it's working.

Nevermind. Forgot the delegate's set through URLSession itself. However, the question is still sort of valid for things like setting the taskDescription.

The second example, @State var valueClass = VC() is not typically, or ever done. The "state" being created is the result of creating an object by VC() which is a reference (or pointer) to a VC object. It's a memory address and it won't change, even if the properties it holds do change. Since there's no change to it, the view doesn't update. Your third example @ObservedObject var valueClassObserved = VD() is also problematic and not typically done. ObservedObjects are intended to observe changes within objects not owned by the view. Here the object is being created and owned by the view. What you are looking for is either the first example, just using a @State and value type or @StateObject if you want to track an object that you create in the view. So in your example just change ObservedObject to StateObject. StateObject is intended to keep track of objects that are created and owned by the view. To summarize: If you are initializing the object inside your View code, use @StateObject. If it's initialized outside your View code, and you pass it as argument or otherwise, use @ObservedObject (or @EnvironmentObject, which is more convenient in global cases)

 TextField("enter text", text: $text)       .onChange(of: text) {         if $0 == "magic" { // use $0.lowercased() for case-insensitive           // do something         }    }

Try this. Where you initialize the LocationDetailViewModel() in the View, use @StateObject instead of @ObservedObject. Do that whenever the observed object belongs to the view. To contrast, if you want to share that object among other views (ie it doesn't belong to this View), keep it as an @ObservedObject and create and initialize it outside the view and pass it. Also, maybe keep the location and model together so it can update. So that all the state information is in the model and spread across the view and model.

I normally use the taskDescription as like a human-friendly description of the task for debug logs/console and the taskIdentifier more of a unique id for mapping and identifying. But I think you are right, since it's the only task property that is altered after init I can think of. It's not worth allowing setting it at the expense of complicating things which are otherwise very nicely done in Combine.

Awesome, I'm using the regular 12.4 release and this feature can wait. Thanks @BabyJ.

Don't pass the SwiftUI View to the coordinator. It is a struct and many copies of it are made as the screen is redrawn. Instead put the center location in an ObservableObject pass that and additionally, if you need it, a reference to the UIView itself (it is an object and only one copy is created. In your case you don't need use it because the delegate gives you the reference to the UIView, but often you do need your own reference). So make something like class MapState: ObservableObject { @Published var centre: CLLocationCoordiate2D? }. Have the SwiftUI View hold that, either as StateObject, ObservedObject or EnvironmentObject depending on where the object is made. Pass a reference of that object to the Coordinator. When the delegate calls, update that property and the @Published should send that back to the SwiftUI view to update.

Don't have a solution, but I'm experiencing a similar thing with the same setup. Compiling the files seems ok, but other steps are getting stuck often.

I don't have a definite answer on what the best practice is, but have wondered the same thing. In the past, I would return a Future. Now, I always return type-erased AnyPublisher. I find it keeps the interface more general, seems cleaner (standard) and, like you said, often it's easier to work. Besides, the type-erased Future returned as AnyPublisher is still going to finish after one output.