Skip to content
Prepare to Grow

SwiftUI Fundamentals

Introduction to SwiftUI and Declarative UI

Understand SwiftUI's declarative model, the App and View protocols, view identity, and the render-update cycle.

Intermediate6 min read2 guided activities

Before you begin

What you will understand

  • Explain declarative UI in practical terms.
  • Trace a SwiftUI app from App to Scene to View.
  • Describe why a View value is a description rather than a persistent screen object.
  • Create and preview a small SwiftUI hierarchy.
01

Learning stage

Concept Explanation

SwiftUI is a declarative user-interface framework. You describe what the interface should look like for the current data, and SwiftUI determines how to create and update the platform views. When state changes, SwiftUI evaluates the affected view descriptions again and reconciles the new result with the existing interface.

A SwiftUI application begins with a type conforming to App. Its body provides one or more scenes, commonly WindowGroup. Each scene contains a hierarchy of values conforming to View. A view's body returns another view description; composition continues until SwiftUI reaches primitive views and platform rendering behavior.

View values are intentionally lightweight and may be created frequently. Do not treat init or body as lifecycle callbacks for expensive work. Keep body deterministic, move durable state into the correct state owner, and perform asynchronous work with lifecycle-aware APIs such as task.

  • App: the application entry point and scene declaration.
  • Scene: a system-managed presentation context such as WindowGroup.
  • View: a value describing part of the interface for current data.
  • body: a computed view description, not a one-time construction method.
  • Reconciliation: SwiftUI updates the rendered interface while preserving state through identity.
02

Learning stage

Syntax & Examples

This app composes a root screen from small view values and keeps body free of side effects.

LearningApp.swiftswift
import SwiftUI

@main
struct LearningApp: App {
  var body: some Scene {
    WindowGroup {
      WelcomeScreen(learnerName: "Mina")
    }
  }
}

struct WelcomeScreen: View {
  let learnerName: String

  var body: some View {
    VStack(spacing: 12) {
      Image(systemName: "swift")
        .font(.largeTitle)
        .foregroundStyle(.orange)

      Text("Welcome, (learnerName)")
        .font(.title.bold())

      Text("Your SwiftUI path starts here.")
        .foregroundStyle(.secondary)
    }
    .padding()
  }
}

#Preview {
  WelcomeScreen(learnerName: "Preview Learner")
}
The App owns the scene; the screen describes its hierarchy from immutable input. The preview supplies representative data without launching the full app.
03

Learning stage

Real-World Usage

Connect the SwiftUI concept to complete, maintainable application features.

  • Create a root scene and choose the first screen of an app.
  • Build reusable screens that accept explicit input values.
  • Use previews to inspect meaningful states while developing.
  • Reason about UI as a function of data rather than a sequence of manual mutations.
04

Learning stage

Common Mistakes

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

  • Starting network requests or changing state directly inside body.
  • Assuming a View struct instance lives as long as the pixels on screen.
  • Creating one enormous root view instead of composing focused pieces.
  • Treating every visual update as a manual imperative command.
  • Using previews with unrealistic empty data only.
05

Learning stage

Practice Exercises

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

Activity 1

Trace an app hierarchy

Create an App with a WindowGroup, a HomeScreen, and two small child views. Draw the hierarchy from App to its leaf views.

Hint: Pass at least one immutable value from the parent into a child.

Activity 2

Preview meaningful states

Create previews of a course card for available, completed, and locked states using fixed sample data.

Hint: Previews are most valuable when they represent states that are otherwise slow or difficult to reach.

06

Learning stage

Knowledge Check

Answer each question before revealing the explanation.

QUESTION 1

What does a SwiftUI View's body represent?

  1. A.A description of the interface for the current data
  2. B.A one-time screen constructor
  3. C.A mutable UIKit view hierarchy
  4. D.A background thread
Reveal answer

A description of the interface for the current data

SwiftUI may evaluate body repeatedly and reconciles its result with the current rendered interface.

QUESTION 2

Why should body avoid side effects?

Reveal answer

Because SwiftUI controls when and how often body is evaluated, so side effects there can repeat unpredictably.

Use explicit actions and lifecycle-aware modifiers for work that changes state or interacts with external systems.

07

Learning stage

Interview Preparation

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

What does declarative UI mean in SwiftUI?

Short answer: A view describes the UI that should exist for the current state, and the framework applies the necessary updates.

Explore the detailed answer

Instead of directly creating and mutating every platform view, SwiftUI code declares a hierarchy derived from data. When that data changes, SwiftUI re-evaluates affected descriptions, compares identity and structure, and updates the rendered interface. State ownership and stable identity therefore matter greatly.

Possible follow-ups

  • • Is a View value the same as the rendered platform view?
  • • Why can body run many times?
08

Learning stage

Key Takeaways

SwiftUI turns current state into a declarative view hierarchy. App and Scene establish the application structure; small View values describe the interface without owning imperative rendering work.

  • SwiftUI describes UI from current data.
  • App contains scenes; scenes contain view hierarchies.
  • View values are lightweight descriptions.
  • body should be deterministic and free of side effects.
  • Previews should represent real interface states.