Did you ever get any resolution on this? My application (on both iPad and macOS) began exhibiting this sort of severe shifting in both dimensions and it started around a year ago. This has made the app nigh unusable, but I haven't had the time to look into the problem It seems to be affecting many kinds of controls in both windows and model dialogs. Any hints about the source of the problem and potential fix would be greatly appreciated.

Ripping code out of the view piece-by-piece, I have discovered that removing all the gestures from my custom view eliminates the problem. This happens even if the gestures contain no code at all, and if there is only 1 gesture.

Somewhat remarkably, this happens even if the contents of the Button's perform method is just a print("clicked") to verify that the click was register. After that none of the sliders and steppers can be interacted with via the mouse.

Also, I used to be able to have multiple sections in the body of a view, but now I cannot? Wrapping them in a VStack or something else seems to make that compile, but then they don't look right anymore.

Just as an FYI to any readers... my "solution" to this problem was to provide a function on my object (i.e. an instance of a class) which owns the state data (i.e. an instance of a struct). The struct provides 2 functions, a non-mutating one which gets cached data via a key, and a second which is marked mutating. The second one checks the cache and returns the cached data (without modifying state), but if it is not in the cache it computes it and adds it to the cache (thereby modifying state). Only the owning object ever calls these two functions, and it does so from the method it exposes, first trying the non-mutating method and only calling the mutating method if the requested data was not in the cache. This is ugly and inefficient (multiple mutex locks are required), but appears to be forced upon me by the language / framework design. I would like to have a better solution. struct D { 		func get_cached(key: Int) -> ValueType { ... } 		mutating func create_cached(key: Int) -> ValueType { ... }		 // always causes a SwiftUI update } class A { 		var data : D 		func get_value(key: Int) { 				if let value = data.get_cached(key) { 						return value 				} 				else { 						return data.create_cached(key) 				} }

I have seen this problem several times as well. Usually when clicking on a NavigationLink it goes to the page, and then comes immediately back again. Sometimes twice! A couple of times I had figured out that there was a problem in the view I was navigating to, but with the case I'm seeing today it just seems to happen spontaneously sometimes, but going straight back into the link again works fine.

Yes, I had settled on a workaround much like your suggestion and the problem goes away. This might be a problem of specification, but it definitely violates the principle of least astonishment!! A highly questionable design decision, IMO.

I'm on the latest beta (3), and it happens with earlier versions too. There are a few example on StackOverflow of people having the same issue. I worked around it by removing the code from my init of A, and calling it explicitly from the init of B (and other places that need to make an A). The issue is that I don't want that code to execute twice, but the compiler seems to want to force me to initialize it in the declaration in B (without access to the argument I need) and then again in the init of B. By making the init of A lightweight, I don't care anymore... but now need a secondary step to ensure it is properly initialized.

Ah, there is far too much code to include here (and the fragility of SwiftUI to its context is probably its biggest issue). I've solved the problem by adding @State members which I recompute from the original data source using a Combine subscription.

I get an printed error telling me that it cannot init() the MTLCaptureManager in Mac Catalyst. I guess that answers that question.