Exercise 1: StepperView with @State, and Why value Persists Across Recreations — Possible Solution
==========================================================================================================

struct StepperView: View {
    @State private var value = 0

    var body: some View {
        VStack {
            Text("Value: \(value)")
            HStack {
                Button("-") { value -= 1 }
                Button("+") { value += 1 }
            }
        }
    }
}

WHY value PERSISTS ACROSS RECREATIONS: Per Chapter 4, StepperView is a
struct, and SwiftUI genuinely does recreate a fresh struct value every
time this view's body needs to be re-evaluated - for instance, right
after one of the buttons is tapped. If value were a plain, ordinary
struct property with no special handling, each fresh StepperView
instance would simply reset back to its own declared initial value (0)
every single time, since a brand-new struct copy has no memory of a
previous one's own property values.

@State is specifically what prevents that reset from happening. The
real value backing a @State property isn't actually stored inside the
StepperView struct instance itself - SwiftUI stores it externally, in
storage the framework manages and keys to this specific view's own
identity within the view tree, independent of any one particular
struct instance. Each time SwiftUI creates a fresh StepperView struct,
that new struct's own value property is reconnected to that same
external, persistent storage rather than starting over - so tapping
"+" updates the externally-stored value, and the next struct
recreation reads that already-updated value back out, rather than
resetting to 0.

ANSWER: value correctly persists across taps because @State stores its
real underlying value outside the StepperView struct itself, in
storage SwiftUI manages and keys to this view's own identity - not
inside any one particular struct instance. Each time SwiftUI recreates
the StepperView struct (a cheap, disposable value per Chapter 4), the
new struct's value property reconnects to that same persistent
external storage rather than resetting, which is exactly why the count
keeps its own running value across repeated taps and struct
recreations.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly builds the stepper view and explains @State's real
externalized-storage mechanism as the specific reason state survives
struct recreation, directly resolving the tension the chapter itself
raised between "views are cheap, disposable structs" and "state
persists."