SwiftUI Property Wrappers Finally Make Sense (Build One From Scratch)

Mentoring 👉 https://rebeloper.com/mentoring

I was using @State wrong for years — and this tiny SwiftUI example finally made it click.
In this video, I compare @State and @Observable using one single variable to show how state lifetime actually works in SwiftUI. You’ll see why @State resets when views are recreated, why @Observable behaves differently, and how one wrong state decision can cause bugs that feel “random” or unpredictable.

If your SwiftUI views keep resetting, updating too often, or behaving strangely, this mental model will save you hours of debugging. Once you see this, SwiftUI stops feeling magical and starts feeling predictable.

→ PLAYLIST:
SwiftUI That Feels Like Apple 👉 https://www.youtube.com/watch?v=Ee9WX0pL9sM&list=PL_csAAO9PQ8Yg4k1M6o8DaH0PEebQx2hk
__________
Get in touch:
→ support@rebeloper.com

SUBSCRIBE to weekly tips & tutorials for building iOS apps!
→ https://www.youtube.com/@rebeloper?sub_confirmation=1

GitHub: https://github.com/rebeloper/
Hire me: https://rebeloper.com/hire-us/
LinkedIn: https://www.linkedin.com/in/rebeloper/
My Blog: https://rebeloper.com/blog
Follow me on Instagram: https://www.instagram.com/rebeloper/
X: https://twitter.com/rebeloper

Rebeloper

SwiftUI's @State and @Observable serve different purposes in state management. @State lives only while the view exists and resets when the view is removed from the hierarchy, making it suitable for view-specific data. @Observable outlives the view by storing data in a separate model class, persisting values even when views are toggled on and off. The choice depends on whether you need view-scoped or persistent state throughout the app's lifecycle.

I Was Using @State Wrong for Years