That's... odd 😳 The playground code was extracted from a WIP app that was exhibiting the same behaviour... I'm using the same Xcode build as you but my macOS is actually the beta (12.2 21D5039d). Perhaps that's the culprit? I'll check on my other machine that runs 12.1 and report back! Thanks for the input!

Ah kk. Just for the record I did go ahead and test and I get the same result both on 12.1 and 12.2, both in playgrounds and when built as an app, using either the multiplatform or macOS templates.

I actually tried that. Problem here is that it does act intuitively on iOS (last item is pulled all the way up, leaving an unsightly gap) 😅 I guess I could just conditional my way around it but I'm way too deep in this rabbit hole at this point. I found that anchor takes a UnitPoint, which the docs don't disclose much about ("No overview available")... Anyways... I dug deeper and it looks like UnitPoint basically represents relative (0-1 range) xy coordinates from the top-left corner (maybe top-right for right-to-left languages? idk); but UnitPoint.bottom == UnitPoint(x: 0.5, y: 1.0) and UnitPoint.top == UnitPoint(x: 0.5, y: 0.0). So... I put a GeometryReader in the .background of the TextField in the safeAreaInset (putting it at the top-level of the safeAreaInset resulted in it taking the entire 400x400 frame). To convert the geometry to the relative coordinates scrollTo expects I divided the TextField's minY and midX by 400. This almost resulted in the expected behaviour but here's the weird thing: minY on iOS is 346 but on macOS it's 352. Ok, that makes sense since the views aren't 100% identical between the platforms. However, only the result based on the iOS reading (346 if you're following) looked correct on macOS. The result from macOS (352), still anchored too low. Phew that's a bit much. Hopefully I have time to update the code and post some screenshots to show what I mean.

Same issue with Xcode 16 beta and 16.1 beta 😩