SwiftUI Layout: The Rules That Stop the ‘Why Is It Doing That?’

Quickstart

When a SwiftUI view “should be centered” or “should take full width” but isn’t, don’t fight it with random .frame calls. Use this quick sequence: it’s fast, repeatable, and it usually reveals the real constraint in under 2 minutes.

Overview

SwiftUI layout isn’t “auto magic.” It’s a negotiation between parent and child views, performed in a predictable order. Once you understand that order, stacks, frames, alignment, and spacing stop being mysterious knobs and start being tools you can reason about.

The focus here is day-to-day SwiftUI layout: building screens, cards, rows, and responsive UI that behaves well across device sizes, dynamic type, and localization. No hand-waving—just rules, patterns, and what to watch out for.

Core concepts

If you learn only one thing about SwiftUI layout, learn this: the system is not trying to “make it look right.” It’s trying to satisfy constraints in a consistent way. Here are the pieces of that system.

1) The layout pass: proposal, choice, placement

SwiftUI performs layout in a pass where each parent offers a proposed size to its children. Each child picks a size that fits its content and the proposal, and the parent places it according to alignment rules.

2) Containers: stacks, spacers, and “who owns the space?”

Stacks are layout containers. They don’t “draw.” They measure children and distribute available space. The important bit: in a stack, most views are content-sized, while Spacer is space-sized.

3) Modifier order: you’re wrapping views, not “setting properties”

In SwiftUI, modifiers are not configuration flags. Most modifiers return a new view that wraps the previous one. That’s why .padding().background() and .background().padding() are different: you changed what you’re measuring.

4) Compression, hugging, and priority (the invisible tiebreaker)

When space is tight, SwiftUI must decide what gets smaller first. That decision is influenced by view behavior and .layoutPriority(). Priority is a tiebreaker: higher priority views get to keep more of their ideal size.

Step-by-step

This section is a practical workflow: how to build and debug SwiftUI layout with predictable results. The goal isn’t “memorize modifiers.” The goal is to identify the constraint owner (which parent controls the proposal) and then apply the smallest change that makes the constraint explicit.

Step 1 — Add a tiny layout debugger (and stop guessing)

Start every layout diagnosis by making boundaries visible. This helper draws a border and overlays the measured size. Use it temporarily while you build a screen, then remove it.

import SwiftUI

private struct DebugLayout: ViewModifier {
    let name: String
    let color: Color

    func body(content: Content) -> some View {
        content
            .overlay(
                GeometryReader { proxy in
                    let size = proxy.size
                    ZStack(alignment: .topLeading) {
                        Rectangle()
                            .stroke(color.opacity(0.9), lineWidth: 1)
                        Text("\(name) \(Int(size.width))×\(Int(size.height))")
                            .font(.caption2.monospaced())
                            .padding(4)
                            .background(color.opacity(0.15))
                            .foregroundStyle(color)
                            .clipShape(RoundedRectangle(cornerRadius: 6))
                            .padding(4)
                    }
                }
            )
    }
}

extension View {
    /// Debug the layout bounds and measured size of a view.
    func debugLayout(_ name: String, color: Color = .pink) -> some View {
        modifier(DebugLayout(name: name, color: color))
    }
}

Step 2 — Choose the right container for the job

Many “layout bugs” are actually “wrong container” bugs. If you’re stacking a list of rows, use a vertical container. If you need overlapping elements, use a ZStack/overlay. If you need grid behavior, use LazyVGrid or a custom layout.

Step 3 — Make space first, then align

Alignment is a placement decision. If there is no extra space, alignment has nothing to do. The most reliable pattern is: create a flexible container, then align inside it.

Step 4 — Build a “real” row: protect important views with priority

Here’s a common layout: leading icon + title/subtitle + trailing action. The tricky part is compression: when space is tight (small devices, large text, long strings), you want the action to stay tappable and the title to wrap/truncate gracefully.

import SwiftUI

struct SettingsRow: View {
    let title: String
    let subtitle: String
    let actionTitle: String

    var body: some View {
        HStack(alignment: .firstTextBaseline, spacing: 12) {
            Image(systemName: "gearshape.fill")
                .symbolRenderingMode(.hierarchical)
                .foregroundStyle(.secondary)
                .frame(width: 22, height: 22, alignment: .center)

            VStack(alignment: .leading, spacing: 4) {
                Text(title)
                    .font(.headline)
                    .lineLimit(2)
                    .fixedSize(horizontal: false, vertical: true)

                Text(subtitle)
                    .font(.subheadline)
                    .foregroundStyle(.secondary)
                    .lineLimit(2)
                    .fixedSize(horizontal: false, vertical: true)
            }
            .layoutPriority(1) // Prefer keeping text over shrinking it too aggressively.

            Spacer(minLength: 8)

            Button(actionTitle) {
                // action
            }
            .buttonStyle(.bordered)
            .fixedSize() // Keep the button at its ideal size (don’t let it compress).
        }
        .padding(.vertical, 10)
        .padding(.horizontal, 14)
        .frame(maxWidth: .infinity, alignment: .leading)
        .background(.thinMaterial, in: RoundedRectangle(cornerRadius: 14, style: .continuous))
    }
}

Step 5 — Use GeometryReader intentionally (and know what it changes)

GeometryReader is powerful, but it changes the negotiation: it tends to take all available space and then reports it. That’s great when you truly need container size (e.g., a chart or custom positioning), but it can cause accidental full-screen expansion if placed too high in the hierarchy.

Step 6 — When stacks aren’t enough: a tiny custom Flow layout

Sometimes you want tags/chips that wrap to the next line. Nested stacks can’t do wrapping. On newer OS versions, SwiftUI gives you the Layout protocol—use it to express the rule directly. (Even if you don’t ship this exact layout, reading it teaches you how SwiftUI thinks about measurement and placement.)

import SwiftUI

/// A simple "flow" layout: items go left-to-right, wrapping to new lines as needed.
struct FlowLayout: Layout {
    var spacing: CGFloat = 8

    func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) -> CGSize {
        let maxWidth = proposal.width ?? .infinity

        var lineWidth: CGFloat = 0
        var lineHeight: CGFloat = 0
        var totalHeight: CGFloat = 0
        var maxLineWidth: CGFloat = 0

        for view in subviews {
            let size = view.sizeThatFits(.unspecified)

            if lineWidth + size.width > maxWidth {
                totalHeight += lineHeight + spacing
                maxLineWidth = max(maxLineWidth, lineWidth)
                lineWidth = 0
                lineHeight = 0
            }

            lineWidth += (lineWidth == 0 ? 0 : spacing) + size.width
            lineHeight = max(lineHeight, size.height)
        }

        totalHeight += lineHeight
        maxLineWidth = max(maxLineWidth, lineWidth)

        return CGSize(width: min(maxLineWidth, maxWidth), height: totalHeight)
    }

    func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) {
        var x = bounds.minX
        var y = bounds.minY
        var lineHeight: CGFloat = 0

        for view in subviews {
            let size = view.sizeThatFits(.unspecified)

            if x + size.width > bounds.maxX {
                x = bounds.minX
                y += lineHeight + spacing
                lineHeight = 0
            }

            view.place(
                at: CGPoint(x: x, y: y),
                proposal: ProposedViewSize(width: size.width, height: size.height)
            )

            x += size.width + spacing
            lineHeight = max(lineHeight, size.height)
        }
    }
}

Notice how this layout follows the same rule set: given a proposed width, it computes the size that fits, then places children. That’s the layout engine in miniature.

Common mistakes

These are the patterns behind most “why is it doing that?” moments. Each one includes the fix that tends to stick long-term, not just a one-off patch.

FAQ

Why doesn’t .frame(alignment: ...) move my content?

Because alignment only matters when there’s extra space inside the frame. If the view is sized to its content, there’s no unused area to place content “to the leading edge.” Give the view room with .frame(maxWidth: .infinity, alignment: .leading) (or constrain the parent to be larger).

Why does my VStack sometimes take full width and sometimes hug content?

A VStack sizes itself based on its children and the proposal from its parent. In many containers, the parent proposes the full available width, so the stack can expand. In others (like certain rows, overlays, or nested stacks), the proposal is tighter, so the stack hugs content. If you need consistent behavior, make it explicit with .frame(maxWidth: .infinity) or by sizing the parent container.

When should I use Spacer() vs padding?

Use padding for a fixed gap around or between elements. Use Spacer() when you want a gap that grows/shrinks with available space (e.g., push a button to the trailing edge). If you use a Spacer when you meant a fixed gap, your layout will look “random” across device sizes.

What’s the difference between stack alignment and frame alignment?

Stack alignment (e.g., VStack(alignment: .leading)) controls how children line up relative to each other within that stack. Frame alignment (e.g., .frame(width: 200, alignment: .leading)) controls where the view’s content sits inside the frame you gave it. They solve different problems—often you need both for predictable results.

Why does GeometryReader make things expand?

GeometryReader tends to adopt all the space its parent offers, then reports that size. If you place it high in the view tree, it can become the “space owner” and cause children to behave as if they have much more room. Constrain it with a frame, move it lower, or use stack/grid constraints when you can.

How do I stop text from truncating in a row?

Decide what should win when space is tight. Give the important text higher .layoutPriority() and make controls like buttons .fixedSize() so they stay tappable. For multiline text that should grow vertically, use .fixedSize(horizontal: false, vertical: true) and a reasonable .lineLimit.

Cheatsheet

Keep this open while you build. It’s the “what actually changes size?” map plus a quick checklist for debugging SwiftUI layout.

Wrap-up

SwiftUI layout gets dramatically simpler when you stop thinking in terms of “centering” and “spacing” as magic and start thinking in terms of who owns the proposal and what size each view chooses. Once you adopt that mental model, frames, alignment, and spacers become predictable tools instead of surprises.

If you want to go further, the related posts below connect well: architecture choices affect where layout code lives, profiling helps you spot expensive view trees, and robust deep links often require careful UI state and layout handling.

Related posts

• iOS Architecture That Scales: MVVM, DI, and Feature Modules
• Make iOS Apps Smooth: Instruments Profiling Starter Guide
• Mobile App Security Basics: Storage, TLS, and Jailbreak Signals
• Deep Links That Work: Universal Links, App Links, and Edge Cases
• Jetpack Compose: State, Effects, and UI That Doesn’t Jitter
• Android Studio Profilers: Fix the 90% of Slowdowns