Avoid using GeometryReaders in your main view tree. To measure views, place GeometryReaders inside of a .background or .overlay and communicate the size up through a Preference or other methods.
GeometryReaders always fill all of their proposed size, essentially overriding the layout behavior of the views they wrap. They also override the children’s ideal size.
Usage of .background or .overlay is recommended because the content of these modifiers doesn’t affect the layout of the parent view, so this limits the GR’s impact while still allowing you to measure the parent view final size (note this can be different from the proposed size).
// Good: Measure final size of Text without affecting its layout
Text("Sample text")
.background { // Size proposed to this will be the final size of the Text view
GeometryReader { proxy in
Color.clear.preference(key: SizePreferenceKey.self, value: proxy.size)
}
}
.onPreferenceChange(SizePreferenceKey.self) { size in
// Do things with the measured size
}
private struct SizePreferenceKey: PreferenceKey {
static var defaultValue: CGSize = .zero
static func reduce(value: inout CGSize, nextValue: () -> CGSize) {
value = nextValue()
}
}
// Bad: We measure size proposed to the Text view, but the GeometryReader won't fit the text.
GeometryReader { proxy in
Text("Sample text")
}
There are cases where you may need to read the size proposed to a view instead of the final size (for example to do custom proportional layout). In these cases, first consider if a combination of stacks, spacers and frames can be used instead.
If you absolutely need the GeometryReader, expanding to fill the dimension you want to measure is unavoidable.
Let’s say you want to ensure a view’s width is always 0.65x of the proposed width and the height is self sized.
Wrap a GeometryReader in a frame, constraining the dimension you don’t care about.
GeometryReader { proxy in
...
}
.frame(height: 0) // The GeometryReader won't fill all proposed height
Note that if you place your content inside of this GeometryReader, as far as the GeometryReader’s parent is concerned, the height will always be 0. This can cause layout issues because the inner view will render out of bounds.
GeometryReader { proxy in
Rectangle()
// The Rectangle will take 20pts, but this height will be ignored by the layout system.
.frame(width: proxy.size.width * 0.65, height: 20)
}
.frame(height: 0)
This is caused by the .frame we used to constrain the GeometryReader to 0 height. To get the benefits of a height-constrained GeometryReader and a correctly sized content view, you can place the GeometryReader in a ZStack and bubble up its measurement. Combined with the previous method, this means:
Note that a ZStack will match the size of its largest child in each dimension, so it will still fill all width due to the contained GeometryReader.
// The Rectangle will have a width proportional to the proposed width without taking up all the proposed height.
// This is a two pass layout
@State var availableWidth: CGFloat = 0
ZStack {
GeometryReader { proxy in
Color.clear.preference(key: WidthPreferenceKey.self,
value: proxy.size.width)
}
.frame(height: 0)
.onPreferenceChange(WidthPreferenceKey.self) { newWidth in
availableWidth = newWidth
}
Rectangle()
.frame(width: availableWidth * 0.65, height: 20)
}
If your inner view is flexible and wants to span the proposed height anyways, the ZStack trick is unnecessary.
You will find that the GeometryReader aligns the smaller inner view based on undocumented logic (top-leading as of 5/20/22). To make the alignment explicit and customizable, wrap your view in essentially a passthrough frame with an explicit alignment parameter.
// This view will span the proposed width and height
// The Rectangle will span the proposed height and take 0.65x of the proposed width.
// It will be centered in the proposed width.
GeometryReader { proxy in
Rectangle()
.frame(width: proxy.size.width * 0.65)
// This frame has the same sizing behavior as the GeometryReader, but allows you to change the alignment.
.frame(width: proxy.size.width,
height: proxy.size.height,
alignment: .center)
}
Use native Text instead of a UIViewRepresentable containing a UILabel whenever possible.
SwiftUI-UIKit layout bridging is heavily dependent on intrinsicContentSize. UILabel calculates this size in a special way, taking its preferredMaxLayoutWidth into consideration to determine how many lines the label will need. In an Auto Layout environment this property is set automatically, but it won’t be set by SwiftUI. This results in incorrect sizing for multiline UILabels when used in SwiftUI. The native Text doesn’t suffer from these problems and takes the proposed width into consideration during a layout pass.
There are cases where the use of UILabel is unavoidable, for example attributed text, which has only been supported in SwiftUI since iOS 15. In these cases you need to ensure preferredMaxLayoutWidth is set to the correct value. There are multiple methods of doing this:
@Binding, making sure to update the UILabel in the representable’s updateUIView function.GeometryReader to measure the relevant views. See the GeometryReader sections for details.