From Swift Objects to SwiftUI

Text and Pet are type names. Each complete expression calls an initializer and produces a value of that type:

Pet(...)  → a Pet value
Text(...) → a Text value

The string "Hello" supplies the information needed to initialize the Text. SwiftUI is already using the same relationship between types, initializers, and values that we used to create pets.

ContentView is a struct, and body is a computed property. It is a property rather than a method because its name is not followed by parentheses.

struct ContentView: View

The colon says that ContentView conforms to the SwiftUI View protocol. In plain language, the type promises to meet SwiftUI’s requirements for a view.

var body: some View

The body property produces one specific kind of value that conforms to View. The keyword some lets the implementation keep that exact type out of the declaration. At this stage, the useful reading is: the body produces a view.

Both are structs with properties. Pet has a stored property named name; ContentView has a computed property named body.

Their purposes differ:

Pet          models a thing
ContentView  describes an interface

A SwiftUI view is not a separate species of programming construct. It is a Swift type that satisfies the rules of the View protocol.

They appear in a vertical column:

Cookie
Energy: 5
Hungry

VStack is both a view and a container for other views. It arranges its children vertically. This is view composition: a larger interface is built from smaller views instead of being written as one giant object.

The expression begins by creating a Text view. .font(.title) describes a title-sized font, and .padding() adds space around the result.

The string remains "Cookie". More precisely, a SwiftUI modifier returns a new view that includes the requested change. It does not reach into the original Text value and mutate it.

create Text → return a view with a title font → return a view with padding

The calls look like ordinary methods because they are methods. SwiftUI uses familiar Swift syntax to construct a description of the interface.

Replace HStack with VStack:

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Cookie")
            Text("Energy: 5")
        }
    }
}

HStack arranges its children horizontally. VStack arranges them vertically. Choosing a container is part of describing the relationship among views, not merely a way to make the compiler accept several expressions.

The user sees a button labeled Feed. The print statement runs when the button is pressed, not when Swift creates the button.

The braces contain a closure: a function value passed to Button so SwiftUI can call it later. This form is called trailing-closure syntax because the closure appears after the initializer’s parentheses.

The button therefore combines two different pieces of information:

"Feed"                  what the button displays
{ print("Feeding pet") } what the button does

The interface begins with Energy: 5. One press changes it to Energy: 6; four presses change it to Energy: 9.

This line changes the state:

energy += 1

This line reads that state while describing the interface:

Text("Energy: \(energy)")

When energy changes, SwiftUI reevaluates the view’s body and updates the affected display. You describe the relationship between state and interface; SwiftUI performs the update.

let creates a constant, so energy += 1 cannot compile.

An ordinary mutable property is also a poor fit. SwiftUI view structs are temporary descriptions that the framework may create again as the interface changes. Local state needs storage with a lifetime managed by SwiftUI:

@State private var energy = 5

@State tells SwiftUI to preserve this value for the view’s identity and to update the interface when it changes. private keeps the storage as an implementation detail of ContentView.

PetView is a struct that conforms to View. It has three properties with different roles:

let name: String                // fixed information supplied from outside
@State private var energy = 5  // local state with a default value
var body: some View             // the interface description

The initializer also gives name a default without making it mutable:

init(name: String = "Cookie") {
    self.name = name
}

Both PetView() and PetView(name: "Mochi") are now valid. The first displays Cookie; the second displays Mochi. Energy begins at 5 in either view.

The body composes VStack, HStack, Text, and Button views. .font(.title), .padding(), and .disabled(...) are modifiers. Each button receives a closure. Feed raises energy but caps it at 10; Play lowers energy but floors it at 0.

The assignments defend the 0...10 rule. The disabled states also show the user when an action has reached its limit. Keeping both matters: the interface communicates the boundary, and the state-changing code still protects it.

Both labels read properties. Text(name) displays fixed input, while Text("Energy: \(energy)") displays changing state. When a closure changes energy, SwiftUI reevaluates the body and refreshes the energy label.

The bridge from the previous lesson is direct:

struct and protocol conformance → PetView: View
properties                      → name, energy, body
initializers                    → PetView(...), Text(...), Button(...)
closures                        → button actions
dot notation                    → view modifiers
state and its valid range       → @State, min(...), max(...)

The sequence produces 4, 6, 8, then 10. The last increase stops at the upper boundary.

Button("Sleep") {
    energy = min(energy + 2, 10)
}
.disabled(energy >= 10)

This is the same rule used by Feed, but the change is larger. If energy were 9, Sleep would still finish at 10, not 11.

A computed property keeps one source of truth:

var mood: String {
    if energy <= 2 {
        return "Tired"
    }

    if energy >= 8 {
        return "Energetic"
    }

    return "Ready"
}

Then place this view beside the energy label:

Text("Mood: \(mood)")

Mood changes whenever SwiftUI reevaluates body. A second stored state value would create an avoidable bug: one button might change energy but forget to change mood.

One compact solution is:

ProgressView("Energy", value: Double(energy), total: 10)

Text("\(energy) / 10")

This is a determinate progress view because it receives both the present value and the total. Its numeric initializer expects a floating-point value, so Double(energy) converts the Int without changing the stored state.

Do not stop after the code compiles. Press each button at both boundaries and confirm that the bar, number, disabled buttons, and mood all describe the same state.