There I was, staring at my beautiful new experience written entirely in SwiftUI, months ahead of schedule as I promised (and gambled on). Feeling proud of myself, I went to show one of my teammates. They praised the work… and then asked how it looked in different dynamic sizes.
Uh oh…
Captain SwiftUI is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Much of the UI began to shrink and grow as we scaled from small to large. But the sub-containers that made up such a large part of the experience were set to a fixed height and width.
I quickly scrambled to find a solution, worrying that it would take another sprint to custom write something. But then, what’s this? @ScaledMetric you say? I quickly add it to my code.
That sense of aw and magic I had when I first used SwiftUI quickly washed over me as I watched these containers scale along with the overall experience. The fear of a lost sprint was squashed with a simple, mysterious property wrapper.
Wrappers: Unsung Heroes of SwiftUI
SwiftUI developers lean heavily on the classic property wrappers: @State, @Binding, @ObservedObject. But SwiftUI ships with a powerful cast of other property wrappers and wrapped values — some that solve complex problems with a single line of code.
This article is your curated guide to 10 wrappers and values that are often overlooked but deserve a spot in your toolkit.
Note: What do I mean by wrapped values? Towards the end of this list, you’ll see values that can be found in Environment. They are not wrappers, themselves. However, they felt at home on this list because of the similar help they offer experiences as well as to highlight some of the powerful values being kept “under wraps”.
What Are Property Wrappers?
Property wrappers in Swift are a powerful language feature that let you define reusable behaviors for how values are stored, computed, or observed. In SwiftUI, they’re everywhere: @State, @Binding, @Environment, and others all rely on this system.
At a high level, a property wrapper:
Encapsulates a value (like a Bool or String)
Adds logic to how that value is read or written
Can expose additional projected values (like $binding)
For example, @State var isOn = false actually wraps the value inside a State<Bool> struct, managing updates and triggering view re-renders when the value changes.
3. @FocusedValue – Share Values Across Focused Views
What it does: Exposes values based on the currently focused view. Perfect for input coordination.
@FocusedValue(\.username) var username
Why it matters:
Great for building forms where data flows between fields without tightly coupling the views.
Lets you create smarter, context-aware toolbars or keyboards that change depending on focus.
When to use it: When multiple fields or child views need to share or react to information based on the current focus — like dynamic toolbars or editing panels.
What it does: Tracks temporary state during a gesture and resets automatically after it ends.
@GestureState private var isPressed = false
Circle()
.scaleEffect(isPressed ? 1.2 : 1.0)
.gesture(
LongPressGesture()
.updating($isPressed) { value, state, _ in state = value }
)
Why it matters:
No need to manually reset gesture state — SwiftUI cleans it up for you.
Makes it easy to animate elements during gestures like drags, long-presses, or swipes.
When to use it: Anytime you want temporary visual feedback during a user interaction — like highlighting, scaling, or revealing hidden options while dragging.
Cleaner and safer than UIKit’s messy becomeFirstResponder()/resignFirstResponder().
Crucial for building great, intuitive SwiftUI forms, especially for keyboard users.
When to use it: Whenever you want to control or track which field is active — like auto-advancing fields, validating on focus loss, or dismissing keyboards cleanly.
8. @Environment(\.dynamicTypeSize) – Read Current Type Size
What it does: Gives you access to the current Dynamic Type size setting (like .large, .accessibility5).
@Environment(\.dynamicTypeSize) var typeSize
if typeSize.isAccessibilitySize {
CompactLayout()
} else {
RegularLayout()
}
Why it matters:
Lets you adapt layouts, not just text size, for accessibility.
You can build UIs that totally rethink structure at large text sizes.
When to use it: When you need major layout shifts for users with accessibility text sizes — like stacking content vertically or increasing tap target spacing.
