Skip to content
Prepare to Grow

SwiftUI Fundamentals

View Composition and Modifiers

Build reusable views, understand modifier order, and design focused visual APIs with ViewBuilder composition.

Intermediate6 min read2 guided activities

Before you begin

What you will understand

  • Extract focused reusable views.
  • Explain why modifier order changes results.
  • Use ViewBuilder conditionals safely.
  • Design view inputs that express meaning rather than styling details.
01

Learning stage

Concept Explanation

SwiftUI interfaces scale through composition. A screen combines smaller views, each responsible for one meaningful visual or interaction concept. Child views receive the smallest useful inputs and emit actions through closures or bindings instead of reaching into unrelated global state.

A modifier returns a new view that wraps or transforms the previous one. Order matters because padding followed by a background gives a different result from a background followed by padding. Read a modifier chain from the base view outward, one transformation at a time.

The ViewBuilder result builder allows body and container closures to combine multiple child views and use limited control flow such as if and switch. Stable structure and identity still matter; avoid hiding large unrelated screen branches inside deeply nested builders.

  • Composition: assemble screens from small semantic views.
  • Modifier: returns a transformed or wrapped view.
  • Order: each modifier operates on the result before it.
  • ViewBuilder: combines child view expressions into one view result.
  • Action closure: lets a reusable view report intent without owning the feature.
02

Learning stage

Syntax & Examples

The card owns its presentation while its caller supplies content and the action to perform.

LessonCard.swiftswift
import SwiftUI

struct LessonCard: View {
  let title: String
  let minutes: Int
  let isComplete: Bool
  let onOpen: () -> Void

  var body: some View {
    Button(action: onOpen) {
      HStack(spacing: 14) {
        Image(systemName: isComplete ? "checkmark.circle.fill" : "book")
          .foregroundStyle(isComplete ? .green : .blue)

        VStack(alignment: .leading, spacing: 4) {
          Text(title).font(.headline)
          Text("(minutes) min").font(.subheadline).foregroundStyle(.secondary)
        }

        Spacer()
        Image(systemName: "chevron.right")
          .foregroundStyle(.tertiary)
      }
      .padding()
      .background(.background, in: .rect(cornerRadius: 16))
      .overlay {
        RoundedRectangle(cornerRadius: 16).stroke(.separator)
      }
    }
    .buttonStyle(.plain)
  }
}
The reusable card exposes domain inputs and a user intent. Its modifier order places the background behind the padded content and the border around that result.
03

Learning stage

Real-World Usage

Connect the SwiftUI concept to complete, maintainable application features.

  • Extract reusable cards, badges, empty states, headers, and buttons.
  • Build screens whose hierarchy mirrors product concepts.
  • Create small visual APIs that work with previews and tests.
  • Use custom modifiers for repeated, genuinely coherent presentation rules.
04

Learning stage

Common Mistakes

Identify patterns that weaken ownership, identity, adaptation, accessibility, or user experience.

  • Extracting every Text into a separate type without gaining meaning or reuse.
  • Passing a complete feature model when a child needs two values.
  • Ignoring modifier order and compensating with arbitrary spacing.
  • Using AnyView to erase types without a real heterogeneous-storage requirement.
  • Putting navigation, networking, and unrelated feature logic inside a visual component.
05

Learning stage

Practice Exercises

Build the behavior in a small Xcode project and review it in multiple states.

Activity 1

Extract a reusable card

Build a course row, then extract its status badge and action area into focused child views. Keep the screen's data flow visible.

Hint: Extract around a stable concept, not only a line count.

Activity 2

Observe modifier order

Create two Text views: padding then background, and background then padding. Describe the resulting visual boundaries.

Hint: Add a border after each step to make the transformed frame visible.

06

Learning stage

Knowledge Check

Answer each question before revealing the explanation.

QUESTION 1

What does a SwiftUI modifier usually return?

  1. A.A new transformed view value
  2. B.The same mutable platform view
  3. C.Only a color
  4. D.A scene
Reveal answer

A new transformed view value

Modifier chains build nested view descriptions, so order can affect layout, drawing, and behavior.

QUESTION 2

What should a reusable child view receive?

Reveal answer

The smallest meaningful values and actions required to render and behave correctly.

Focused inputs reduce coupling and make previews, reuse, and testing easier.

07

Learning stage

Interview Preparation

Explain the design in terms of data flow, identity, lifecycle, platform behavior, and trade-offs.

Why does modifier order matter in SwiftUI?

Short answer: Each modifier transforms the view produced before it, creating nested layout and drawing behavior.

Explore the detailed answer

For example, background then padding colors only the original content area, while padding then background colors the padded area. Some modifiers affect layout proposals, others draw, add gestures, or alter environment values, but all participate at a specific point in the chain.

Possible follow-ups

  • • When would you create a custom ViewModifier?
  • • Why avoid unnecessary AnyView usage?
08

Learning stage

Key Takeaways

Compose interfaces from semantic views with focused inputs. Treat modifier chains as ordered transformations and keep data ownership outside reusable presentation components unless the state is truly local.

  • Extract stable concepts, not arbitrary fragments.
  • Modifiers produce new nested view values.
  • Modifier order affects layout and drawing.
  • ViewBuilder supports declarative composition and control flow.
  • Actions let children report intent without owning the feature.