Paul HudsonMaking two views match sizes in SwiftUI is surprisingly simple: give each an infinite max frame in the direction you want, then apply fixedSize() to the container. No GeometryReader required. See how it works: https://www.hackingwithswift.com/quick-start/swiftui/how-to-make-two-views-the-same-width-or-height
Kristof Van Landschoot@twostraws I always wonder about these things, is that just the way it behaves or is that a contract for the future? Who says iOS 27 will keep this behavior?
Jamie Froggatt@ristkof @twostraws Sad to say this is the contract…
`.fixedSize` forces a view to use its 'ideal size', per the docs. Its name just defies user expectations.
`.frame` is also badly named, as it technically allows overriding the size proposal a view offers to its container, the documented layout system.
Views take all the available space the container offers, up to their max width, but ideal size kicks in when space is unbounded, like scrollviews or when using fixedSize…
Think:
- `fixedSize` ignores container limits.
- `idealWidth`/`idealHeight` means that dimension when no container limits apply. (Meaning it's a fallback value, while maxWidth is treated like an ideal for a bounded canvas)
- `frame` means override the size proposal to the container.
Kyle Bashour@twostraws how do you prevent the container from expanding beyond it’s container when the views end up quite wide, though? I couldn’t figure that essential piece out
@twostraws _Actually_ this makes total sense if you know that SwiftUI containers offer a size proposal to their subviews which they refine and communicate back up to the containers which then loops back around for a final pass before deciding the actual sizes. Have you never even _tried_ reading the docs for each individual method requirement of the Layout protocol? 🧐
Seriously though, sometimes I miss constraints.