Modifiers, grids, and a layout of your own

The console showed

ModifiedContent<ModifiedContent<Text, _PaddingLayout>, _BackgroundStyleModifier<Color>>
ModifiedContent<ModifiedContent<Text, _BackgroundStyleModifier<Color>>, _PaddingLayout>
ModifiedContent<Text, Tile>

The answer is in the types. A modifier does not change a view. It returns a new one, ModifiedContent, that holds the old view and the modifier. Apple: "Modifiers return a view that wraps the original view and replaces it in the view hierarchy." Chain two and you get one ModifiedContent inside another, and the order you wrote them in is the order of the nesting. Every layer then becomes nodes of its own in SwiftUI's graph: Inside the Attribute Graph shows the sixteen that one chain of four makes.

Read the first line from the inside out: a Text; that text in a padding; that padded text in a background. The second line has the same three parts nested the other way: the text in a background, and that in a padding. They are different types, so they are different views, and nobody should be surprised that they look different. The interview-preparation repository's whole answer is this: "Each modifier wraps the previous view in a new one."

The third line shows what your own modifier is: exactly the same thing. Text("Seattle").modifier(Tile()) is a ModifiedContent<Text, Tile>. The three modifiers inside Tile are its business; from outside it is one wrapper, like padding.

Two practical rules follow. Read a chain from the top down, saying "…and that is put in…" at each dot. And when a modifier seems to do nothing, ask which view it is on: it is usually on a wrapper that was not the one you meant.

Where this comes from: Configuring views · ViewModifier · Senior iOS Interview Preparation (GitHub) — Apple, “Configuring views”: "The order in which you apply modifiers matters."

The first text is large and the second is red: in both, the modifier written first wins. The third has both paddings and both backgrounds.

The third is the plain case. Padding and background wrap the view, and wrapping twice gives two wrappers: a yellow box with an orange frame round it. Nothing is overridden, because there is nothing to override.

.font and .foregroundStyle do not wrap the text in anything visible. They set a value for everything inside the view they are put on, and a view that needs a font uses the nearest one. Apple: "The effects of a modifier propagate to child views that don't explicitly override the modifier." In .font(.largeTitle).font(.caption) the large title is nearer to the text, so the caption — one wrapper further out — never reaches it.

The rule is the one you already use without thinking about it: a font on a VStack is a default for its texts, and a text with its own font keeps it. Writing the two on one view is the same thing, with nothing in between. It matters in real code when a modifier of your own sets a font or a color: a caller who adds .font(…) after your modifier is setting a default that your modifier's font has already overridden.

Where this comes from: Configuring views — Apple, “Configuring views”, section “Configure child views”.

Tapped beside the digit, or in the gap, five of the ten printed:

3
5
6
7
10

Tapped on the digit itself — or, for the last two, on the word at the leading end — all ten did:

1
2
3
4
5
6
7
8
9
10

So every one of them works when you hit the text, and half of them have a tap area smaller than the box you can see. The rule: a gesture answers where its view draws something.

How near is near enough? A finger is not a point, and SwiftUI allows for that. In a further run, nine copies of a word with a tap gesture were each tapped once, a little further beyond the end of the word each time:

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack(spacing: 0) {
            ForEach([4, 8, 12, 16, 20, 24, 28, 32, 36], id: \.self) { distance in
                Text("Tap")
                    .onTapGesture { print("hit, \(distance) points beyond the word") }
                    .frame(height: 60)
            }
            Spacer()
        }
    }
}

The console showed

hit, 4 points beyond the word
hit, 8 points beyond the word
hit, 12 points beyond the word
hit, 16 points beyond the word
hit, 20 points beyond the word

Up to 20 points beyond the word the tap still counted, and from 24 points it did not. So a label with a little padding seems to work without any help, which is how this bug hides: it appears when the empty part is wide.

Rows 2, 8 and 9 are the ones that reach production: a padded label, a custom-looking button, a list row with a gap in it, each of which "only works if you tap the text". The cure is the same one line every time, placed after the padding and before the gesture: .contentShape(Rectangle()). Apple's description of it is a single sentence: it "defines the content shape for hit testing."

And prefer row 7 to all of them. A Button tells VoiceOver that it is a button, shows that it is being pressed, and can be disabled; a text with a tap gesture does none of that.

Where this comes from: contentShape(_:eoFill:) · Human Interface Guidelines: Buttons — Apple, contentShape(_:eoFill:). The Human Interface Guidelines ask for "a hit region of at least 44x44 pt".

All five were tapped. The console showed

d was tapped
e was tapped

Only the last two. In the first three the tap never reached the button, and nothing on the screen says why.

The picture is three wide to two tall, so to fill a strip 180 points wide it is 120 points tall — not 50. It overflows its frame by 35 points above and below. clipShape and clipped() stop that overflow from being drawn. They do not stop it from being there: the invisible top of each picture lies over the button above it, and takes the touch. The proof asked the running app for the frame of each picture, as the accessibility system sees it: about 120 points tall for every one except d, which is 50.

Row c is the layout-safe recipe from lesson 8's edge cases, a clear color with the picture as its overlay. It fixes the layout and has the same blind spot: the overlay overflows too.

The fix is to say which shape takes touches. Row d adds .contentShape(Rectangle()), which makes that shape the frame. Row e uses .allowsHitTesting(false), which takes the picture out of hit testing altogether — the right choice when the picture has no gesture of its own.

This one is worth remembering in the words of the bug report it produces: "the button above the image only works if you tap its top half." Whenever a picture is filled and clipped, give it a content shape.

Where this comes from: contentShape(_:eoFill:) · clipped(antialiased:) · Fitting images into available space — Apple, contentShape(_:eoFill:): "Defines the content shape for hit testing." And clipped(antialiased:), which speaks only of what is visible: "content that extends beyond the edges of the frame is still visible" by default.

Count A: 0 and Count B: 2. The counter that used .if has lost its state.

Look at what .if returns: transform(self) in one branch and self in the other. Those are two different types, and an if between two types in a view builder is not one view that changes. It is two views, of which one exists at a time. When highlight flips, SwiftUI removes the plain counter, with its @State, and inserts a new, highlighted one that starts from 0.

The second counter is one view the whole time. Its background modifier is always there; only the color it is given changes. WWDC21's "Demystify SwiftUI" has a name for this: "We call modifiers like this 'inert modifiers,' because they don't affect the rendered result." And the advice: "Branches are great, and they exist in SwiftUI for a reason. But when used unnecessarily, they can cause poor performance, surprising animations, and, as Luca showed, even loss of state. When you introduce a branch, pause for a second and consider whether you're representing multiple views or two states of the same view."

So do not add .if to a codebase, and when you find it in one, know what it costs: state is lost, animations jump, and text fields lose their focus every time the condition changes. Nearly every modifier takes a value that can be made to do nothing: .clear, 0, 1, nil, false.

Where this comes from: WWDC21: Demystify SwiftUI (2021 — still the reference on identity) · Configuring views — WWDC21, “Demystify SwiftUI”.

Space first. The first two columns are as tall and as wide as if the middle view were there. Apple says it of hidden(): "Hidden views are invisible and can't receive or respond to interactions. However, they do remain in the view hierarchy and affect layout." Opacity is only a way of drawing, so the same goes for it. The third column has closed up, because with if the view is not there at all. The disabled button is there and is drawn, dimmed.

Now touches. Four buttons, each tapped in its middle:

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack(spacing: 0) {
            Button("hidden") { print("hidden was tapped") }
                .buttonStyle(.borderedProminent)
                .hidden()
                .frame(height: 130)
            Button("opacity 0") { print("opacity 0 was tapped") }
                .buttonStyle(.borderedProminent)
                .opacity(0)
                .frame(height: 130)
            Button("opacity 0.5") { print("opacity 0.5 was tapped") }
                .buttonStyle(.borderedProminent)
                .opacity(0.5)
                .frame(height: 130)
            Button("disabled") { print("disabled was tapped") }
                .buttonStyle(.borderedProminent)
                .disabled(true)
                .frame(height: 130)
            Spacer()
        }
    }
}

The console showed

opacity 0.5 was tapped

One line. A hidden button cannot be tapped, as the documentation says. Neither can one with an opacity of 0 — but at 0.5 it can, so do not use a small opacity as a way of switching something off. And a disabled button swallows its tap and does nothing.

The interview version is "what is the difference between hiding a view and removing it?", and the answer that shows experience ends with state: of the four, only if destroys the view's @State, as the last edge case showed.

Where this comes from: hidden() · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) — Apple, hidden().

Hacking with Swift's suggested answer is still the one most people give: "If you're using SwiftUI, then the cornerRadius() modifier is your friend." Apple's reference for cornerRadius(_:antialiased:) now lists it as deprecated, with the note: "Use clipShape or fill instead." The same has happened to foregroundColor(_:), whose page says to use foregroundStyle(_:).

It still compiles. The code above was built with Xcode 27 and produced no warning, which is why this one catches people: nothing tells you. The documentation dates the deprecation to iOS 27.2, and this course was built against iOS 27.0, which is why there is no warning yet.

The three ways to say it now. Clip the view to a shape: .clipShape(RoundedRectangle(cornerRadius: 12)), or the shorter .clipShape(.rect(cornerRadius: 12)). Or, when the roundness belongs to a background, do not clip at all: .background(.yellow, in: RoundedRectangle(cornerRadius: 12)) draws a rounded shape behind the view and leaves the view alone. That is what Tile and Chip do in this lesson's tutorial, and it is the one to prefer: nothing is cut off, so a shadow or a badge that overhangs the edge survives.

Clipping has consequences that a background does not. It cuts off anything drawn outside the shape, including a shadow added before it. And, as an earlier edge case showed, it does not cut the area that takes touches.

Where this comes from: Hacking with Swift interview question: How would you round the corners of one of your views? · cornerRadius(_:antialiased:) · clipShape(_:style:) — Hacking with Swift: “How would you round the corners of one of your views?” Apple, cornerRadius(_:antialiased:).

In the first, every letter. A shadow is cast by what is drawn, and a column with padding draws nothing of its own. It is the SwiftUI version of setting a shadow on a UIView with a clear background and finding that the labels inside have grown shadows.

In the second, the box. The background is drawn, it is behind the texts, and the shadow of the whole — box and letters together — is the shadow of the box.

The third is the first again, and that is the instructive one. .compositingGroup() draws the column and its contents into one image before the shadow is applied. Apple: "A compositing group makes compositing effects in this view's ancestor views, such as opacity and the blend mode, take effect before this view is rendered." One image, one shadow — but the image is still only letters on nothing, so the shadow is still the shape of the letters. Where a compositing group changes the picture is with overlapping things: a card made of several views that should fade as one, or cast one shadow and not one each.

Hacking with Swift's answer to the interview question adds the part that shows experience: "This would be a good time to mention to relative cost of dynamic shadows". A shadow has to be computed from whatever is drawn, every time that changes. A shadow on a simple filled shape is cheap. A shadow on a complicated, changing view, in every row of a scrolling list, is one of the classic causes of dropped frames.

Where this comes from: Hacking with Swift interview question: How would you add a shadow to one of your views? · compositingGroup() — Hacking with Swift: “How would you add a shadow to one of your views?” Apple, compositingGroup().

It compiles, with a warning

'appendInterpolation' is deprecated: Localized string interpolation produces an unlocalized, debug description for this type of value. Use a type supported by LocalizedStringKey.StringInterpolation or initialize a LocalizedStringResource instead with an interpolated value that conforms to CustomLocalizedStringResourceConvertible.

A dump of the view's type, where the 5 should be. It compiled — with the warning above, on the second line.

Text("5").bold() is a Text: bold() here is one of the modifiers that Text defines for itself, which take a text and return a text. So it can be interpolated into another Text, which knows how to include a text with its styling.

.padding() is a modifier for any view, and what it returns is not a Text. Apple: "general modifiers return an opaque type. For example, the return value from the padding modifier isn't Text, but rather an opaque result type". Order matters here for the type: after the first general modifier, you no longer have a text, and everything that needs one stops working. An interpolation that is handed some other value falls back on describing it, which is the dump on the screen, and the warning is the compiler telling you so.

So: text modifiers first, general modifiers after. And treat this warning as an error. It is the same one that lesson 8's Decimal produced, and for the same reason: the interpolation was given something it has no proper way to show.

Where this comes from: Configuring views · Text — Apple, “Configuring views”, section “Use view-specific modifiers”.

"Seattle" turns yellow, and "Vancouver" does not. The modifier has @State, and each place it is used gets a copy of that state for itself. ContentView has no state at all, and knows nothing about which one is marked.

That is the answer to the question. For a fixed chain of modifiers, an extension method is enough: roomy(), in the same extension, is two modifiers and no type.

You need a type that conforms to ViewModifier when the modifier needs something that only a type can hold: @State of its own, as here; a value from the environment, with @Environment; or properties that you want to name and document. Apple: "Adopt the ViewModifier protocol when you want to create a reusable modifier that you can apply to any view."

And know the next step up. When what you are styling is a control, there is a protocol made for it — ButtonStyle, LabelStyle, ToggleStyle — which is given the control's parts and its state (is it pressed? is it on?) and which a whole screen can adopt with one line. A chip that should dim while it is pressed is a ButtonStyle, not a ViewModifier.

Where this comes from: ViewModifier · Configuring views — Apple, ViewModifier.

In the Grid, every one: the console showed 1000 of 1000 cards have appeared. In the LazyVGrid, 7 of 1000 cards have appeared — the ones on the screen.

That is the first half of the answer, and Apple states it in both directions. A Grid "can size its rows and columns correctly because it renders all of its child views immediately." Lazy grids "render their cells when SwiftUI needs to display them, rather than all at once. This reduces the initial cost of displaying a large scrollable grid that's never fully visible, but also reduces the grid's ability to optimally lay out cells."

The second half is that last clause: what a lazy grid gives up. The same small table, in each:

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack(spacing: 30) {
            Grid(alignment: .leading, horizontalSpacing: 16, verticalSpacing: 8) {
                GridRow {
                    Text("City").bold()
                    Text("Nights").bold()
                }
                GridRow {
                    Text("Seattle")
                    Text("5")
                }
                GridRow {
                    Text("San Pedro de Atacama")
                    Text("12")
                }
            }
            .border(.red)
            LazyVGrid(columns: [GridItem(.flexible()), GridItem(.flexible())], alignment: .leading, spacing: 8) {
                Text("City").bold(); Text("Nights").bold()
                Text("Seattle"); Text("5")
                Text("San Pedro de Atacama"); Text("12")
            }
            .border(.blue)
        }
        .padding()
    }
}

The Grid looked at every cell and made the first column as wide as "San Pedro de Atacama". The LazyVGrid cannot look: most of its cells do not exist yet. Apple: it "doesn't generally have access to all the views in a row, because it generates new cells as people scroll", and "instead, it relies on a grid item for information". So its columns are whatever the GridItems say — here, two equal halves, whatever is in them.

The answer, then. Grid for a small, fixed table whose columns should fit what is in them: a form, a set of statistics, a price list. LazyVGrid for a scrolling collection of similar cells that may be long: photographs, cards, search results. The interview-preparation repository's line for an image-heavy grid is a list of four things, of which the first is the container: "LazyVGrid, stable IDs, right-sized images from the server, downsample off main, cache them." And Apple's caution applies here as it did to lazy stacks: "Switch to a lazy grid only if profiling your code shows a worthwhile performance improvement."

Where this comes from: Grid · GridItem · Senior iOS Interview Preparation (GitHub) — Apple, Grid, section “Performance considerations”, and GridItem.

Three, three, four and six.

The first two are what they say. Three fixed items are three columns of 60 points, with the grid's own width left over on each side. Three flexible items are three columns that share the width: Apple's definition is "the size of the grid with spacing and inflexible items removed, divided by the number of flexible items, clamped to the provided bounds."

The third is the one that the question is about. An adaptive item is not a column. It is "multiple items in the space of a single flexible item": the grid fits in as many columns of at least 80 points as it can, here four, and then lets them grow to use up the width. It "prefers to insert as many items of the minimum size as possible but lets them increase to the maximum size." Rotate the phone, or run on an iPad, and the count changes with no code. One line of layout does the work of a collection view's flow layout.

The fourth shows that the kinds can be mixed, and how. The fixed item takes its 60 points. The adaptive item is then one flexible item with the rest of the width, and fills it with columns of at least 50 points: five of them. Six columns in all, and the cells flow through them in order.

Where this comes from: GridItem · LazyVGrid — Apple, GridItem.Size.adaptive(minimum:maximum:) and GridItem.Size.flexible(minimum:maximum:).

With the divider, the grid is as wide as the screen allows and its columns have moved apart. Two rules meet. A view that is put in a grid without a GridRow becomes a row of its own that spans every column. And a divider takes all the width it is offered. Apple: "Because a divider takes as much horizontal space as its parent offers, the entire grid widens to fill the width offered by its parent view." It is lesson 9's divider in a stack, in two dimensions.

The first modifier is for exactly this. .gridCellUnsizedAxes(.horizontal) "asks grid layouts not to offer the view extra size in the specified axes": the divider is then as wide as the other cells make the grid, and no wider. That is the third grid.

The second is for a cell that should cover some columns and not all. .gridCellColumns(2), on a view inside a GridRow, makes it span two. In the fourth grid the note runs under the first two columns, and the star's column is left alone.

A related trap, while you are here: an empty cell. A row that has nothing to put in a column needs something there to keep the later cells in place. Color.clear will do it, and will then stretch the row and the column, because a color takes everything it is offered. Color.clear.gridCellUnsizedAxes([.horizontal, .vertical]) is the empty cell that takes no room.

Where this comes from: Grid · gridCellUnsizedAxes(_:) — Apple, Grid, section “Multicolumn cells”, and gridCellUnsizedAxes(_:).

In the middle of its row, and in the middle of its column. A lazy grid gives every cell in a row the height of the tallest, and every cell the width of its column, and then places each view in that space. Step 3 of layout again: the view chose its size, and the container chooses where it goes. The default is the center.

Where it goes is a property of the column: GridItem(.flexible(), alignment: .top). That is the second grid. The notes now start at the top of their rows — and are still centered sideways, and still of four different sizes, which is seldom what a design means by a grid of cards.

For equal cards, the cell has to take the space, and not merely be placed in it. That is the last lesson's subject: .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .topLeading), and then the background, in that order, so that the yellow is on the frame. Third grid: each card fills its cell, and every row is as tall as its longest note.

This lesson's tutorial did not need this, because every TripCard in a row happens to be the same height. The day a note runs to two lines, it will.

Where this comes from: GridItem · frame(minWidth:idealWidth:maxWidth:minHeight:idealHeight:maxHeight:alignment:) — Apple, GridItem.

With if and else: Count: 0. The VStack in one branch and the HStack in the other are two different views, and so is everything in them. Flipping the switch removed one counter, with its @State, and created another.

let layout = vertical ? AnyLayout(VStackLayout()) : AnyLayout(HStackLayout())
        VStack(spacing: 30) {
            layout {
                Counter()
                Text("Seattle")
                Text("5 nights")
            }

With AnyLayout: Count: 2. There is one container the whole time, and one set of children. Only the rule for arranging them changed. Apple: "Use an AnyLayout instance to enable dynamically changing the type of a layout container without destroying the state of the subviews."

HStackLayout and VStackLayout are the stacks you know, in the form that conforms to Layout; a layout of your own, like this lesson's FlowLayout, can go in an AnyLayout too. Because the views are the same views before and after, the change can also be animated: each one slides from its old place to its new one. With if and else there is nothing to slide, only one set of views fading out and another fading in.

The usual condition is not a switch but the environment — the Dynamic Type size, or the horizontal size class — and for the simple case, "a row if it fits, otherwise a column", lesson 9's ViewThatFits is less code. AnyLayout is for when you decide, and the state inside must survive the decision.

Where this comes from: AnyLayout · WWDC22: Compose custom layouts with SwiftUI · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) — Apple, AnyLayout.

Two, one, one and five. The line that decides is the first line of sizeThatFits:

arrange(subviews, in: proposal.width ?? .infinity).size

A layout does not get to assume a width. It is offered one, as every view is, and the offer can be any of the three special ones that Apple lists for this method: "The zero proposal; respond with the layout's minimum size. The infinity proposal; respond with the layout's maximum size. The unspecified proposal; respond with the layout's ideal size."

On the screen the offer is 370 points, and the chips wrap onto a second line. In a scroll view that scrolls sideways, and under .fixedSize(), the offer has no width: proposal.width is nil. The ?? .infinity turns that into "as wide as you like", so everything goes on one line — which is the right ideal size for a flow of chips, and is why the third one runs off both edges of the screen. In 150 points, no two chips fit side by side.

To see the conversation, print was added to both methods, and the first of the four was run alone:

The console showed

sizeThatFits: offered 370 x 778, answers 291 x 80
placeSubviews: in 291 x 80
placeSubviews: in 291 x 80

One question about size, answered with the size of the two lines of chips; then the placing, in exactly the rectangle that was claimed. Apple: "SwiftUI views choose their own size, so the layout engine always uses a value that you return from this method as the actual size of the composite view." The placing was asked for twice, and a parent may ask for the size more than once too, so both methods must be cheap, and must agree with each other: "Be sure that you use computations during placement that are consistent with those in your implementation of other protocol methods." FlowLayout guarantees that the simple way. Both methods call the same arrange.

Where this comes from: Layout protocol · Layout.sizeThatFits(proposal:subviews:cache:) · Layout.placeSubviews(in:proposal:subviews:cache:) · WWDC22: Compose custom layouts with SwiftUI — Apple, Layout: sizeThatFits(proposal:subviews:cache:) and placeSubviews(in:proposal:subviews:cache:).

The console showed

side by side, the neighbors ask for: 8.0, 8.0, 8.0, 8.0
one above the other, they would ask for: 2.0, 0.0, 3.3, 8.0
the row that asks is 229 points wide
the HStack is 229 points wide

Every child that a layout is handed carries its spacing preferences, and a layout asks one neighbor about the next: subviews[index].spacing.distance(to: subviews[index + 1].spacing, along: .horizontal). Apple: the method "considers the preferences of adjacent views on the edge where they meet. It returns the smallest distance that satisfies both views' preferences for the given edge."

Side by side, these five views all ask for the same 8 points. One above the other they would not — 2 between the two texts, nothing between a text and a symbol, 3.3 between the symbol and a color, 8 between the two colors — which is lesson 9's edge case seen from the inside. And the row that was laid out with the answers comes to exactly the width of the HStack above it, 229 points. This is what the built-in stacks do. WWDC22: "respecting these preferences in your own layouts is a good way to get results that automatically follow Apple's interface guidelines, and as a result, match the look of the rest of the system."

So a layout of your own has the same two choices as a stack: a number that you were given, or the views' own wishes. FlowLayout takes a number, which is right for chips. Whichever you choose, use it in both methods. Apple: "if you add spacing during placement, make sure your implementation of sizeThatFits(proposal:subviews:cache:) accounts for the extra space." The classic bug in a first custom layout is a container that is too small for its children by exactly the gaps.

Where this comes from: Layout.placeSubviews(in:proposal:subviews:cache:) · ViewSpacing · WWDC22: Compose custom layouts with SwiftUI — Apple, Layout.placeSubviews(in:proposal:subviews:cache:), and WWDC22, “Compose custom layouts with SwiftUI”.

Still lazy: the console showed 6 of 1000 cards have appeared. A lazy grid does not need to be the scroll view's own child. It finds the scroll view that it is in, however many ordinary containers are in between, and builds the cells that fall inside the part that can be seen. This lesson's ContentView relies on this: its grid of cards is one child of a stack that also holds the strip, the summary and the chips.

Take the scroll view away and the grid is still lazy, in the worst way: 8 of 1000 cards have appeared.

It built the cards that fit on the screen, and nobody can reach the others. A lazy container trades completeness for speed on the understanding that scrolling will ask for the rest. Without scrolling, the rest never comes.

The opposite mistake is the commoner one: a Grid, or a plain VStack, holding a thousand of anything inside a ScrollView — every one of them built before the first is seen, as this lesson's first edge case counted. The rule that covers both: long and scrolling means lazy; short and fixed means not.

Where this comes from: LazyVGrid · Creating performant scrollable stacks · Grid — Apple, LazyVGrid, and “Creating performant scrollable stacks”.