One of the modifiers that always puzzled me a bit was .aspectRatio. How does it really work? Once I figured it out, it turned out to be simpler than I thought.
One place where we can find out a lot about how SwiftUI works is SwiftUI’s .swiftinterface file. This is located inside of Xcode. Inside your Terminal, go to /Applications/Xcode.app, and perform the following command:
find . -path "*/SwiftUI\.framework*swiftinterface"
There are a few variants of the .aspectRatio API, but they all boil down to a single implementation:
func aspectRatio(_ aspectRatio: CGFloat?, contentMode: ContentMode) -> some View {
}
The variant with CGSize just calls this method with size.width/size.height, and .scaledToFit and .scaledToFill call this method with the respective content modes and an aspectRatio of nil.
When we call aspectRatio with a fixed aspect ratio, e.g. .aspectRatio(16/9, contentMode: .fit), the aspect ratio implementation takes the proposed size, and proposes a new size to its child. When the content mode is .fit, it fits a rectangle with the desired aspect ratio inside the proposed size. For example, when you propose 100×100, it will propose 100×56.2 to its child. When you choose .fill instead, it will propose 177.8×100 to its child instead.
I figured out this behavior by printing the proposed sizes. More on that below.
Perhaps the most common use of aspectRatio is combined with a resizable image, like so:
Image("test")
.resizable()
.aspectRatio(contentMode: .fit)
This will draw the image to fit within the proposed size. Note that we do not specify the actual aspect ratio: it is derived from the underlying image.
When we don’t specify a fixed aspect ratio but use nil for the parameter, the aspect ratio modifier looks at the ideal size of the underlying view. This means it simply proposes nil×nil to the underlying view, and uses the result of that to determine the aspect ratio. For example, when the image reports its ideal size as 100×50, the computed aspect ratio is 100/50.
The process then continues like before: when the view was proposed 320×480, the image will be sized to 320×160 when the content mode is set to .fit, and 960×480 when the content mode is set to .fill.
Figuring out proposed sizes
Proposed sizes are not part of the public API of SwiftUI. Even though you absolutely need to understand how this works in order to write effective layouts, this isn’t really documented. The only official place where this behavior is described is in the excellent 2019 WWDC talk Building Custom Views with SwiftUI.
However, there is a hack to do this. Inside the interface file mentioned above, I searched for “ProposedSize” and found a protocol named _ArchivableView which allows us to override sizeThatFits:
struct MySample: _ArchivableView {
var body: some View {
Rectangle()
}
func sizeThatFits(in proposedSize: _ProposedSize) -> CGSize {
print(proposedSize.pretty)
return proposedSize.orDefault
}
}
We can now simply construct a MySample with an aspect ratio and print the result. Instead of a .frame, you can also use .fixedSize() to propose nil for the width and/or height. Likewise, try leaving out the first parameter and see how .aspectRatio proposes nil to figure out the ideal size of its child view.
MySample()
.aspectRatio(100/50, contentMode: .fill)
.frame(width: 320, height: 480)
Unfortunately the width and height properties on _ProposedSize aren’t visible in the swift interface, so I had to use introspection to print those (and also add a few helper methods like .pretty and .orDefault). The full code is in a gist.
If you want to learn more about how SwiftUI works, read our book Thinking in SwiftUI. When your company is already building things in SwiftUI — or is about to get started — consider booking a SwiftUI Workshop for your team.