لماذا تحتاج View إلى الحالة

A SwiftUI view is a lightweight description of your UI for one moment. It is recreated constantly, so it can't simply store changing values like a normal object. 📐

Your views are structs, and SwiftUI treats their stored properties as read-only inside body. You cannot just reassign a property and expect the screen to react.

Try setting a plain property from a button and the compiler stops you: structs can't mutate themselves inside body. The UI has no idea anything changed anyway.

In SwiftUI, the screen is a pure function of your data. Same data in, same UI out. To change the screen, you change the data, not the view directly.

SwiftUI gives you state: a place to store changing values that lives outside the throwaway view struct. When state changes, SwiftUI rebuilds the affected views for you. ✨

Even though the view struct is recreated again and again, your state value persists between redraws. SwiftUI stores it safely behind the scenes for that view.

State becomes the single source of truth for a piece of view-local data. The view always reflects it, so there is never a stale, out-of-sync screen.

Here a stored value drives the text. Once it is marked as state, changing it will automatically refresh the Text on screen.

You never tell a label to update itself. You change the data and SwiftUI reacts. This declarative style means less wiring and fewer bugs.

Use state for values a single view owns and changes over time: a counter, a toggle, typed text. Static labels and fixed config don't need it.

State is meant for simple, view-local data. Keep each piece focused so SwiftUI can update efficiently and your views stay easy to reason about.

Why can't a SwiftUI view just store a changing value in a plain property?

SwiftUI views are immutable structs and the UI is a function of data. State lets a view own changing values that persist across redraws and drive automatic updates. 🎯