Sagar Unagar's Blog

Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange

Sat, 28 Feb 2026 00:00:00 GMT

SwiftUI's layout system is declarative, adaptive, and proposal-driven. Most of the time, stacks and spacers are enough. But the moment you need to:

Track scroll offset
Build a collapsing header
Implement parallax
Create a fully custom layout
React to safe area changes

You enter the world of geometry.

Understanding geometry in SwiftUI isn't about memorizing APIs. It's about understanding how layout works and where geometry fits inside that system.

In this article, we’ll cover:

How SwiftUI layout actually works
GeometryReader
GeometryProxy (the core abstraction)
Coordinate spaces
Measuring child views with preferences
onGeometryChange (modern observation API)
Geometry vs the Layout protocol
Pitfalls and best practices

This is a long-form, architectural deep dive — not just an API tour.

How SwiftUI Layout Actually Works

SwiftUI layout follows a three-phase process:

Parent proposes a size
Child chooses a size
Parent places the child

Unlike Auto Layout, SwiftUI does not solve constraints. It negotiates size.

For example:

VStack {
    Text("Hello")
    Text("World")
}

What happens internally?

VStack receives a size proposal from its parent.
It proposes a width to each child.
Each Text returns its ideal height.
VStack stacks them vertically and reports its own size upward.

Geometry APIs allow us to inspect the result of that negotiation.

They do not control layout — they observe it.

That distinction is critical.

`GeometryReader`

GeometryReader is the original way to access layout information in SwiftUI.

GeometryReader { proxy in
    Text("Width: \(proxy.size.width)")
}

It gives you a GeometryProxy, which contains information about:

The view’s size
Its frame in different coordinate spaces
Safe area insets

Important Behavior

GeometryReader expands to fill all available space.

Example:

VStack {
    GeometryReader { proxy in
        Color.red
    }
}

Output:

The red view will take all vertical space.

This happens because GeometryReader is itself a layout container.

That’s why it’s powerful — and why it can be intrusive.

`GeometryProxy` - The Core Abstraction

Both GeometryReader and onGeometryChange expose the same type:

GeometryProxy

This is the heart of SwiftUI geometry.

Think of GeometryProxy as a read-only snapshot of resolved layout information.

It does not control layout. It reflects it.

Let’s examine its key APIs.

`size`

proxy.size

Returns the resolved size of the view during that layout pass.

Example:

GeometryReader { proxy in
    Rectangle()
        .fill(.blue)
        .frame(height: proxy.size.width * 0.5)
}

Output:

Here we’re building a responsive rectangle whose height is half its width.

Important nuance:

This is not the proposed size.
It is the size after negotiation.

`frame(in:)`

This is where things get powerful.

proxy.frame(in: .global)

Returns a CGRect representing the view’s position in a specific coordinate space.

Available coordinate spaces:

.local
.global
.named("custom")

Example:

GeometryReader { proxy in
    let frame = proxy.frame(in: .global)

    Text("Y: \(frame.minY)")
}

Output:

This enables:

Scroll offset detection
Sticky headers
Parallax animations
Visibility detection

`safeAreaInsets`

proxy.safeAreaInsets

Returns safe area values at that layout location.

Example:

GeometryReader { proxy in
    VStack {
        Text("Top inset: \(proxy.safeAreaInsets.top)")
    }
}

Output:

Useful for:

Custom navigation bars
Full-screen backgrounds
Keyboard-aware layouts
Dynamic island spacing

Coordinate Spaces Explained

Understanding coordinate spaces is essential.

SwiftUI supports three types.

`.local`

proxy.frame(in: .local)

Coordinates relative to the GeometryReader.

`.global`

proxy.frame(in: .global)

Coordinates relative to the entire screen.

`.named("custom")`

You can define custom spaces.

ScrollView {
    VStack {
        GeometryReader { proxy in
            let frame = proxy.frame(in: .named("scroll"))
            Text("Offset: \(frame.minY)")
        }
        .frame(height: 100)
    }
}
.coordinateSpace(name: "scroll")

Output:

Named spaces are ideal for scroll-based effects.

Measuring Child Views with Preferences

GeometryReader measures its own container.

But what if you need to measure a child view?

This is where PreferenceKey comes in.

Step 1: Define a PreferenceKey

struct SizePreferenceKey: PreferenceKey {
    static var defaultValue: CGSize = .zero

    static func reduce(value: inout CGSize, nextValue: () -> CGSize) {
        value = nextValue()
    }
}

Step 2: Attach Geometry in Background

Text("Measure me")
    .background(
        GeometryReader { proxy in
            Color.clear
                .preference(key: SizePreferenceKey.self,
                            value: proxy.size)
        }
    )

Step 3: Observe Changes

.onPreferenceChange(SizePreferenceKey.self) { size in
    print("Size:", size)
}

This pattern is foundational for advanced layout techniques.

`.onGeometryChange` - The Modern Way

GeometryReader participates in layout.

.onGeometryChange does not.

It allows you to observe geometry changes without wrapping your view.

struct GeometryChangeExample: View {
    @State private var size: CGSize = .zero

    var body: some View {
        Text("Measure me")
            .onGeometryChange(for: CGSize.self) { proxy in
                proxy.size
            } action: { newSize in
                size = newSize
            }
    }
}

API breakdown:

.onGeometryChange(for: Value.Type) { proxy in
    // extract value
} action: { value in
    // react to change
}

Why this matters:

No layout expansion
Cleaner code
More declarative
Safer state updates

Scroll Offset Example (Modern Approach)

struct ModernScrollOffset: View {
    @State private var offset: CGFloat = 0

    var body: some View {
        ScrollView {
            VStack {
                Text("Header")
                    .font(.largeTitle)
                    .opacity(offset < -50 ? 0 : 1)
                    .onGeometryChange(for: CGFloat.self) { proxy in
                        proxy.frame(in: .global).minY
                    } action: { value in
                        offset = value
                    }

                ForEach(0..<50) { index in
                    Text("Row \(index)")
                        .padding()
                        .frame(maxWidth: .infinity)
                }
            }
        }
    }
}

Output:

Notice:

No container view
No unexpected layout behavior
Pure observation

`GeometryReader` vs `.onGeometryChange`

Feature	`GeometryReader`	`.onGeometryChange`
Participates in layout	Yes	No
Expands to fill space	Yes	No
Custom layout logic	Yes	No
Pure observation	Not ideal	Ideal
Modern direction	Legacy-heavy	Preferred

Rule of thumb:

Use GeometryReader when building layout.
Use .onGeometryChange when observing layout.

Geometry vs the `Layout` Protocol

Since iOS 16, SwiftUI provides the Layout protocol for custom layout containers.

Instead of geometry hacks, you can write:

struct EqualWidthLayout: Layout {
    func sizeThatFits(proposal: ProposedViewSize,
                      subviews: Subviews,
                      cache: inout ()) -> CGSize {

        let width = proposal.width ?? 0
        let height = subviews
            .map { $0.sizeThatFits(.unspecified).height }
            .reduce(0, +)

        return CGSize(width: width, height: height)
    }

    func placeSubviews(in bounds: CGRect,
                       proposal: ProposedViewSize,
                       subviews: Subviews,
                       cache: inout ()) {

        var y = bounds.minY

        for subview in subviews {
            let size = subview.sizeThatFits(.unspecified)

            subview.place(
                at: CGPoint(x: bounds.minX, y: y),
                proposal: ProposedViewSize(width: bounds.width,
                                           height: size.height)
            )

            y += size.height
        }
    }
}

struct LayoutTestView: View {
    var body: some View {
        EqualWidthLayout {
            Text("Short")
                .padding()
                .background(.blue.opacity(0.3))
                .border(.blue)
            
            Text("This is a much longer piece of text")
                .padding()
                .background(.green.opacity(0.3))
                .border(.blue)
            
            Text("Medium length")
                .padding()
                .background(.orange.opacity(0.3))
                .border(.blue)
        }
        .padding()
        .border(.red)
    }
}

Output:

Modern SwiftUI encourages:

Custom layout → Layout
Geometry observation → .onGeometryChange
GeometryReader → edge cases

Common Pitfalls

Wrapping entire screens in `GeometryReader`

Leads to unintended expansion.

Creating layout feedback loops

If geometry updates state that affects layout, you can trigger infinite re-layout cycles.

Be cautious with:

.onGeometryChange { value in
    self.size = value
}

If size affects layout, you may cause continuous updates.

Using geometry when Spacer is enough

Stacks + Spacer solve most layout needs.

Geometry is not the default tool.

The Mental Model

Here’s the refined mental model:

SwiftUI describes layout declaratively.
Layout negotiation happens internally.
GeometryProxy gives you a snapshot of the result.
GeometryReader embeds geometry into layout.
.onGeometryChange observes layout changes.
Layout customizes layout behavior.

Geometry is not about controlling layout.

It’s about understanding it.

Final Thoughts

Most SwiftUI layout bugs don’t come from SwiftUI.

They come from misunderstanding:

Size proposals
Coordinate spaces
When geometry is resolved
How state interacts with layout

Once you internalize:

Proposal-based layout
GeometryProxy as read-only snapshot
Observation vs participation

You stop fighting SwiftUI — and start working with it.

Geometry in SwiftUI is powerful.

Thank you for reading. If you have any questions, feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support my work, Buy me a coffee ☕️

Static vs Dynamic Dispatch in Swift - How Method Dispatch Really Works

Sat, 21 Feb 2026 00:00:00 GMT

Method dispatch is one of those low-level Swift concepts that quietly influences performance, architecture, and API design. Although most apps function perfectly without thinking about dispatch, understanding how Swift decides which method implementation to call helps you write more predictable, efficient, and maintainable code—especially when building frameworks, reusable components, or performance-sensitive features.

This article explains:

What dispatch means in Swift
The difference between static dispatch and dynamic dispatch
How structs, classes, protocols, and generics influence dispatch
How Swift decides which dispatch mechanism to use
Practical guidelines for designing APIs with dispatch in mind

The goal is not to optimize prematurely, but to build a correct mental model of how Swift executes your code.

What Is Dispatch in Swift?

In Swift, dispatch refers to how the compiler and runtime determine which function implementation to execute when a method is called.

Consider this example:

protocol Greeter {
    func greet() -> String
}

struct EnglishGreeter: Greeter {
    func greet() -> String {
        "Hello"
    }
}

let greeter: Greeter = EnglishGreeter()
print(greeter.greet())

Output:

Hello

At the call site (greeter.greet()), Swift must decide which concrete greet() implementation to run. That decision can be made in two ways:

At compile time → Static dispatch
At runtime → Dynamic dispatch

Understanding when each happens is key to understanding Swift’s performance and abstraction model.

Static Dispatch

Static dispatch means the compiler knows the exact method implementation at compile time and generates a direct call to that function. There is no runtime lookup.

Static Dispatch with Value Types

struct Counter {
    func increment(_ value: Int) -> Int {
        value + 1
    }
}

let counter = Counter()
print(counter.increment(10))

Output:

Because Counter is a value type and cannot be subclassed, Swift knows exactly which increment(_:) method to call. The compiler can inline and optimize the call aggressively.

This is one reason Swift encourages the use of structs and enums for modeling data and behavior.

Static Dispatch with `final` Classes

final class Logger {
    func log(_ message: String) {
        print(message)
    }
}

let logger = Logger()
logger.log("Hello")

Output:

Hello

Marking a class as final tells the compiler that the method cannot be overridden. This allows Swift to use static dispatch even for class methods.

Benefits of Static Dispatch

Static dispatch enables the compiler to:

Inline method calls
Remove abstraction overhead
Perform cross-function optimizations
Reduce binary size
Improve performance in hot paths

In many cases, the call disappears entirely after optimization.

Dynamic Dispatch

Dynamic dispatch means the method implementation is chosen at runtime based on the actual type of the instance. This is required when Swift cannot know the concrete implementation at compile time.

Dynamic dispatch enables polymorphism but introduces runtime overhead.

Dynamic Dispatch with Class Inheritance

class Animal {
    func speak() -> String {
        "..."
    }
}

class Dog: Animal {
    override func speak() -> String {
        "Woof"
    }
}

let animal: Animal = Dog()
print(animal.speak())

Output:

Woof

Here:

The static type is Animal
The runtime type is Dog

Swift must determine the correct method implementation at runtime.

This uses Swift’s class dispatch mechanism (virtual method tables).

Dynamic Dispatch with Protocol Existentials

protocol Storage {
    func save()
}

struct DiskStorage: Storage {
    func save() {
        print("Saved to disk")
    }
}

let storage: Storage = DiskStorage()
storage.save()

Output:

Saved to disk

When a protocol is used as a type, Swift erases the concrete type information.

The method call is resolved at runtime using a lookup mechanism.

This flexibility allows you to write abstraction-oriented code, but comes with a small runtime cost.

Protocols, Generics, and Dispatch

Protocols in Swift can participate in either static or dynamic dispatch depending on how they are used.

Protocols as Generic Constraints (Static Dispatch)

protocol Greeter {
    func greet() -> String
}

struct EnglishGreeter: Greeter {
    func greet() -> String { "Hello" }
}

func greet<G: Greeter>(_ greeter: G) {
    print(greeter.greet())
}

greet(EnglishGreeter())

Output:

Hello

Because the compiler specializes this function for each concrete type, method calls are statically dispatched. This allows the compiler to inline and optimize aggressively.

Protocols as Types (Dynamic Dispatch)

protocol Greeter {
    func greet() -> String
}

struct EnglishGreeter: Greeter {
    func greet() -> String { "Hello" }
}

func greet(_ greeter: any Greeter) {
    print(greeter.greet())
}

greet(EnglishGreeter())

Hello

Here, the concrete type is erased. Swift must perform runtime lookup to determine which implementation to call.

How `@objc` and `dynamic` Change Dispatch

When you mark methods with @objc or dynamic, Swift opts into Objective-C runtime dispatch:

class Player: NSObject {
    @objc dynamic func play() {
        print("Playing")
    }
}

let player = Player()
player.play()

Playing

This uses:

Objective-C message sending
Runtime method lookup
KVO compatibility

This is slower than Swift v-table dispatch and should be used only when you need:

KVO
Method swizzling
Objective-C interoperability

Dispatch Behavior Summary

Pattern	Dispatch Type
Generic constraint (`<T: P>`)	Static dispatch
Protocol as a type (`P`)	Dynamic dispatch
Struct / enum methods	Static dispatch
Final class methods	Static dispatch
Overridable class methods	Dynamic dispatch

How Swift Chooses Which Dispatch to Use

Swift follows a few general rules:

If the method cannot be overridden, Swift prefers static dispatch
If the method can be overridden, Swift uses dynamic dispatch
If type information is erased (protocol existentials), Swift uses dynamic dispatch
If the compiler can specialize the call (generics), Swift prefers static dispatch

Swift is designed to favor static dispatch whenever it is safe to do so.

Practical Design Guidelines

Prefer Static Dispatch When

Writing performance-sensitive code
Implementing algorithms and transformations
Designing libraries and reusable components
Working inside tight loops

Prefer:

Structs and enums
Generics
final classes when subclassing is not intended

Prefer Dynamic Dispatch When

Modeling polymorphic domain behavior
Designing plugin-style systems
Abstracting over multiple runtime implementations
Building dependency injection boundaries

Dynamic dispatch improves flexibility and architecture clarity.

Common Misconceptions

"Swift always uses static dispatch"

Swift prefers static dispatch, but falls back to dynamic dispatch when runtime polymorphism is required.

“Dynamic dispatch is slow and should be avoided”

Dynamic dispatch is slightly slower than static dispatch, but the cost is usually negligible in real applications. Architecture clarity often matters more than micro-optimizations.

“Protocols are slow”

Protocols are only dynamically dispatched when used as types.

Protocols used with generics are statically dispatched and highly optimized.

Final Thoughts

Dispatch is a foundational concept in Swift’s performance and abstraction model.

Understanding how and when Swift chooses static versus dynamic dispatch helps you:

Design better APIs
Avoid accidental performance costs
Build more predictable architectures
Reason about optimization behavior

You don’t need to optimize every call site—but knowing how dispatch works lets you make intentional design choices instead of accidental ones.

Thank you for reading. If you have any questions, feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support my work, Buy me a coffee ☕️

Copy-on-Write(CoW) in Swift - How It Works and Why It Optimizes Memory

Sat, 14 Feb 2026 00:00:00 GMT

Swift is designed around two core principles: safety and performance.

At first glance, these goals often appear to conflict. Value types provide safety and predictability, but copying large values repeatedly can be expensive. Reference types provide efficiency through shared storage, but they introduce shared mutable state.

Swift solves this tension elegantly through a memory optimization technique called Copy-on-Write (CoW).

If you’ve used Array, Dictionary, Set, or String, you’ve already relied on Copy-on-Write — even if you didn’t realize it.

In this article, we’ll explore:

What is Copy-on-Write
Why Swift uses it
How it works internally
The role of isKnownUniquelyReferenced
How ensureUnique() preserves value semantics
How to implement your own Copy-on-Write type

What Is Copy-on-Write?

Copy-on-Write is a strategy where:

A value is only copied when a mutation occurs — not when it is assigned.

This allows multiple variables to share the same underlying storage until one of them attempts to modify it.

Instead of eagerly copying data during assignment, Swift delays copying until mutation is required.

This achieves:

Value semantics externally
Shared storage internally
Efficient memory usage
Predictable behavior

The Problem Copy-on-Write Solves

Consider this example:

var numbers = Array(0...1_000_000)
var copy = numbers

If Swift eagerly copied one million integers during assignment, performance would suffer significantly.

Instead:

numbers and copy share the same storage.
No duplication happens yet.
A copy is only created if one of them mutates.

This lazy copying is the essence of Copy-on-Write.

Observing Copy-on-Write in Action

Example 1 — Assignment Without Mutation

var a = [1, 2, 3]
var b = a

At this moment:

a and b share the same storage.
No copy has been made.

Example 2 — Mutation Triggers Copy

b.append(4)

Now Swift performs a check:

Is the underlying storage uniquely referenced?
If not, create a copy before mutating.

Final result:

a = [1, 2, 3]
b = [1, 2, 3, 4]

Value semantics are preserved, but copying only happens when necessary.

How Swift Knows When to Copy

Even though Array is a struct, it stores its elements in a hidden reference-type buffer internally.

Before mutating that buffer, Swift performs a runtime check:

isKnownUniquelyReferenced(_:)

This function determines whether the underlying storage is exclusively owned.

Deep Dive: `isKnownUniquelyReferenced`

The function signature is:

func isKnownUniquelyReferenced<T>(_ object: inout T) -> Bool where T : AnyObject

It returns:

true → if exactly one strong reference exists
false → if multiple strong references exist

In practical terms:

“Is this storage exclusively owned?”

If yes → mutate in place.

If no → create a copy first.

Why the Parameter Is `inout`

You may wonder why the parameter is marked inout.

This is deliberate and essential.

1. Avoiding Temporary Retains

If the parameter were passed normally, Swift might temporarily increase the reference count while passing it into the function. That temporary retain would falsely indicate the object is not unique.

Using inout prevents that extra reference increment and ensures the check reflects the true ARC count.

2. Enforcing Memory Exclusivity

Swift enforces strict memory access rules. By requiring inout, the compiler guarantees exclusive access to the variable during the check.

This prevents race conditions and overlapping access during mutation.

What “Known” Means

The name is precise:

isKnownUniquelyReferenced

It does not guarantee uniqueness under every conceivable concurrency scenario. It guarantees uniqueness when Swift can safely prove it under ARC and exclusivity rules.

This is sufficient for implementing Copy-on-Write correctly in standard Swift usage.

Value Semantics Is Not Copy-on-Write

It is important to clarify a common misconception:

Value semantics is not the same as Copy-on-Write.

All structs in Swift have value semantics. That means:

Assignment creates a new value.
Mutation does not affect the original instance.

However, Copy-on-Write is not automatically applied to all structs.

Copy-on-Write is a deliberate engineering decision made by the implementer of a type.

For example:

Array uses Copy-on-Write.
Dictionary uses Copy-on-Write.
Set uses Copy-on-Write.
String uses Copy-on-Write.

But a simple struct like this:

struct Point {
    var x: Int
    var y: Int
}

does not use Copy-on-Write.

When you assign Point, its stored properties are copied immediately because they are small and inexpensive.

Why Some Types Use Copy-on-Write

Copy-on-Write exists purely for performance optimization.

It is applied when:

The underlying storage is large
Copying eagerly would be expensive
Shared storage improves efficiency
Value semantics must still be preserved

In other words:

Copy-on-Write is an optimization strategy, not a language rule.

The Architectural Distinction

Value semantics → language-level behavior
Copy-on-Write(CoW) → storage optimization pattern
ARC → runtime mechanism enabling uniqueness checks

These are related — but not identical.

Understanding this distinction separates surface-level familiarity from architectural understanding of Swift’s design.

Implementing Copy-on-Write Manually

To understand the mechanism fully, let’s build our own CoW type.

Step 1 — Reference Storage

final class Storage {
    var value: Int

    init(value: Int) {
        self.value = value
    }
}

We use a final class because:

Classes are reference types.
final avoids dynamic dispatch overhead.

Step 2 — Struct Wrapper

struct Counter {
    private var storage: Storage

    init(value: Int) {
        self.storage = Storage(value: value)
    }

    var value: Int {
        get { storage.value }
        set {
            ensureUnique()
            storage.value = newValue
        }
    }
}

Externally, Counter behaves like a value type.

Internally, it shares reference storage.

The Critical Mutation Gate: `ensureUnique()`

extension Counter {
    private mutating func ensureUnique() {
        if !isKnownUniquelyReferenced(&storage) {
            storage = Storage(value: storage.value)
        }
    }
}

This function guarantees:

Before mutation occurs, the struct owns its storage exclusively.

Why `ensureUnique()` Is `mutating`

If the storage is shared, we assign a new instance to storage. That modifies self, so the method must be marked mutating.

What `ensureUnique()` Actually Does

It does not mutate the value directly.

It only ensures that mutation can occur safely.

Think of it as a safety checkpoint before modification.

Step-by-Step Execution Flow

Consider:

var a = Counter(value: 10)
var b = a

b.value = 20

Step 1 — Assignment

a ──┐
    ├── Storage(value: 10)
b ──┘

Reference count = 2.

Step 2 — Mutation Begins

b.value = 20 calls:

ensureUnique()

Swift checks:

isKnownUniquelyReferenced(&storage)

Result: false

Step 3 — Copy Created

storage = Storage(value: storage.value)

Now each instance has its own storage.

Step 4 — Safe Mutation

storage.value = 20

Final state:

a.value // 10
b.value // 20

Value semantics preserved.

Why This Pattern Is Essential

If you skipped ensureUnique():

storage.value = newValue

You would accidentally mutate shared storage.

Your struct would behave like a class.

Value semantics would be broken silently.

The uniqueness check is what guarantees correctness.

Performance Characteristics

The uniqueness check:

Is O(1)
Reads ARC metadata
Does not allocate memory unless needed

Copy-on-Write performs best when:

Data is large
Reads are frequent
Mutations are relatively rare

However, repeated copying inside tight mutation loops can reduce performance.

Understanding this helps you design more efficient systems.

Why Swift Uses Copy-on-Write

Copy-on-Write gives Swift the best of both worlds:

Feature	Struct + CoW	Class
Value semantics	✅	❌
Shared storage	✅	✅
Predictable behavior	✅	❌
Memory efficiency	✅	✅

It enables:

Safer APIs
Better SwiftUI data modeling
Efficient large collections
Scalable architecture

Key Design Principles for Custom CoW Types

When implementing Copy-on-Write:

Use a final class for storage.
Keep storage private.
Gate every mutation behind ensureUnique().
Never expose the reference storage directly.
Ensure copying is deep enough to preserve isolation.

These rules are non-negotiable.

Final Thoughts

Copy-on-Write is not just a performance trick. It is a foundational design pattern in Swift.

It allows Swift to deliver:

Value semantics
High performance
Memory efficiency
Predictable behavior

The partnership between:

isKnownUniquelyReferenced
ensureUnique()
ARC
Struct wrappers

is what makes Swift’s standard library both elegant and powerful.

Mastering Copy-on-Write deepens your understanding of how Swift balances safety with efficiency — and equips you to design high-performance abstractions in your own code.

Thank you for reading. If you have any questions, feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support my work, Buy me a coffee ☕️

AsyncStream & AsyncThrowingStream in Swift - Real-Time Data Sync Explained

Wed, 04 Feb 2026 00:00:00 GMT

Modern apps are no longer single-device experiences.

Users expect their data to stay perfectly in sync across iPhone, iPad, and Mac, with updates appearing instantly—no refresh button, no manual sync. This expectation becomes even stronger in productivity apps like invoicing, accounting, or note-taking, where consistency and correctness matter.

In my invocing app Reckord, users can sign in on multiple devices and continue their work seamlessly. To support this, I needed a real-time data synchronization system that:

Reacts immediately to remote changes
Integrates cleanly with Swift’s async/await model
Cancels automatically when views disappear
Avoids callback-heavy, hard-to-maintain code

To achieve this, I built the entire real-time sync layer using AsyncStream and AsyncThrowingStream.

This article explains:

What is AsyncStream
What is AsyncThrowingStream
When to use each
How they work internally
And how I used them to implement real-time multi-device syncing in Reckord

The Problem with Callback-Based Real-Time APIs

Most real-time systems—including Firebase Firestore—are built around callbacks.

A typical Firestore listener looks like this:

listener = query.addSnapshotListener { snapshot, error in
    // Called every time data changes
}

While functional, this approach has drawbacks in modern SwiftUI apps:

Hard to integrate with async/await
Manual listener cleanup
Complex cancellation logic
Business logic scattered across closures

What we want is something like this:

for await update in updates {
    apply(update)
}

This is exactly what AsyncSequence enables—and AsyncStream is how we create one.

`AsyncSequence`: The Foundation

Both AsyncStream and AsyncThrowingStream conform to AsyncSequence.

An AsyncSequence:

Produces multiple values over time
Is consumed using for await
Integrates naturally withTask and SwiftUI lifecycles
Supports structured cancellation

You can think of it as:

The async/await equivalent of a data stream.

What is `AsyncStream`?

AsyncStream is a Swift type that allows you to create an asynchronous sequence of values that are produced over time, rather than all at once.

In simple terms:

AsyncStream lets you manually feed values into an async for await loop.

You can find the official Apple documentation here: AsyncStream.

Why `AsyncStream` Exists

Before Swift Concurrency, when values arrived over time, we usually relied on:

Closures
Delegates
Notifications
Combine publishers

These approaches don’t integrate naturally with async/await.

AsyncStream exists to bridge non-async, callback-based APIs into Swift’s structured concurrency world.

How `AsyncStream` Works (Conceptually)

An AsyncStream has two sides:

Producer: This is where values are generated using a Continuation.
Consumer: This is where values are consumed using for await.

The producer and consumer can live in completely different parts of your app.

Anatomy of `AsyncStream`

AsyncStream<Element> { continuation in
    continuation.yield(value)
    continuation.finish()
}

Element → type of values emitted
continuation.yield(_:) → sends a value to consumers
continuation.finish() → ends the stream

Once finished, no more values can be emitted.

A Very Simple Example

Let’s say you want to emit numbers over time.

func numberStream() -> AsyncStream<Int> {
    AsyncStream { continuation in
        Task {
            for i in 1...5 {
                continuation.yield(i)
                try await Task.sleep(for: .seconds(1))
            }
            continuation.finish()
        }
    }
}

Consume it like this:

Task {
    for await number in numberStream() {
        print(number)
    }
}

Output:

This is not a loop returning values — it’s a stream pushing values asynchronously.

Important Characteristics of `AsyncStream`

Can emit multiple values
Works naturally with async/await
Cannot throw errors
Must be manually finished
Supports cancellation

Because it cannot fail, AsyncStream is best suited for:

UI events
Timers
State changes
In-memory signals

What is `AsyncThrowingStream`?

AsyncThrowingStream is the error-capable sibling of AsyncStream.

It represents an async sequence that:

Emits values over time
Can fail with an error

In other words:

AsyncThrowingStream is AsyncStream + error handling.

You can find the official Apple documentation here: AsyncThrowingStream.

Why `AsyncThrowingStream` Exists

Most real-world asynchronous systems can fail:

Network requests
Databases
File IO
Permissions
Authentication

Using AsyncStream for such systems would mean:

Errors must be hidden
Or sent as values (bad idea)
Or handled outside the stream (messy)

AsyncThrowingStream solves this cleanly.

Anatomy of `AsyncThrowingStream`

AsyncThrowingStream<Element, Error> { continuation in
    continuation.yield(value)
    continuation.finish(throwing: error)
}

Key differences:

Can call finish(throwing:)
Consumers must use for try await

Simple Example with Errors

Imagine a stream that emits random numbers but fails sometimes.

enum RandomError: Error {
    case unlucky
}

func randomNumberStream() -> AsyncThrowingStream<Int, Error> {
    AsyncThrowingStream { continuation in
        Task {
            for _ in 1...10 {
                let number = Int.random(in: 1...10)

                if number == 7 {
                    continuation.finish(throwing: RandomError.unlucky)
                    return
                }

                continuation.yield(number)
                try await Task.sleep(for: .seconds(1))
            }

            continuation.finish()
        }
    }
}

Consume it like this:

Task {
    do {
        for try await number in randomNumberStream() {
            print(number)
        }
    } catch {
        print("Stream failed:", error)
    }
}

Output:

3
2
4
Stream failed: unlucky

It generates random numbers between 1 and 10 and prints them. If the generated number is 7, it stops generating numbers and throws an error.

Key Characteristics of `AsyncThrowingStream`

Emits multiple values
Can terminate with an error
Natural error propagation
Structured cancellation
Ideal for networked systems

This makes it perfect for real-time databases like Firestore.

`AsyncStream` vs `AsyncThrowingStream` (Mental Model)

Question	AsyncStream	AsyncThrowingStream
Can this operation fail?	❌ No	✅ Yes
Needs `try` to consume?	❌ No	✅ Yes
UI / in-memory events	✅	⚠️
Network / database	❌	✅

If you’re unsure, ask yourself:

Can this realistically fail at runtime?
If yes → use AsyncThrowingStream.

How I Implemented Real-Time Multi-Device Sync in Reckord

In Reckord, users can sign in on multiple devices and expect their data to stay perfectly in sync.

This means:

Any change on one device
Must instantly appear on all other devices
Without refresh, polling, or manual sync

Firestore already provides real-time updates via snapshot listeners, but those APIs are callback-based.

My goal was to:

Convert Firestore listeners into async/await
Automatically manage lifecycle and cancellation
Keep UI code clean and predictable

Step 1: Model Firestore as an `AsyncThrowingStream`

Firestore snapshot listeners:

Emit initial data
Emit updates continuously
Can fail
Must be removed manually

That maps exactly to AsyncThrowingStream.

func invoicesStream(userId: String) -> AsyncThrowingStream<[Invoice], Error> {
    AsyncThrowingStream { continuation in
        let listener = firestore
            .collection("invoices")
            .whereField("userId", isEqualTo: userId)
            .addSnapshotListener { snapshot, error in
                if let error {
                    continuation.finish(throwing: error)
                    return
                }

                guard let snapshot else { 
                    continuation.finish(throwing: FirestoreServiceError.invalidPath)
                    return 
                }

                do {
                    var invoices: [Invoice] = []
                    for document in snapshot.documents {
                        let parsedInvoice = try FirestoreParser.parse(document.data(), type: Invoice.self)
                        invoices.append(parsedInvoice)
                    }
                    continuation.yield(invoices)
                } catch {
                    continuation.finish(throwing: FirestoreServiceError.parseError)
                }
            }

        continuation.onTermination = { _ in
            listener.remove()
        }
    }
}

This single function:

Turns Firestore into an async sequence
Handles real-time updates
Cleans up listeners automatically

Step 2: Consume the Stream in SwiftUI

@MainActor
func observeInvoices() async {
    do {
        for try await invoices in invoicesStream(userId: userId) {
            self.invoices = invoices
        }
    } catch {
        self.errorMessage = error.localizedDescription
    }
}

And attach it to the view lifecycle:

.task {
    await observeInvoices()
}

Step 3: Automatic Multi-Device Sync

Now the flow looks like this:

Device A updates data
Firestore emits a snapshot update
AsyncThrowingStream yields new values
Device B receives changes instantly
SwiftUI view updates automatically

No polling.
No manual refresh.
No Combine.

Just structured concurrency.

Where `AsyncStream` Fits in Reckord

While Firestore uses AsyncThrowingStream, I use AsyncStream internally for:

Authentication status changes
Subscription state changes

This keeps error handling where it belongs and avoids overusing throwing streams.

Final Thoughts

AsyncStream and AsyncThrowingStream are foundational tools for modern Swift development.

They allow you to:

Model real-time systems cleanly
Embrace structured concurrency
Write predictable, maintainable code
Build true multi-device experiences

They form the backbone of Reckord ’s real-time sync system—and once you adopt them, callback-heavy designs start to feel outdated.

Thank you for reading. If you have any questions, feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support my work, Buy me a coffee ☕️

Designing a Scalable App-Wide Theming System in SwiftUI

Mon, 26 Jan 2026 00:00:00 GMT

Theming is one of those features users notice instantly — and one of the easiest places to introduce inconsistency if it’s not designed carefully.

In my invocing app Reckord, users can choose an app theme directly from Settings. Once changed, that theme needs to apply everywhere: text, backgrounds, surfaces, outlines — instantly and consistently.

SwiftUI gives us powerful tools to solve this cleanly. Instead of passing theme objects through view initializers or relying on global singletons, Reckord uses a SwiftUI-native, environment-driven approach, backed by a token-based design system.

This article walks through the exact implementation used in Reckord, while also highlighting which parts are implementation choices, not hard requirements.

Goals of the Theming System

A single source of truth for UI styling
App-wide access without prop drilling
Instant UI updates when the user changes theme
First-class support for System Light/Dark Mode
A foundation that can expand beyond colors

The last point is important: this system is intentionally abstract. It is designed to grow into fonts, spacing, corner radius, and other design tokens — not just colors.

High-Level Architecture

SwiftUI View
   ↓
EnvironmentValues.theme
   ↓
Theme abstraction
   ↓
Design tokens (colors, fonts, spacing…)
   ↓
User-selected theme (persisted)

Views never know:

where the theme comes from
how it’s stored
which implementation is used under the hood

They only consume semantic values.

Understanding SwiftUI Environment

Apple uses it internally for:

color scheme
dynamic type size
locale
accessibility settings

We can extend the same mechanism for app-wide theming.

Before diving into the implementation, it’s important to understand the two building blocks that make this possible: EnvironmentKey and EnvironmentValues.

What Is `EnvironmentKey`?

An EnvironmentKey defines a custom value that can live inside SwiftUI’s environment.

struct ThemeEnvKey: EnvironmentKey {
    static let defaultValue: ThemeToken = AppTheme()
}

class AppTheme: ThemeToken {
    let spacing = SpacingTokens()
    let colors = ColorTokens()
}

This does two things:

Declares the type of value stored in the environment
Provides a default value so views never crash due to missing data

SwiftUI uses this default unless the value is overridden higher in the view hierarchy.

What Is `EnvironmentValues`?

EnvironmentValues is a type-safe container that SwiftUI uses to store environment data.

We extend it to expose a clean API:

extension EnvironmentValues {
    var theme: ThemeToken {
        get { self[ThemeEnvKey.self] }
        set { self[ThemeEnvKey.self] = newValue }
    }
}

After this, theme behaves just like a built-in SwiftUI environment value.

Reading from the Environment

Any SwiftUI view can now access the theme like this:

@Environment(\.theme) private var theme

SwiftUI automatically re-renders the view whenever the theme changes — no manual observation required.

Defining a Theme Abstraction

The ThemeToken protocol defines what a theme provides, not how it is implemented.

protocol ThemeToken {
    var colors: ColorTokens { get }
    var spacing: SpacingTokens { get }
}

This abstraction is intentional.

Later, this can evolve into:

protocol ThemeToken {
    var colors: ColorTokens { get }
    var spacing: SpacingTokens { get }
    var typography: TypographyTokens { get }
    var radius: RadiusTokens { get }
}

Nothing in the view layer would need to change.

Centralizing Styling with Design Tokens

All UI styling in Reckord flows through semantic tokens, not raw values.

For colors, this is done using ColorTokens.

Instead of scattering Color(...) throughout the app, every color flows through semantic properties such as:

foregroundPrimary
backgroundSecondary
surfacePrimary
outlineTertiary

Example: Colors

struct ColorTokens {
    @Shared(.currentTheme) var currentTheme
    
    // MARK: - Foreground colors
    
    /// Used for primary text, selected icons, etc.
    public var foregroundPrimary: Color {
        if currentTheme == .system {
            Color(uiColor: .label)
        } else {
            currentTheme.color.foregroundPrimary
        }
    }
    
    /// Used for secondary text like subtitles, unselected icons, etc.
    public var foregroundSecondary: Color {
        if currentTheme == .system {
            Color(uiColor: .secondaryLabel)
        } else {
            currentTheme.color.foregroundSecondary
        }
    }
    
    /// Used for tertiary text like placeholders, disabled icons, etc.
    public var foregroundTertiary: Color {
        if currentTheme == .system {
            Color(uiColor: .secondaryLabel)
        } else {
            currentTheme.color.foregroundTertiary
        }
    }
    
    /// Used for placeholder text like placeholders in text fileds and text views etc.
    public var foregroundPlaceholder: Color {
        if currentTheme == .system {
            Color(uiColor: .placeholderText)
        } else {
            currentTheme.color.foregroundTertiary
        }
    }
    
    // MARK: - Inverted colors
    
    /// Used for primary text on inverted backgrounds, selected icons, etc.
    public var invertedForegroundPrimary: Color {
        if currentTheme == .system {
            Color(uiColor: .white)
        } else {
            currentTheme.color.invertedForegroundPrimary
        }
    }
    
    /// Used for secondary text on inverted backgrounds, unselected icons, etc.
    public var invertedForegroundSecondary: Color {
        currentTheme.color.invertedForegroundSecondary
    }
    
    /// Used for tertiary text on inverted backgrounds, disabled icons, etc.
    public var invertedForegroundTertiary: Color {
        currentTheme.color.invertedForegroundTertiary
    }
    
    // MARK: - Background colors
    
    /// Used for main content background, app background, etc.
    public var backgroundPrimary: Color {
        if currentTheme == .system {
            Color(uiColor: .systemGroupedBackground)
        } else {
            currentTheme.color.backgroundPrimary
        }
    }
    
    /// Used for secondary backgrounds, cards, etc.
    public var backgroundSecondary: Color {
        if currentTheme == .system {
            Color(uiColor: .secondarySystemGroupedBackground)
        } else {
            currentTheme.color.backgroundSecondary
        }
    }
    
    /// Used for tertiary backgrounds, inactive buttons, etc.
    public var backgroundTertiary: Color {
        if currentTheme == .system {
            Color(uiColor: .tertiarySystemBackground)
        } else {
            currentTheme.color.backgroundTertiary
        }
    }
    
    // MARK: - Surface colors
    
    /// Used for surfaces with opacity. Cards, pills, etc.
    public var surfacePrimary: Color {
        currentTheme.color.surfacePrimary
    }
    
    /// Used for secondary surfaces with opacity. Scrims, overlays, tooltips, etc.
    public var surfaceSecondary: Color {
        currentTheme.color.surfaceSecondary
    }
    
    /// Used for tertiary surfaces with opacity. Tooltips, popovers, etc.
    public var surfaceTertiary: Color {
        currentTheme.color.surfaceTertiary
    }
    
    // MARK: - Inverted surface colors
    
    /// Used for elements that need dark backgrounds, like cards, sheets, etc.
    public var invertedSurfacePrimary: Color {
        currentTheme.color.invertedSurfacePrimary
    }
    
    /// Used for elements that need slightly less darker backgrounds, like panels, dialogs, etc.
    public var invertedSurfaceSecondary: Color {
        currentTheme.color.invertedSurfaceSecondary
    }
    
    // MARK: - Inverted background colors
    
    /// Used for main content background on dark backgrounds, app background, etc.
    public var invertedBackgroundPrimary: Color {
        currentTheme.color.invertedBackgroundPrimary
    }
    
    /// Used for secondary content background on dark backgrounds, card background, etc.
    public var invertedBackgroundSecondary: Color {
        currentTheme.color.invertedBackgroundSecondary
    }
    
    /// Used for tertiary content background on dark backgrounds, modal background, etc.
    public var invertedBackgroundTertiary: Color {
        if currentTheme == .system {
            Color(uiColor: .systemBlue)
        } else {
            currentTheme.color.invertedBackgroundTertiary
        }
    }
    
    // MARK: - Outline colors
    
    /// Used for primary outlines, borders, etc.
    public var outlinePrimary: Color {
        currentTheme.color.outlinePrimary
    }
    
    /// Used for secondary outlines, borders, etc.
    public var outlineSecondary: Color {
        currentTheme.color.outlineSecondary
    }
    
    /// Used for tertiary outlines, borders, etc.
    public var outlineTertiary: Color {
        currentTheme.color.outlineTertiary
    }
}

Example: Spacing

struct SpacingTokens {
    ///2
    public let xxxs: CGFloat =  2
    
    ///4
    public let xxs: CGFloat = 4
    
    ///8
    public let xs: CGFloat = 8
    
    ///12
    public let sm: CGFloat = 12
    
    ///16
    public let md: CGFloat = 16
    
    ///24
    public let lg: CGFloat = 24
    
    ///32
    public let xl: CGFloat = 32
    
    ///48
    public let xxl: CGFloat = 48
    
    ///64
    public let xxxl: CGFloat = 64
}

This ensures:

consistent usage across the app
easy refactoring
readable UI code

Modeling Theme Choices with `Theme`

Users can choose from the following themes in Reckord:

System
Graphite
Sky
Tomato
Gold
Grass
Ruby

These options are modeled using a strongly typed enum:

enum Theme: String, CaseIterable {
    case system = "System"
    case graphite = "Graphite"
    case sky = "Sky"
    case tomato = "Tomato"
    case gold = "Gold"
    case grass = "Grass"
    case ruby = "Ruby"
    
    var color: LCHColor {
        switch self {
        case .system:
            return Color.proBlue
        case .graphite:
            return Color.proGray
        case .sky:
            return Color.proSky
        case .tomato:
            return Color.proTomato
        case .gold:
            return Color.proGold
        case .grass:
            return Color.proGrass
        case .ruby:
            return Color.proRuby
        }
    }
}

Why an Enum? Using an enum provides:

Compile-time safety
Easy iteration for Settings UI
Clean persistence using raw values
A single source of truth for available themes

Mapping Themes to Color Palettes

In Reckord, each Theme maps to an LCHColor palette:

var color: LCHColor

These palettes are sourced from ColorTokensKit-Swift, a library created by the talented designer Siddhant Mehta, offering:

LCH-based color tokens
Built-in Light/Dark Mode handling
Perceptually balanced color values

👉 https://github.com/metasidd/ColorTokensKit-Swift

NOTE

ColorTokensKit is not required for this system.

You can replace it with:

system colors
custom Color values
asset catalog colors
your own token structs

The system does not depend on any specific color library — only on the idea of semantic color tokens.

Persisting the Selected Theme

In Reckord, the selected theme is persisted using Point-Free’s Sharing library, backed by UserDefaults.

extension SharedKey where Self == AppStorageKey<Theme>.Default {
    static var currentTheme: Self {
        Self[.appStorage("currentTheme"), default: .system]
    }
}

👉 https://github.com/pointfreeco/swift-sharing

This gives:

persistence across launches
reactive updates
type safety

NOTE

Using the Sharing library is optional.

You can implement the same system using:

@AppStorage
a custom observable state
any persistence layer

What matters is that the selected theme is reactive, not how it’s stored.

Using the Theme in Views

From a view’s perspective, theming is intentionally simple:

struct InvoiceRow: View {
    @Environment(\.theme) private var theme

    var body: some View {
        VStack(spacing: theme.spacing.xs) {
            Text("Invoice #1024")
                .bold()
                .foregroundStyle(theme.colors.foregroundPrimary)

            Text("Paid")
                .font(.caption)
                .foregroundStyle(theme.colors.foregroundSecondary)
        }
    }
}

Views don’t care:

how the theme is stored
which library is used
whether it’s system or custom

They only care about meaningful tokens.

Visual Result

Below are screenshots from Reckord app showing different themes applied to the same screens:

Theme changes apply instantly and consistently across the app.

Final Thoughts

SwiftUI’s environment system is a powerful but often underused tool for app-wide concerns like theming.

By combining:

EnvironmentKey and EnvironmentValues
an abstract theme model
semantic design tokens
reactive persistence

Reckord achieves a theming system that is:

Declarative
Flexible
Library-agnostic
Easy to evolve

Whether you use ColorTokensKit, system colors, or your own palette, this system gives you room to grow — from colors and spacings today to a full design system tomorrow.

Thank you for reading. If you have any suggestions or a better approach, feel free to connect with me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

SwiftUI Observation Framework Explained - Using @Observable in iOS 17

Mon, 19 Jan 2026 00:00:00 GMT

SwiftUI’s rendering system is built around a single core idea: views are cheap to recreate, but state must be preserved. To support this model, SwiftUI needs a reliable way to observe changes in data and update only the parts of the UI that depend on those changes.

Prior to iOS 17, this responsibility was handled primarily by ObservableObject and @Published. While effective, that approach introduced boilerplate, relied heavily on Combine, and triggered view updates at the object level rather than the property level.

With iOS 17, Apple introduced the Observation framework, centered around the @Observable macro. This new system provides a lighter, more precise way to model observable state in SwiftUI.

This article explains how the Observation framework works, how to use @Observable correctly in SwiftUI, how it differs from ObservableObject, and how to migrate existing code safely.

Why Apple Introduced a New Observation System

Before iOS 17, observable state in SwiftUI typically looked like this:

class UserViewModel: ObservableObject {
    @Published var name: String = ""
    @Published var isPremium: Bool = false
}

This approach worked, but it had several drawbacks:

Boilerplate everywhere: Every observable type had to conform to ObservableObject, and every changing property required @Published.
Over-notification: A change to any @Published property invalidates all dependent views, even if they don’t use that property.
Manual correctness: Forgetting @Published silently breaks UI updates.

Apple’s answer to these problems is the Observation framework, which introduces a compiler-driven observation system.

Introducing `@Observable`

At the core of the new system is the @Observable macro.

@Observable
class User {
    var name: String = ""
    var isPremium: Bool = false
}

That’s it. No ObservableObject. No @Published.

Every stored property becomes observable by default.

Key Design Goals

Apple designed @Observable with three principles in mind:

Explicit at the type level: You mark what is observable, not how each property behaves.
Fine-grained dependency tracking: Views only re-render when the specific properties they read change.
Minimal runtime overhead: Observation metadata is generated at compile time.

How Observation Actually Works

This is where the new system truly shines.

Property-Level Dependency Tracking

With @Observable, SwiftUI tracks which properties are read during view evaluation.

struct ProfileView: View {
    @State private var user = User()

    var body: some View {
        Text(user.name)
    }
}

In this example:

SwiftUI records that ProfileView depends on user.name
Changing user.isPremium does not invalidate this view
Only updates to name trigger a re-render

This is a major improvement over ObservableObject, where any @Published change triggers objectWillChange.

Initializing Observable Models in SwiftUI

SwiftUI view structs are ephemeral and may be recreated frequently. For this reason, observable models must be initialized in stable storage.

Incorrect Initialization

struct SettingsView: View {
    private let settings = InvoiceSettingsModel()

    var body: some View {
        Text(settings.currencyCode)
    }
}

This may appear correct, but the model can be recreated whenever the view is reinitialized.

Correct Initialization Using `@State`

Observable models should be initialized using @State.

import SwiftUI
import Observation

@Observable
class InvoiceSettingsModel {
    var currencyCode: String = "USD"
    var includeTax: Bool = false
}

struct SettingsView: View {
    @State private var model = InvoiceSettingsModel()

    var body: some View {
        Form {
            Toggle("Include Tax", isOn: $model.includeTax)
            Text("Currency: \(model.currencyCode)")
        }
    }
}

Here:

@State guarantees stable model lifetime
@Observable enables fine-grained updates
SwiftUI updates only when accessed properties change

To understand why an @Observable class must be initialized using @State within the SwiftUI hierarchy, refer to this excellent article by Natalia Panferova:
Initializing @Observable classes within the SwiftUI hierarchy

Excluding Properties from Observation

Not every property should trigger UI updates.

@Observable
class AnalyticsModel {
    var visibleCount = 0

    @ObservationIgnored
    var internalCache: [String: Int] = [:]
}

Use @ObservationIgnored to exclude properties that:

Are derived or transient
Don’t affect UI rendering
Are performance-sensitive

Comparison: Old vs New Observation

Old (`ObservableObject`)

class ViewModel: ObservableObject {
    @Published var title: String = ""
    @Published var isLoading = false
}

struct ContentView: View {
    @ObservedObject var model = ViewModel()

    var body: some View {
        Text(model.title)
    }
}

New (`@Observable`)

@Observable
class ViewModel {
    var title: String = ""
    var isLoading = false
}

struct ContentView: View {
    @State private var model = ViewModel()

    var body: some View {
        Text(model.title)
    }
}

Key Differences

Aspect	`ObservableObject`	`@Observable`
Boilerplate	High	Minimal
Property annotations	Required	Automatic
Dependency tracking	Object-wide	Property-level
Compile-time safety	Low	High

Performance and Predictability

Because dependencies are tracked at the property level:

Views re-render less often
Complex screens scale better
Large observable models no longer cause global invalidation

This makes the Observation framework particularly useful for:

Settings screens
Dashboards
Forms with many fields
State-heavy business apps

Migration Strategy

You don’t need to migrate everything at once.

Recommended Approach

Keep existing ObservableObject models working
Introduce @Observable for new features
Gradually refactor models with heavy @Published usage
Remove @ObservedObject where possible

SwiftUI fully supports mixing both systems.

Common Pitfalls

Mutating outside the main actor: Observation does not automatically enforce threading rules.
Assuming all mutations trigger updates: Only observed properties that are read by views cause re-renders.
Over-modeling: Don’t make everything observable—prefer smaller, focused models.

When Should You Use `@Observable`?

Use it when:

Targeting iOS 17+
You want cleaner state management
You care about fine-grained view updates

Avoid it if:

You must support older OS versions
You rely heavily on Combine publishers

Final Thoughts

The Observation framework is not just a syntactic improvement—it’s a fundamental shift in how SwiftUI tracks state changes.

By moving observation to the compiler level, Apple has made SwiftUI:

More efficient
More predictable
Easier to reason about

If you’re building modern SwiftUI apps targeting iOS 17 and later, @Observable should be your default choice for shared state.

Thank you for reading. If you have any questions feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

Xcode Templates Explained - Speed Up iOS Development by Eliminating Boilerplate

Mon, 12 Jan 2026 00:00:00 GMT

While building production apps, efficiency rarely comes from writing less code. It comes from writing the same code fewer times.

This article explains how Xcode Templates can be used to automate repetitive setup, improve consistency, and significantly speed up everyday development. The ideas apply to any architecture or project style.

To ground the discussion, I’ll start with a real problem I encountered while working on my invocing app Reckord, and then walk through how Xcode File Templates became a practical solution.

The Problem I Faced While Building Reckord

Reckord is a production iOS app built with a strong emphasis on structure and consistency. The app follows The Composable Architecture (TCA), which encourages explicit, well-defined components.

This structure is powerful, but it comes with a tradeoff.

Every time I added a new screen or feature, I had to:

Create a new SwiftUI view
Create a corresponding reducer file
Add standard imports
Define state, actions, and reducer structure
Wire everything together correctly

None of this was difficult. But all of it was repetitive.

I found myself copying boilerplate code from an existing feature, pasting it into a new file, and carefully renaming types. Over time, this workflow started to slow me down and introduced small but avoidable risks—missed renames, leftover references, or minor inconsistencies.

The problem wasn’t TCA. The problem was manual repetition.

That’s when I decided to move this repetition into the tooling itself.

Why Xcode File Templates Are the Right Tool

Xcode already provides a mechanism to solve this exact problem: File Templates.

Instead of manually creating files and pasting code, Xcode File Templates allow you to:

Define a reusable file structure
Encode your project’s conventions
Automatically replace placeholders like file names
Generate ready-to-use files in seconds

In my case, I created:

A template for views
A template for reducers

From that point onward, adding a new feature in Reckord became a predictable, low-friction operation.

What Are Xcode Templates?

Xcode Templates are customizable file blueprints that appear in:

File → New → File…

A template can include:

One or more Swift files
Predefined imports
Standardized structure
Placeholder tokens replaced by Xcode

When you select a template and provide a name, Xcode generates the file exactly according to the template definition.

This allows Xcode to work with your workflow instead of against it.

Why This Matters Beyond Reckord

Although my motivation came from working with TCA, file templates are architecture-agnostic.

They are equally useful for:

SwiftUI views
Feature modules
View models or controllers
Test files
Design system components

Any time you notice repeated setup, file templates are worth considering.

How Xcode Templates Work

At a high level, a template consists of:

A .xctemplate directory
One or more template source files
A TemplateInfo.plist
Placeholder tokens such as ___FILEBASENAME___

Where Custom Templates Live

Custom templates are stored locally at:

~/Library/Developer/Xcode/Templates/

Each folder inside this directory becomes a category in Xcode.

NOTE: If you do not find Templates directory then create by your self.

Example: Creating Templates for the Reckord Workflow

To support my workflow, I created a dedicated template group:

Templates/
└── The Composable Architecture(TCA)
    ├── TCAView.xctemplate
    └── TCAReducer.xctemplate

This keeps arcitecture-specific templates organized and easy to find.

TCAView Template

Inside The Composable Architecture(TCA) folder, I added a template folder named: TCAView.xctemplate. It contain two files: ___FILEBASENAME___.swift and TemplateInfo.plist

TIP: Xcode already ships with well-structured, production-ready templates that can be reused as a foundation. A practical approach is to copy the existing Swift file template provided by Xcode and customize it for your own needs. The standard Swift file template is located at: /Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/MultiPlatform/Source/Swift File.xctemplate

Contains of ___FILEBASENAME___.swift file:

//___FILEHEADER___

import SwiftUI
import ComposableArchitecture

struct ___FILEBASENAMEASIDENTIFIER___: View {
    @Bindable var store: StoreOf<___FILEBASENAMEASIDENTIFIER___Domain>
    
    var body: some View {
        Text("___FILEBASENAMEASIDENTIFIER___")
    }
}

#Preview {
    ___FILEBASENAMEASIDENTIFIER___(
        store: Store(
            initialState: ___FILEBASENAMEASIDENTIFIER___Domain.State(),
            reducer: {
                ___FILEBASENAMEASIDENTIFIER___Domain()
            }
        )
    )
}

Contains of TemplateInfo.plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>SupportsSwiftPackage</key>
	<true/>
	<key>Kind</key>
	<string>Xcode.IDEFoundation.TextSubstitutionFileTemplateKind</string>
	<key>Description</key>
	<string>A SwiftUI Custom TCA View with Preview</string>
	<key>Summary</key>
	<string>TCA View</string>
	<key>SortOrder</key>
	<string>1</string>
	<key>Image</key>
	<dict>
		<key>FileTypeIcon</key>
		<string>swift</string>
	</dict>
	<key>AllowedTypes</key>
	<array>
		<string>public.swift-source</string>
	</array>
	<key>Platforms</key>
	<array/>
	<key>DefaultCompletionName</key>
	<string>TCAView</string>
	<key>MainTemplateFile</key>
	<string>___FILEBASENAME___.swift</string>
	<key>Options</key>
	<array>
		<dict>
			<key>NotPersisted</key>
			<true/>
			<key>Type</key>
			<string>text</string>
			<key>Description</key>
			<string>The name of the view to create</string>
			<key>Name</key>
			<string>Name of View:</string>
			<key>Required</key>
			<true/>
			<key>Identifier</key>
			<string>productName</string>
		</dict>
	</array>
</dict>
</plist>

TCAReducer Template

Similarly, the TCAReducer.xctemplate contains a predefined structure.

Contains of ___FILEBASENAME___.swift file:

//___FILEHEADER___

import ComposableArchitecture

@Reducer
struct ___FILEBASENAMEASIDENTIFIER___ {
    @ObservableState
    struct State: Equatable {
    }
    
    enum Action: Equatable {
    }
    
    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            }
        }
    }
}

Contains of TemplateInfo.plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>SupportsSwiftPackage</key>
	<true/>
	<key>Kind</key>
	<string>Xcode.IDEFoundation.TextSubstitutionFileTemplateKind</string>
	<key>Description</key>
	<string>A TCA View Reducer</string>
	<key>Summary</key>
	<string>TCA View Reducer</string>
	<key>SortOrder</key>
	<string>1</string>
	<key>Image</key>
	<dict>
		<key>FileTypeIcon</key>
		<string>swift</string>
	</dict>
	<key>AllowedTypes</key>
	<array>
		<string>public.swift-source</string>
	</array>
	<key>Platforms</key>
	<array/>
	<key>DefaultCompletionName</key>
	<string>TCAView</string>
	<key>MainTemplateFile</key>
	<string>___FILEBASENAME___.swift</string>
	<key>Options</key>
	<array>
		<dict>
			<key>NotPersisted</key>
			<true/>
			<key>Type</key>
			<string>text</string>
			<key>Description</key>
			<string>The name of the reducer to create</string>
			<key>Name</key>
			<string>Name of Reducer:</string>
			<key>Required</key>
			<true/>
			<key>Identifier</key>
			<string>productName</string>
		</dict>
	</array>
</dict>
</plist>

All boilerplate is generated automatically, leaving only feature-specific logic to implement. After creating or updating templates, restarting Xcode is required.

Output: Using the Templates in Xcode

Once Xcode restarts:

Select New File
Choose the template
Enter a name
Xcode generates the file instantly

No copy-paste. No cleanup.

Benefits Observed in Practice

Faster Feature Creation - New screens are scaffolded in seconds.
Consistent Structure - Every file follows the same conventions.
Reduced Errors - No leftover identifiers or missed renames.
Better Focus - Time is spent on behavior, not setup.
Scales With the Project - Templates grow alongside the codebase.

Best Practices

Keep templates focused and minimal
Avoid embedding feature-specific logic
Revisit templates as conventions evolve
Treat templates as part of your tooling
Share templates with the team when possible

Conclusion

Xcode Templates are a small investment with long-term impact.

By moving repetitive setup into Xcode itself, you:

Improve development speed
Enforce consistency
Reduce mental overhead
Create a smoother daily workflow

For me, solving this problem while building Reckord made templates an essential part of my development environment—and once set up, they quietly pay dividends every day.

Thank you for reading. If you have any questions feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

InlineArray in Swift - Memory Efficient Fixed-Size Arrays

Tue, 06 Jan 2026 00:00:00 GMT

Swift 6.2 introduces InlineArray, a new low-level data structure designed to improve performance and memory efficiency in specific scenarios. While most developers will continue using Array in everyday code, InlineArray fills an important gap for performance-critical paths where allocation cost, cache locality, and predictable memory layout matter.

In this article, we’ll explore what InlineArray is, why Apple added it, how it works internally, and when you should (and should not) use it. We’ll also walk through practical examples to understand its behavior and limitations.

Why Was InlineArray Introduced?

Swift’s standard Array is powerful and flexible, but that flexibility comes with overhead:

Heap allocation for storage
Reference counting
Capacity growth logic
Indirection when accessing elements

In performance-sensitive systems—such as SwiftUI internals, compiler tooling, numeric code, or tight loops—this overhead can become measurable.

Apple introduced InlineArray to solve a very specific problem:

Store a small, fixed number of elements directly inline, without heap allocation.

This design enables:

Better cache locality
Fewer allocations
More predictable performance
Lower memory overhead

What Is InlineArray?

InlineArray is a fixed-size, value-type collection whose elements are stored inline within the value itself, rather than in heap-allocated storage.

Conceptually:

Array<T> - dynamically sized, heap-allocated
InlineArray<T, N> - fixed size N, stack-like inline storage
Once created, the size of an InlineArray cannot change.

Declaring an InlineArray

An InlineArray is defined with:

An element type
A compile-time constant size

let numbers: InlineArray<Int, 4> = [1, 2, 3, 4]

Key points:

The size (4) is part of the type
You must provide exactly that many elements
No resizing is allowed

Accessing Elements

Element access is similar to Array:

let values: InlineArray<Int, 3> = [10, 20, 30]

print(values[0]) // 10
print(values[1]) // 20

Indexing is bounds-checked, just like Array, ensuring safety.

Mutating an InlineArray

InlineArray is a value type, so mutation works as expected:

var scores: InlineArray<Int, 3> = [80, 90, 100]

scores[1] = 95

However, you cannot append or remove elements:

// ❌ Not allowed
scores.append(110)

The size is fixed at compile time.

InlineArray vs Array

Let’s compare the two side by side:

Feature	Array	InlineArray
Size	Dynamic	Fixed
Storage	Heap	Inline
Allocation	Yes	No
Resizable	Yes	No
Performance	General-purpose	Optimized for small sizes
API richness	Very high	Intentionally minimal

Memory Layout and Performance Benefits

The biggest advantage of InlineArray is memory layout predictability.

Because elements are stored inline:

The entire collection lives contiguously
No pointer chasing is required
CPU cache usage improves

This is especially beneficial in:

Math / geometry types
Small buffers
Internal framework data structures
Hot paths in performance-critical code

Example: Representing a 3D Vector

Instead of:

struct Vector3 {
    var values: [Float]
}

You can now write:

struct Vector3 {
    var values: InlineArray<Float, 3>
}

let position = Vector3(values: [1.0, 2.0, 3.0])

Benefits:

No heap allocation
Better cache locality
Clear semantic intent (exactly 3 values)

Iterating Over InlineArray

You can iterate using standard loops:

let colors: InlineArray<String, 3> = ["Red", "Green", "Blue"]

for color in colors {
    print(color)
}

This feels familiar while preserving the fixed-size guarantees.

Interoperability with Array

You can convert an InlineArray to a standard Array when needed:

let inline: InlineArray<Int, 4> = [1, 2, 3, 4]
let array = Array(inline)

This is useful when interacting with APIs that expect [T].

When Should You Use InlineArray?

InlineArray is not a replacement for Array. It shines in narrow, well-defined cases.

Good Use Cases

Small, fixed-size collections
Performance-critical code paths
Math and geometry types
Internal framework or library implementations

Avoid Using InlineArray When

Collection size is dynamic
API ergonomics matter more than performance
You rely heavily on Array functions like append(), filter(), or map()

API Design Philosophy

Apple intentionally kept InlineArray minimal:

No resizing
Limited mutation
Strong compile-time guarantees

This makes misuse harder and intent clearer—an important principle in Swift’s evolution.

Final Thoughts

InlineArray is a powerful addition to Swift, but it’s a specialized tool, not a general-purpose collection. For most application-level code, Array remains the best choice. However, when you need precise control over memory layout and performance, InlineArray provides a safe, expressive alternative without sacrificing Swift’s core principles.

If you’re building frameworks, performance-sensitive components, or low-level abstractions, InlineArray is well worth understanding and adopting thoughtfully.

Thank you for reading. If you have any questions feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

Zoom Navigation Transitions in SwiftUI

Mon, 29 Dec 2025 00:00:00 GMT

SwiftUI continues to evolve with powerful APIs that help developers build fluid, delightful user experiences with very little code. One such addition is zoom-style navigation transitions, introduced to make navigation feel more spatial, contextual, and intuitive.

Recently, I added a zoom navigation transition to the Settings view in my invocing app Reckord using the .navigationTransition and .matchedTransitionSource modifiers. In this article, we’ll explore these APIs in detail—what they are, why they matter, and how to use them correctly in real-world SwiftUI apps.

Zoom navigation transitions using .navigationTransition and .matchedTransitionSource are supported on iOS 18 and later.

Why Navigation Transitions Matter

Navigation is one of the most frequent interactions in any app. Poor transitions can feel abrupt and disorienting, while well-designed transitions:

Provide visual continuity
Help users understand where they came from
Make the UI feel polished and native
Reduce cognitive load

Traditional push/pop animations are functional—but they don’t always communicate context. Zoom transitions solve this by visually linking the source and destination views.

What Is a Zoom Navigation Transition?

A zoom navigation transition animates a view so it appears to expand into the next screen (or collapse back when navigating back). This is commonly seen in:

Settings screens
Profile details
Media viewers
Card-based layouts

SwiftUI enables this behavior by matching views across navigation boundaries using a shared identity.

Core Concepts You Need to Understand

Before writing any code, it’s important to understand the three key building blocks:

@Namespace
.matchedTransitionSource
.navigationTransition

We’ll explore each one in isolation first.

`.@Namespace`: Creating a Shared Animation Space

@Namespace creates a shared animation context that allows SwiftUI to relate views across different parts of the view hierarchy.

@Namespace private var settingsNamespace

Think of a namespace as a bridge that tells SwiftUI:

“These views are related—animate between them.”

Why Is It Required?

SwiftUI navigation views are recreated during transitions. Without a namespace, SwiftUI has no way to know that two views (in different screens) represent the same UI element.

Key Rules

A namespace must be declared once, typically at the parent level.
The same namespace must be used in both source and destination views.
Namespaces are lightweight and safe to reuse for related transitions.

`.matchedTransitionSource`: Creating a Shared Animation Space

.matchedTransitionSource marks the starting point of a navigation transition.

.matchedTransitionSource(
    id: "settings",
    in: settingsNamespace
)

This modifier tells SwiftUI:

“When navigating, animate from this view.”

Important Parameters

id: A unique identifier that matches the destination view.
in: The namespace that connects source and destination.

Where Should You Apply It?

Apply .matchedTransitionSource to:

Buttons
Cards
List rows
Any tappable UI that triggers navigation

In my app Reckord, this is applied to the Settings icon on the dashboard screen.

`.navigationTransition`: Defining the Destination Animation

.navigationTransition defines how the destination view appears when navigated to.

.navigationTransition(
    .zoom(sourceID: "settings", in: settingsNamespace)
)

This modifier belongs on the destination view, not the source.

How Zoom Works

The .zoom transition:

Animates size
Animates position
Maintains visual continuity

SwiftUI automatically calculates the animation path between the source and destination views.

Putting It All Together: Step-by-Step Implementation

Step 1: Declare the Namespace

@Namespace private var navigationNamespace

Place this in the parent view that manages navigation.

Step 2: Mark the Source View

NavigationLink {
    SettingsView(namespace: navigationNamespace)
} label: {
    Image(systemName: "gear")
        .matchedTransitionSource(
            id: "settings",
            in: navigationNamespace
        )
}

This tells SwiftUI where the zoom animation should start.

Step 3: Apply the Navigation Transition in Destination

struct SettingsView: View {
    let namespace: Namespace.ID

    var body: some View {
        SettingsContent()
            .navigationTransition(
                .zoom(sourceID: "settings", in: namespace)
            )
    }
}

Now SwiftUI knows:

Where the animation starts
Where it ends
How to animate between them

Real-World Example: Reckord Settings Screen

In Reckord, the Settings screen includes:

App preferences
Business details
Invoice configuration

Using a zoom transition:

Makes the Settings feel connected to the dashboard screen
Improves perceived performance
Matches Apple’s system apps behavior

Before adding zoom navigation for settings screen:

After adding zoom navigation for settings screen:

Accessibility Considerations

SwiftUI automatically respects:

Reduce Motion system settings
Dynamic Type scaling
VoiceOver focus changes

You don’t need extra code—but always:

Test transitions with Reduce Motion enabled
Ensure the app remains usable without animations

Final Thoughts

SwiftUI’s .navigationTransition and .matchedTransitionSource APIs make it easier than ever to create high-quality, native-feeling navigation animations—without complex gesture handling or custom animation code.

By understanding:

How @Namespace connects views
How source and destination roles differ
Where each modifier belongs

You can confidently add polished transitions to production apps like Reckord.

Thank you for reading. Stay safe and Happy holidays! 🎄

If you have any questions feel free to follow me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

SwiftUI Fonts Explained - System Styles, Modifiers and Accessibility

Wed, 24 Dec 2025 00:00:00 GMT

Fonts define the visual structure and readability of text in a SwiftUI interface. SwiftUI provides a typography system that adapts automatically to user settings, supports accessibility, and maintains consistency across Apple platforms.

This blog describes how to use system font styles, apply font modifiers, and integrate custom fonts in SwiftUI.

Why Fonts Matter in UI/UX

Fonts influence how users scan, read, and understand information in your app.

Good typography helps with:

Establishing visual hierarchy
Improving readability
Creating a consistent brand identity
Supporting accessibility features like Dynamic Type

SwiftUI encourages the use of semantic font styles instead of fixed font sizes. Semantic styles adapt to:

Dynamic Type
Accessibility settings
Platform-specific typography guidelines

Using System Font Styles

System font styles describe the purpose of text rather than its size. SwiftUI adjusts the actual font size automatically.

Example

VStack(spacing: 12) {
    Text("Large Title")
        .font(.largeTitle)

    Text("Title")
        .font(.title)

    Text("Title 2")
        .font(.title2) //available in iOS 14 and onwards

    Text("Title 3")
        .font(.title3) //available in iOS 14 and onwards

    Text("Headline")
        .font(.headline)

    Text("Sub Headline")
        .font(.subheadline)

    Text("Body")
        .font(.body) // default

    Text("Callout")
        .font(.callout)

    Text("Footnote")
        .font(.footnote)

    Text("Caption")
        .font(.caption)

    Text("Caption 2")
        .font(.caption2) //available in iOS 14 and onwards
}

Output

Use .largeTitle for main screen titles.
Use .title, .title2, .title3 for primary section titles.
Use .headline for emphasized labels.
Use .subheadline for secondary headings.
Use .body use for readable body text.
Use .callout for quote, important information, or a benefit statement.
Use .footnote for secondary text, such as disclaimers, or legal information
Use .caption for small, secondary text such as descriptions accompanying images, disclaimers, or subtitles.
Use .caption2 for alternate, smaller captions.

All system styles automatically support Dynamic Type it means these styles scale automatically when users change text size in Settings.

Applying Font Weight

Font weight determines the thickness of characters, ranging from very light to very heavy. Use it to establish hierarchy without changing font size.

Example

VStack(spacing: 12) {
    Text("Ultra Light")
        .fontWeight(.ultraLight)

    Text("Thin")
        .fontWeight(.thin)

    Text("Light")
        .fontWeight(.light)

    Text("Regular")
        .fontWeight(.regular)

    Text("Medium")
        .fontWeight(.medium)

    Text("Semi Bold")
        .fontWeight(.semibold)

    Text("Bold")
        .fontWeight(.bold)

    Text("Heavy")
        .fontWeight(.heavy)

    Text("Black")
        .fontWeight(.black)

}
.font(.title)

Output

Use .regular for body text
Use .medium or .semibold for labels
Use .bold or .heavy sparingly for emphasis

Combining Font Style and Weight (Best Practice)

Instead of using only weight or size, combine font style + weight.

Example

VStack(spacing: 12) {
    Text("Invoices")
        .font(.title)        // title font style
        .fontWeight(.heavy)  // heavy weight

    Text("Invoice Summary")
        .font(.headline)        // headline font style
        .fontWeight(.semibold)  // semibold weight
}

Output

Why this works

Keeps typography adaptive
Maintains Apple’s visual consistency
Works perfectly with accessibility

Font Design

SwiftUI allows you to change the design of system fonts.

Available Designs

.default
.rounded
.monospaced
.serif

Example

VStack(spacing: 12) {
    Text("Default Design")
        .font(.title)

    Text("Rounded Design")
        .font(.title)
        .fontDesign(.rounded)

    Text("Monospaced Design")
        .font(.title)
        .fontDesign(.monospaced)

    Text("Serif Design")
        .font(.title)
        .fontDesign(.serif)
}

Output

Use Cases

Monospaced - Numbers, invoices, codes
Rounded - Friendly UI
Serif - Reading-heavy apps

Italics, Underline and Strikethrough

You can further adjust the system font’s style by using modifiers such as .italic() to italicize the text, .underline() to add an underline, and .strikethrough() to draw a line through the text.

Example

VStack(spacing: 12) {
    Text("Note: This feature is experimental")
        .italic()

    Text("Privacy Policy")
        .underline()

    Text("$49.99")
        .strikethrough()
}

Output

Starting with iOS 16, you can customize the .underline and .strikethrough by changing the line’s pattern and color. Pattern has these options: .dash, .dashDot, .dashDotDot, .dot,.solid.

Example

VStack(spacing: 12) {
    Text("Custom Underline")
        .underline(pattern: .dash, color: .blue)

    Text("Custom Strikethrough")
        .strikethrough(pattern: .dot, color: .red)

    Text("Mixed Styles")
        .underline(pattern: .dashDot, color: .red)
        .strikethrough(pattern: .solid)
}
.font(.title)

Output

Use Cases

.italic() - Quoting text, scientific names, subtitles or captions, thoughts or narration in text content
.underline() - Links, key terms or definitions, items requiring user attention
.strikethrough() - Completed tasks in a to-do list, Discounted prices, Deprecated or unavailable items

Letter Spacing: Kerning

Kerning adjusts the spacing between specific pairs of letters to improve visual balance and readability.

Example letter pairs:

Characteristics

Applies to individual letter pairs
Often handled automatically by the font
Improves visual consistency, not uniform spacing

Example

VStack(spacing: 12) {
    Text("AV")

    Text("AV")
        .kerning(8)
}
.font(.title)

Output

Use Cases

Logos or branding text
Headlines where visual polish matters
Short strings of text

Letter Spacing: Tracking

Tracking adjusts the spacing uniformly across all letters in a word or block of text.

Characteristics

Applies even spacing to all characters
Often used for stylistic or readability purposes
Affects the entire text range equally

Example

VStack(spacing: 12) {
    Text("WELCOME")

    Text("WELCOME")
        .tracking(8)
}
.font(.title)

Output

Use Cases

All-caps text (improves readability)
Buttons and labels
UI headings

Line Spacing for Multiline Text

Line spacing is the distance from one line of text to the next.

Default spacing is determined by the font
Increasing spacing makes text easier to read
Decreasing spacing makes text more compact

Example

VStack(spacing: 24) {
    Text("""
    SwiftUI automatically wraps text
    onto multiple lines when needed.
    Line spacing controls the vertical
    distance between those lines.
    """)

    Text("""
    SwiftUI automatically wraps text
    onto multiple lines when needed.
    Line spacing controls the vertical
    distance between those lines.
    """)
    .lineSpacing(8)
}

The value is measured in points and is added to the font’s default line height.

Output

Use Cases

Body Text (Articles, Descriptions)
Headlines with Subtext
Compact UI Text

Baseline Offset

Baseline offset controls how text is shifted vertically relative to its baseline. The baseline is the invisible line on which most letters sit (like a, e, o), while letters such as g or y extend below it.

The .baselineOffset(_:) modifier lets you move text up or down without changing its font size or layout space.

What Does Baseline Offset Do?

Positive values move text up
Negative values move text down
Measured in points
Affects vertical alignment, not spacing

Example

VStack(spacing: 48) {
    HStack(spacing: .zero) {
        Text("10")

        Text("2")
            .font(.caption)
            .baselineOffset(8)
    }

    HStack(spacing: .zero) {
        Text("H")

        Text("2")
            .font(.caption)
            .baselineOffset(-6)

        Text("O")
    }
}

Output

Supporting Dynamic Type (Accessibility)

Dynamic Type allows users to choose larger or smaller text sizes in iOS Accessibility settings. Supporting it properly ensures your app remains readable, usable, and inclusive for everyone.

System fonts is designed to work well with Dynamic Type by default—but there are important best practices to follow.

Use System Text Styles (Best Practice)

System text styles automatically scale with Dynamic Type.

Example

VStack(spacing: 48) {
    Text("Body text")
        .font(.body)

    Text("Headline")
        .font(.headline)

    Text("Title")
        .font(.title)
}

These fonts scale automatically
Follow Apple’s typography guidelines

Output

Avoid Fixed Font Sizes (When Possible)

Use system text styles whenever possible. Avoid fixed font sizes.

Example(Not Dynamic Type–friendly)

VStack(spacing: 24) {
    Text("Fixed size")
        .font(.system(size: 16))

    Text("Fixed size")
        .font(.system(size: 32))

    Text("Fixed size")
        .font(.system(size: 48))
}

Output

Example(Dynamic Type–friendly)

VStack(spacing: 24) {
    Text("Scalable title")
        .font(.title)

    Text("Scalable headline")
        .font(.headline)

    Text("Scalable body text")
        .font(.body)
}

Output

Conclusion

SwiftUI provides a typography system that is both powerful and opinionated. By using semantic system font styles, applying font modifiers intentionally, and respecting Dynamic Type and accessibility settings, you can create interfaces that remain readable, consistent, and adaptable across devices.

Custom fonts can be layered on top when branding requires it, but system fonts should remain the foundation for most user interfaces. Understanding how each font modifier affects text allows you to make precise typographic decisions while preserving accessibility and platform conventions. When used correctly, SwiftUI fonts help your UI communicate hierarchy, clarity, and intent without additional complexity.

If you have any suggestions, feel free to connect with me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

How to Create a Signature Canvas in iOS Using SwiftUI and PencilKit?

Mon, 15 Dec 2025 00:00:00 GMT

Creating a smooth and natural signature experience is a small feature that can add huge perceived value to an app—especially in business, productivity, and document-related products.

While building my invocing app Reckord, I recently added a Signature feature using Apple PencilKit. This post explains why digital signatures matter, introduces Apple PencilKit, and walks through how to build a custom signature canvas in SwiftUI step by step.

PencilKit

PencilKit is Apple’s native framework for handling handwriting, drawing, and annotations on iOS and iPadOS.

Although it’s often associated with sketching or note-taking apps, PencilKit is an excellent choice for building signature capture features.

Key benefits of using PencilKit:

Smooth, low-latency drawing experience
Native support for Apple Pencil and finger input
Pressure and tilt sensitivity (Apple Pencil)
High performance and battery efficiency
Fully on-device and privacy-friendly
Actively maintained and optimized by Apple

At the core of is PKCanvasView, a UIKit view that provides a ready-to-use drawing surface for capturing handwritten input.

What Does PencilKit Provide?

PencilKit offers a small but powerful set of APIs:

PKCanvasView– A drawing canvas for user input
PKDrawing – A data model representing the drawing
PKToolPicker – Pencil, pen, eraser, and tool selection
Built-in support for exporting drawings as UIIMage, PDF, or Data

These components make it easy to build features like:

Signature pads
Handwritten notes
Document annotations
Markup tools

Using PencilKit in SwiftUI

PencilKit is built on UIKit, while many modern apps—including mine—are written in SwiftUI.

To use PencilKit inside SwiftUI, we rely on: UIViewRepresentable

UIViewRepresentable allows us to wrap a UIKit view and embed it seamlessly inside a SwiftUI layout.

Using this approach, we can:

Create and configure a PKCanvasView
Manage its lifecycle
Sync the drawing state with SwiftUI
Keep the rest of the app fully SwiftUI-based

Step 1: Create a Signature Canvas Wrapper

The first step is to create a custom SwiftUI view that wraps PKCanvasView using UIViewRepresentable.

This wrapper is responsible for:

Creating the canvas view
Configuring drawing behavior
Exposing the drawing data back to SwiftUI

Typically, this includes:

Implementing makeUIView() to initialize the canvas
Implementing updateUIView() to keep state in sync
Using a @Binding to store the PKDrawing

import SwiftUI
import PencilKit

struct SignatureCanvasView: UIViewRepresentable {
    @SwiftUI.Environment(\.theme) var theme
    @Environment(\.colorScheme) var colorScheme
    @Binding var exportedImage: UIImage?
    @Binding var exportRequested: Bool
    @Binding var clearRequested: Bool
    @Binding var isCanvasEmpty: Bool

    func makeUIView(context: Context) -> PKCanvasView {
        let canvas = PKCanvasView(frame: .zero)
        canvas.overrideUserInterfaceStyle = .light
        canvas.drawingPolicy = .anyInput
        canvas.alwaysBounceVertical = false
        canvas.backgroundColor = .white
        canvas.isOpaque = true
        canvas.drawingPolicy = .anyInput
        canvas.tool = PKInkingTool(.pen, color: .black)

        context.coordinator.canvasView = canvas
        context.coordinator.canvasView?.delegate = context.coordinator
        return canvas
    }

    func updateUIView(_ uiView: PKCanvasView, context: Context) {
        uiView.overrideUserInterfaceStyle = .light
        uiView.tool = PKInkingTool(.pen, color: .black)
        // handle export request
        if exportRequested {
            // Export the whole canvas bounds (transparent background preserved)
            let lightTraits = UITraitCollection(userInterfaceStyle: .light)
            let scale = UIScreen.main.scale
            lightTraits.performAsCurrent {
                let bounds = uiView.drawing.bounds.insetBy(dx: -10, dy: -10) // small padding
                let drawingImage = uiView.drawing.image(from: bounds, scale: scale)
                DispatchQueue.main.async {
                    exportedImage = drawingImage
                    // reset flag
                    self.exportRequested = false
                }
            }
        }

        // handle clear request
        if clearRequested {
            uiView.drawing = PKDrawing() // reset drawing
            DispatchQueue.main.async {
                self.clearRequested = false
            }
        }
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(isCanvasEmpty: $isCanvasEmpty)
    }

    class Coordinator: NSObject, PKCanvasViewDelegate {
        weak var canvasView: PKCanvasView?
        @Binding var isCanvasEmpty: Bool

        init(canvasView: PKCanvasView? = nil, isCanvasEmpty: Binding<Bool>) {
            self.canvasView = canvasView
            self._isCanvasEmpty = isCanvasEmpty
        }

        func canvasViewDrawingDidChange(_ canvasView: PKCanvasView) {
            isCanvasEmpty = canvasView.drawing.strokes.isEmpty
        }
    }

}

Step 2: Configure the PencilKit Canvas

Inside the UIKit view setup, you configure how the signature behaves.

Common configuration includes:

Allowing both finger and Apple Pencil input
Setting a clear or white background
Enabling or disabling scrolling
Choosing the default drawing tool
Optionally displaying the tool picker

let canvas = PKCanvasView(frame: .zero)
canvas.overrideUserInterfaceStyle = .light // light, dark
canvas.drawingPolicy = .anyInput // default, anyInput, pencilOnly
canvas.alwaysBounceVertical = false
canvas.backgroundColor = .white
canvas.isOpaque = true
canvas.tool = PKInkingTool(.pen, color: .black)

These settings ensure the signature feels natural and distraction-free.

Step 3: Integrate the Signature Canvas into SwiftUI

Once the wrapper is ready, you can use it like any other SwiftUI view.

At this stage, you can:

Embed it inside a VStack or Form
Control its height and layout
Add actions like Clear, Save, or Done
React to drawing updates using bindings

This makes the signature feature feel fully native within your SwiftUI app.

VStack {
    Spacer()

    ZStack {
        // Visual border to show area
        RoundedRectangle(cornerRadius: theme.spacing.sm)
            .stroke(style: StrokeStyle(lineWidth: 1, dash: [6])) // dashed border
            .foregroundColor(theme.colors.tint)

        // The PencilKit canvas
        SignatureCanvasView(
            exportedImage: $exportedImage,
            exportRequested: $exportRequested,
            clearRequested: $clearRequested,
            isCanvasEmpty: $isCanvasEmpty
        )
        .clipShape(RoundedRectangle(cornerRadius: theme.spacing.sm))
        .padding(theme.spacing.xs)
        .onChange(of: store.exportedImage) { oldValue, newValue in
            if let image = newValue, let imageData = image.pngData() {
                //USE imageData TO DISPLAY IMAGE ON VIEW
            }
        }
    }
    .frame(height: 220)

    Spacer()
}

Output:

Step 4: Extract and Use the Signature Output

After the user finishes signing, the captured PKDrawing can be:

Converted into a UIImage
Exported as a PNG or PDF
Stored locally or uploaded
Attached to invoices, documents, or records

This step turns a visual signature into something usable in real-world workflows.

.onChange(of: store.exportedImage) { oldValue, newValue in
    if let image = newValue, let imageData = image.pngData() {
        //USE imageData TO DISPLAY IMAGE ON VIEW
    }
}

Final Result

By combining PencilKit with SwiftUI, you get:

A smooth, responsive signature experience
Support for Apple Pencil and finger input
Clean separation between UI and data
A future-proof, Apple-maintained solution

This is the exact approach I used to implement the signature feature in Reckord, and it works great. Here is output:

Closing Thoughts

Signature capture might seem like a small feature, but when implemented well, it adds significant trust and professionalism to an app.

With SwiftUI + PencilKit, you can deliver a high-quality signature experience using native tools with minimal complexity.

Thank you for reading! 😀 Stay safe and take care!

If you have any suggestions or a better approach, feel free to connect with me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

SwiftUI App Localization in Xcode — Easy, Scalable

Wed, 13 Aug 2025 00:00:00 GMT

Recently, I updated my invocing app Reckord to support 24 different languages as part of my ASO strategy. Localization not only makes your app more accessible to a global audience but also increases your chances of ranking in non-English App Stores.

Here’s exactly how you can do it — in 7 simple steps.

1. Create a String Catalog

First, Create a String Catalog in my Xcode project:

In the Resources folder, right-click → New File → search for “String Catalog” → name it Localizable.

This will serve as the central place for all your translated strings.

2. Convert Static Strings into Localised Strings

Next, Replace all hardcoded static strings in your SwiftUI views with String(localized:) so they are ready for translation.

Here’s an example:

String (
    localized: "create_organisation_view.create.title",
    defaultValue: "New Organisation",
    table: "Localizable",
    comment: "Title for create organisation screen"
)

localized → The key for your string in the String Catalog.

defaultValue → The text for your base language (English in my case).

table → The name of your String Catalog file.

comment → Extra context for translators (and AI tools).

💡 Pro Tip: Create a constants file to make localization scalable and maintainable. Here’s how I structured mine:

public struct Constants {
    public struct CreateOrganisationView {
        public static let createOrganisationTitle: String = String(
            localized: "create_organisation_view.create.title",
            defaultValue: "New Organisation",
            table: "Localizable",
            comment: "Title for create organisation screen"
        )

        public static let editOrganisationTitle: String = String(
            localized: "create_organisation_view.edit.title",
            defaultValue: "Edit Organisation",
            table: "Localizable",
            comment: "Title for edit organisation screen"
        )
        
        public static let organisationNamePlaceholder: String = String(
            localized: "create_organisation_view.organisation.name.placeholder",
            defaultValue: "What is organisation's name?",
            table: "Localizable",
            comment: "Placeholder for organisation name filed in create/edit organisation screen"
        )
    }
}

3. Build the Project to Populate the String Catalog

Once you replace all static strings, build the project(Product → Build).

Now, when you open the Localizable String Catalog, you’ll see all your keys under the English column.

4. Add New Languages to Your Project

To prepare for translations, go to: Project Settings → Info Tab → Localizations → +

Add all the languages you want your app to support.

5. Export Localizations

Go to Product → Export Localizations… in Xcode.

You can open this .xcloc file in Xcode to review it. It will contain all your string keys and their English values.

6. Translate Your .xcloc File

Instead of translating manually, You can use AI-powered localization tools(strings.dev in my case).

Some great tools include: localizebot.com, strings.dev

Steps:

Upload your en.xcloc file.
Select target languages.
Download the translated .xcloc files.

7. Import Translations Back into Xcode

Go to Product → Import Localizations… in Xcode.

Select the .xcloc file you downloaded from the translation tool.
Xcode will merge these translations into your String Catalog.

At this point, your Localizable catalog will show translations for each added language.

Final Result

Your app now supports 2 different languages(French, Japanese) — and You can easily add more in the future using this same process.

This way, you can scale your app and keep supporting new languages without a huge manual effort.

Thank you for reading! 😀 Stay safe and take care!

If you have any suggestions or a better approach, feel free to connect with me on X and send me a DM. If you enjoyed this article and would like to support me, Buy me a coffee.

How to add SegmentedControl in List that scrolls with a List in SwiftUI?

Mon, 13 Jan 2025 00:00:00 GMT

When building apps with SwiftUI, you might need to add a SegmentedControl on top of a List that scrolls along with the list.

Usually, you’d think of placing the List inside a VStack and adding a Picker with the .segmented style above it, like this:

VStack(spacing: .zero) {
    Picker("Conact type", selection: $genre) {
        ForEach(Genre.allCases, id: \.self) { genre in
            Text(genre.string)
                .textCase(nil)
        }
    }
    .pickerStyle(.segmented)
    .padding(.horizontal)
    .background(Color(uiColor: .systemGroupedBackground))

    List {
        Section {
            ForEach(songs, id: \.id) { song in
                VStack(alignment: .leading) {
                    Text(song.title)
                        .foregroundStyle(.primary)
                        .bold()

                    Text(song.artist)
                        .foregroundStyle(.secondary)
                }
            }
        }
    }
}

However, this approach doesn’t give the desired result:

The right way: Using a SegmentedControl in the List header

Instead of adding the Picker in a VStack, you can include it in the List's section header, like this:

List {
    Section {
        ForEach(songs, id: \.id) { song in
            VStack(alignment: .leading) {
                Text(song.title)
                    .foregroundStyle(.primary)
                    .bold()

                Text(song.artist)
                    .foregroundStyle(.secondary)
            }
        }
    } header: {        Picker("Conact type", selection: $genre) {            ForEach(Genre.allCases, id: \.self) { genre in                Text(genre.string)                    .textCase(nil)            }        }        .pickerStyle(.segmented)    }}

This gives a much better result:

Removing extra space

You might notice unwanted spacing around the SegmentedControl. To fix this, apply the .listRowInsets(EdgeInsets()) modifier to the Picker:

List {
    Section {
        ForEach(songs, id: \.id) { song in
            VStack(alignment: .leading) {
                Text(song.title)
                    .foregroundStyle(.primary)
                    .bold()

                Text(song.artist)
                    .foregroundStyle(.secondary)
            }
        }
    } header: {
        Picker("Conact type", selection: $genre) {
            ForEach(Genre.allCases, id: \.self) { genre in
                Text(genre.string)
                    .textCase(nil)
            }
        }
        .pickerStyle(.segmented)
        .listRowInsets(EdgeInsets())        .padding(.vertical)
    }
}

Here’s the final output: a SegmentedControl that scrolls seamlessly with the list.

Thanks for reading! If you have any questions or suggestions, feel free to send me DM on X. If you enjoyed this article and would like to support me, Buy me a coffee.

Sign in with Apple - SwiftUI, MVVM

Wed, 17 Mar 2021 00:00:00 GMT

Sign in with Apple is a new way to sign in to your app just like facebook and google with all apple privacy and security.

Sign in with Apple is the fast, easy, and more private way to sign in to third-party apps and websites using the Apple ID that you already have. Sign in with Apple is built from the ground up to secure your privacy and personal data. At your first sign-in, apps and website can ask only for your name and email address to set up an account for you.

You can also hide your personal email address from the app or website. if you choose to hide your personal email address then a unique, random email address is generated so your personal email address isn't shared with the app or website developer during the account setup and sign in process. This address is unique to you and the developer and follows this format: <unique-alphanumeric-string>@privaterelay.appleid.com

Let's implement Sign in with Apple using SwiftUI by following MVVM architecture.

On the signing & capability pane, set the bundle id to unique identifier.

Add your apple id account and assign the target to the team so Xcode can enable sign in with Apple in your provisioning profile. You can also add this capability on the apple developer portal manually.

Choose a run destination from the scheme pop-up menu that you're signed into with and apple id and that uses two factor authentication(TouchID or FaceID)
If necessary, click register device in signing & capabilities to create the provisioning profile.
In the toolbar, click run or choose Product > Run

Here is the project structure,

Add a Sign in with Apple button

We can add the Sign in with Apple button in our view by importing AuthenticationServices. Using this button we can create authorization requests with the scope and also handle the results.

SignInWithAppleButton(.signIn,
    onRequest: { request in
        request.requestedScopes = [.fullName, .email]
    },
    onCompletion: { result in
        authenticationViewModel.didFinishAuthentication(result: result)
    }
)

In the above code snippet, Sign in with Apple button has three parameter as follows,

label: This is the button title that displays title like Continue, Sign In or Sign up
onRequest: Setup request and scope
onCompletion: Handle the authorization result

Handle authorization result

On completion of the request, we will get the authorization result whether the user successfully signed in or not.

func didFinishAuthentication(result: Result<ASAuthorization, Error>) {
    switch result {
    case .success(let authorization):
        guard let credential = authorization.credential as? ASAuthorizationAppleIDCredential else {
            shouldShowAlert = true
            alertTitle = "Error"
            alertMessage = "Something went wrong. Please try again later."
            return
        }
        
        saveUserData(name: credential.fullName?.givenName, email: credential.email, userId: credential.user)
    case .failure(let error):
        shouldShowAlert = true
        alertTitle = "Error"
        alertMessage = error.localizedDescription
    }
}

If the user gets successfully signs in then store the user information in UserDefautls or Keychain and if it fails then show an alert to the user.

Revoke the permission and handle the changes

We can revoke the permission for the app from Settings > Apple Id > Password & Security > Apps using your Apple ID

When we press "Stop Using Apple Id" we also need to handle that change in our app and we can handle it using ASAuthorizationAppleIDProvider.credentialRevokedNotification notification and we need to register for it in our ViewModel like this,

init() {
    NotificationCenter.default.addObserver(self, selector: #selector(getAuthorizationState), name: ASAuthorizationAppleIDProvider.credentialRevokedNotification, object: nil)
}

@objc func getAuthorizationState() {
    let provider = ASAuthorizationAppleIDProvider()
    if let userId = UserDefaults.standard.value(forKey: "userId") as? String {
        provider.getCredentialState(forUserID: userId) { [self] (state, error) in
            switch state {
            case .authorized:
                // Credential are still valid
                break
            case .revoked:
                //Credential is revoked. It is similar to Logout. Show login screen.
                self.deleteUserData()
                break
            case .notFound:
                //Credential was not found. Show login screen.
                self.deleteUserData()
                break
            case .transferred:
                //The app is transfeered from one development team to another development team. You need to login again so show login screen.
                self.deleteUserData()
                break
            default:
                break
            }
        }
    }
}

Code

SignInWithAppleDemoApp.swift

import SwiftUI

@main
struct SignInWithAppleDemoApp: App {
    @ObservedObject var authenticationViewModel: AuthenticationViewModel = AuthenticationViewModel()
    @AppStorage("email") var email: String = ""
    
    init() {
        authenticationViewModel.getAuthorizationState()
    }
    
    var body: some Scene {
        WindowGroup {
            if email == "" {
                AuthenticationView(authenticationViewModel: authenticationViewModel)
            } else {
                HomeView()
            }
        }
    }
}

HomeView.swift

import SwiftUI

struct HomeView: View {
    @AppStorage("name") var name: String = ""
    
    var body: some View {
        VStack {
            Text("Hello \(name), Have a good day!")
                .font(.title)
            
            Spacer()
                .frame(height: 100)
        }
    }
}

AuthenticationView.swift

import SwiftUI
import AuthenticationServices

struct AuthenticationView: View {
    
    @ObservedObject var authenticationViewModel: AuthenticationViewModel
    
    var body: some View {
        VStack {
            SignInWithAppleButton(.signIn,
                onRequest: { request in
                    request.requestedScopes = [.fullName, .email]
                },
                onCompletion: { result in
                    authenticationViewModel.didFinishAuthentication(result: result)
                }
            )
            .scaledToFit()
            .padding()
        }
        .alert(isPresented: $authenticationViewModel.shouldShowAlert, content: {
            Alert(title: Text(authenticationViewModel.alertTitle), message: Text(authenticationViewModel.alertMessage), dismissButton: .default(Text("OK")))
        })
    }
}

AuthenticationViewModel.swift

import Foundation
import AuthenticationServices

class AuthenticationViewModel:  ObservableObject {
    @Published var shouldShowAlert: Bool = false
    @Published var alertTitle: String = ""
    @Published var alertMessage: String = ""
    
    //get notified when autherization state gets change
    init() {
        NotificationCenter.default.addObserver(self, selector: #selector(getAuthorizationState), name: ASAuthorizationAppleIDProvider.credentialRevokedNotification, object: nil)
    }
    
    //handle the authorization result that returned from the authorization request in Sign In with Apple button
    func didFinishAuthentication(result: Result<ASAuthorization, Error>) {
        switch result {
        case .success(let authorization):
            guard let credential = authorization.credential as? ASAuthorizationAppleIDCredential else {
                shouldShowAlert = true
                alertTitle = "Error"
                alertMessage = "Something went wrong. Please try again later."
                return
            }
            
            saveUserData(name: credential.fullName?.givenName, email: credential.email, userId: credential.user)
        case .failure(let error):
            shouldShowAlert = true
            alertTitle = "Error"
            alertMessage = error.localizedDescription
        }
    }
    
    //store the user information in UserDefaults
    func saveUserData(name: String?, email: String?, userId: String?){
        UserDefaults.standard.setValue(name, forKey: "name")
        UserDefaults.standard.setValue(email, forKey: "email")
        UserDefaults.standard.setValue(userId, forKey: "userId")
    }
    
    //store nil for all user information in USerDefaults
    func deleteUserData(){
        UserDefaults.standard.setValue(nil, forKey: "name")
        UserDefaults.standard.setValue(nil, forKey: "email")
        UserDefaults.standard.setValue(nil, forKey: "userId")
    }
    
    //this method gets call when the credential revoked notification has been arised in NotificationCenter
    @objc func getAuthorizationState() {
        let provider = ASAuthorizationAppleIDProvider()
        if let userId = UserDefaults.standard.value(forKey: "userId") as? String {
            provider.getCredentialState(forUserID: userId) { [self] (state, error) in
                switch state {
                case .authorized:
                    // Credential are still valid
                    break
                case .revoked:
                    //Credential is revoked. It is similar to Logout. Show login screen.
                    self.deleteUserData()
                    break
                case .notFound:
                    //Credential was not found. Show login screen.
                    self.deleteUserData()
                    break
                case .transferred:
                    //The app is transfeered from one development team to another development team. You need to login again so show login screen.
                    self.deleteUserData()
                    break
                default:
                    break
                }
            }
        }
    }
}

Resources

https://developer.apple.com/sign-in-with-apple/

https://developer.apple.com/documentation/authenticationservices/implementing_user_authentication_with_sign_in_with_apple

https://support.apple.com/en-in/HT210318

Conclusion

Sign in with Apple is more secure and easy to implement in any SwiftUI app. I hope that you like this article and also understood how to implement it by following MVVM architecture. If you have any questions consider following me on X and DM me your questions. If you enjoyed this article and would like to support me, Buy me a coffee.

Thank you for reading! 😀 Stay safe and take care!

Understanding gradients using SwiftUI

Tue, 12 May 2020 00:00:00 GMT

What is the gradient?

Apple says it is an array of color stops each having parametric location value. In simple word, it is a color ramp or color progression that blends one into another and create a beautiful color effect.

Gradient in SwiftUI

SwiftUI allow us to apply gradient color to its View using three different ways,

Linear Gradient
Radial Gradient
Angular Gradient

Before we discuss each into detail let's understand some SwiftUI struct that we are going to use in the code examples,

Gradient

It represents an array of color stops and each color having a parametric location value. Gradient will be initialized with an array or Color or an array of Color.Stop. Note that Color.Stop represents one color stop in gradient.

Gradient(colors: [Color.red, Color.white])
Gradient(stops : [Color.Stop(color: Color.red, location: 0), Color.Stop(color: Color.white, location: 0)])

UnitPoint

UnitPoint is represented by X and Y position in bounding rectangle shape. It ranges from 0 to 1. SwiftUI gives us predefine UnitPoints such as:

UnitPoint.zero // UnitPoint(x: 0, y: 0)
UnitPoint.center // UnitPoint(x: 0.5, y: 0.5)
UnitPoint.leading // UnitPoint(x: 0, y: 0.5)
UnitPoint.trailing // UnitPoint(x: 1, y: 0.5)
UnitPoint.top // UnitPoint(x: 0.5, y: 0)
UnitPoint.bottom // UnitPoint(x: 0.5, y: 1)
UnitPoint.topLeading // UnitPoint(x: 0, y: 0)
UnitPoint.topTrailing // UnitPoint(x: 1, y: 0)
UnitPoint.bottomLeading // UnitPoint(x: 0, y: 1)
UnitPoint.bottomTrailing // UnitPoint(x: 1, y: 1)

Consider this image for better understanding.

It was a basic understanding of Gradient and UnitPoint. Now let's discuss the main three gradients that SwiftUI provide us,

1. Linear Gradient

A linear gradient is the most common and popular method to add gradient color in your View.

The gradient applies the color function along an axis, as defined by its start and end points. The gradient maps the unit-space points into the bounding rectangle of each shape filled with the gradient.

In simple words, a linear gradient is a progressive transition between two or more colors along with a straight line.

struct LinearGradientView: View {
    let gradient = Gradient(colors: [
        Color.black,
        Color.red
    ])
    
    var body: some View {
        VStack {
            HStack {
                
                Spacer()
                
                VStack(alignment: .center) {
                    LinearGradient(gradient: gradient, startPoint: .bottomLeading, endPoint: .topTrailing)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".bottomLeading\nto\n.topTrailing")
                        .multilineTextAlignment(.center)
                }
                
                Spacer()
                
                VStack {
                    LinearGradient(gradient: gradient, startPoint: .bottomTrailing, endPoint: .topLeading)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".bottomTrailing\nto\n.topLeading")
                        .multilineTextAlignment(.center)
                }
                
                Spacer()
            }
            
            HStack {
                Spacer()
                
                VStack(alignment: .center) {
                    LinearGradient(gradient: gradient, startPoint: .leading, endPoint: .trailing)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".leading\nto\n.trailing")
                        .multilineTextAlignment(.center)
                }
                
                Spacer()
                
                VStack {
                    LinearGradient(gradient: gradient, startPoint: .trailing, endPoint: .leading)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".trailing\nto\n.leading")
                        .multilineTextAlignment(.center)
                }
                Spacer()
            }
            
            HStack {
                Spacer()
                
                VStack(alignment: .center) {
                    LinearGradient(gradient: gradient, startPoint: .top, endPoint: .bottom)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".top\nto\n.bottom")
                        .multilineTextAlignment(.center)
                }
                
                Spacer()
                
                VStack {
                    LinearGradient(gradient: gradient, startPoint: .bottom, endPoint: .top)
                    .frame(width: 100, height: 100)
                    .cornerRadius(20)
                    
                    Text(".bottom\nto\n.top")
                        .multilineTextAlignment(.center)
                }
                Spacer()
            }
            Spacer()
        }
    }
}

The output will look like this,

You can use a different combination of UnitPoint to get your exact matched gradient color.

2. Radial Gradient

A radial gradient is a progressive transition between two or more colors that radiate from the center point.

The gradient applies the color function as the distance from a center point, scaled to fit within the defined start and end radii. The gradient maps the unit-space center point into the bounding rectangle of each shape filled with the gradient.

Here is the example,

struct RadialGradientView: View {
    let gradient = Gradient(colors: [
        Color.black,
        Color.red
    ])
    
    var body: some View {
        VStack {
            RadialGradient(gradient: gradient, center: .center, startRadius: 0.0, endRadius: 100.0)
                .frame(width: 200, height: 200)
                .cornerRadius(20)
            
            Text("width: 200, height: 200\ncornerRadius: 20\nstartRadius: 0.0\nendRadius: 100.0")
                .multilineTextAlignment(.center)
        }
    }
}

The output will look like this,

3. Angular Gradient

An angular gradient is also known as a “conic” gradient. This gradient applies the color function as the angle changes, relative to a center point and defined start and end angles. If endAngle - startAngle > 2π, the gradient only draws the last complete turn. If endAngle - startAngle < 2π, the gradient fills the missing area with the colors defined by gradient locations one and zero, transitioning between the two halfway across the missing area. The gradient maps the unit-space center point into the bounding rectangle of each shape filled with the gradient.

In simple words, angular gradient sweeps counterclockwise around the starting point. The line between start and endpoint defines the angle.

Here is the example,

struct AngularGradientView: View {
    let gradient = Gradient(colors: [
        Color.black,
        Color.red
    ])
    
    var body: some View {
        VStack {
            
            //you can use either of following initialiser to create angular gradient
            
            //1 with center only initialise
            
            //AngularGradient(gradient: gradient, center: .center)
            //    .frame(width: 200, height: 200)
            //    .cornerRadius(20)
            
            //2 with center and angle initialise
            
            //AngularGradient(gradient: gradient, center: .center, angle: .degrees(0))
            //  .frame(width: 200, height: 200)
            //  .cornerRadius(20)
            
            //3 with center, start angle and end angle initialise

            AngularGradient(gradient: gradient, center: .center, startAngle: .degrees(0), endAngle: .degrees(360))
                .frame(width: 200, height: 200)
                .cornerRadius(20)
            
            Text("width: 200, height: 200\ncornerRadius: 20\nstartAngle: 0.0\nendAngle: 360.0")
            .multilineTextAlignment(.center)
            
        }
    }
}

The output will look like this,

Conclusion

SwiftUI provides powerful gradients that you can use it to fill your views with required configurations. If you have any questions consider following me on X and DM me your questions. If you enjoyed this article and would like to support me, Buy me a coffee.

Thank you for reading! 😀 Stay safe and take care!

Property wrappers in SwiftUI

Mon, 03 Feb 2020 00:00:00 GMT

What is Property Wrapper?

Property wrapper is a simple generic class/struct that has some logic that gets trigger whenever the value of property gets modified. It was introduced during WWDC 2019 and comes with Swift 5.

SwiftUI provides us many property wrappers like @State, @Binding, @ObservedObject, @EnvironmentObject, @Environment. Let's discuss each of them and understand when to use and how to use it.

@State

@State is a property wrapper that allows us to modify value inside a struct. When the state value changes, the view invalidate its appearance and rebuild the view. Because of the local nature of @State property, Apple recommends us to mark them as private. Here is the example,

struct ContentView: View {
    @State private var showAlert: Bool = false
    
    var body: some View {
        Button(action: {
            self.showAlert = true
        }) {
            Text("Show me alert")
        }
        .alert(isPresented: $showAlert) {
            Alert(title: Text("Hey!"), message: Text("Have a good day :)"), dismissButton: .default(Text("OK")))
        }
    }
}

In the above example, we have a simple screen with the button "Show me alert" in the center. When you hit the button it will change the state property showAlert and SwiftUI recreates view and display the alert.

@Binding

@Binding property wrapper allows you to pass the data between two or more views without ownership. It provides reference like access for a value type. @Binding property has its value passed in from parent view as binding. It does not have ownership since it copies a value from parent @State value. Here is the example,

struct ContentView: View {
    @State private var isPlaying: Bool = false
    
    var body: some View {
        VStack {
            Text("Test audio!")
            PlayButtonView(isPlaying: $isPlaying)
        }
    }
}

struct PlayButtonView: View {
    @Binding var isPlaying: Bool
    var body: some View {
        Button(action: {
            self.isPlaying.toggle()
        }) {
            Image(systemName: isPlaying ? "pause.circle" : "play.circle")
        }
    }
}

In the above example, we have a simple view with a label and play/pause button in the center. We have state property isPlaying and passing that reference to PlayButtonView using $. As soon as PlayButtonView changes the value of isPlaying property, SwiftUI recreates ContentView and PlayButtonView as its child view.

@ObservedObject

@ObservedObject is similar to @State property wrapper but it is for external type and track the changes using @Published property wrapper. The key difference between @State and @ObservedObject is that @ObservedObject shares the object between two or more individual views. Let's look at the example,

class Cart: ObservableObject {
    @Published var cartItems = [String]()
}

struct ContentView: View {
    @ObservedObject var cart = Cart()
    
    var body: some View {
        VStack {
            Text("Number of items in cart is: \(cart.cartItems.count)")
        }
    }
}

In the above example, we have Cart class that we are using in multiple views of our application. Whenever any changes made to cartItems, It will automatically notify all the views that use the Cart. Any type you mark as @ObservedObject should conform to the protocol ObservableObject and it should be a class type.

@EnvironmentObject

@EnvironmentObject is very similar to @ObservedObject but the main difference is that @EnvironmentObject allows us to create a property that shared across the entire app without created by view or passed in from another view. In simple words, we can add a property in the Environment of the view hierarchy and all the child view in the hierarchy can access that property. Here is the example,

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let windowScene = scene as? UIWindowScene {
            let window = UIWindow(windowScene: windowScene)
            let cart = Cart()
            let contentView = ContentView().environmentObject(cart)
            window.rootViewController = UIHostingController(rootView: contentView)
            self.window = window
            window.makeKeyAndVisible()
        }
    }
}

struct ContentView: View {
    @EnvironmentObject var cart: Cart
    
    var body: some View {
        VStack {
            Text("Number of items in cart is: \(cart.cartItems.count)")
        }
    }
}

Above example is similar to example of @ObservedObject but the difference is we don't need to pass the default value by uisng @EnvironmentObject. It means it will be provided by SwiftUI environment. You can see in the example that we created the cart object in SceneDelegate and passing it to ContentView's environment object.

@Environment

@Environment property wrapper allows us to use system default settings like whether the device is in dark mode or light mode, device's current timezone, etc. Here is the example,

struct ContentView: View {
    @Environment(\.timeZone) var timeZone: TimeZone
    
    var body: some View {
        VStack {
            Text("Your Timezone: \(self.timeZone.abbreviation() ?? "N/A")")        }
    }
}

In above example, we have simple screen that display device's default currency code in the center of screen.

Conclusion

Property wrappers are powerful and playing a huge role while working with SwiftUI. You need to choose wisely which property wrapper you need to use and how to use it. If you have any questions feel free to follow me on Twitter and ask me your questions.

Thank you for reading! 😀 Peace ✌️

Basic structure of SwiftUI project

Mon, 23 Dec 2019 00:00:00 GMT

Apple introduced SwiftUI in WWDC 2019 that enabled a new way to create user-interface of your iOS app.

Whenever you create your single view app using SwiftUI, You will get the following basic template of your app.

Let's discuss more about this all files,

AppDelegate.swift

After SwiftUI introduced, Appdelegate is only responsible for setting up external dependency and managing application data(ex. coredata).

SceneDelegate.swift

This is something new you can see in a project that is created using SwiftUI. SeceneDelegate is responsible for managing the way your app is shown. This contains the app transition methods that handle the app enter in the foreground, enter in the background, etc.

ContentView.swift

This is an initial view of your application. In this file, you can create your app interface using a declarative way. This is equivalent to ViewController that is being generated in the project that is created without using SwiftUI.

Assets.assets

As usual as previous, Assets contain all the images and colors that are used in our project.

LaunchScree.storyboard

This screen is displayed as a launch screen(splash screen) of your app. Nothing changes the way we setting up the launch screen previously.

Info.plist

This is a property list file that states all the system related settings like app name, app version, build number, etc.

Preview Contain

This folder includes one another asset catalog that is used at preview time in canvas.

Thanks for reading, Happy Holidays 🎅🎄

Sagar Unagar's Blog

Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange

How SwiftUI Layout Actually Works

GeometryReader

Important Behavior

GeometryProxy - The Core Abstraction

size

frame(in:)

safeAreaInsets

Coordinate Spaces Explained

.local

.global

.named("custom")

Measuring Child Views with Preferences

Step 1: Define a PreferenceKey

Step 2: Attach Geometry in Background

Step 3: Observe Changes

.onGeometryChange - The Modern Way

Scroll Offset Example (Modern Approach)

GeometryReader vs .onGeometryChange

Geometry vs the Layout Protocol

Common Pitfalls

Wrapping entire screens in GeometryReader

Creating layout feedback loops

Using geometry when Spacer is enough

The Mental Model

Final Thoughts

Static vs Dynamic Dispatch in Swift - How Method Dispatch Really Works

What Is Dispatch in Swift?

Static Dispatch

Static Dispatch with Value Types

Static Dispatch with final Classes

Benefits of Static Dispatch

Dynamic Dispatch

Dynamic Dispatch with Class Inheritance

Dynamic Dispatch with Protocol Existentials

Protocols, Generics, and Dispatch

Protocols as Generic Constraints (Static Dispatch)

Protocols as Types (Dynamic Dispatch)

How @objc and dynamic Change Dispatch

Dispatch Behavior Summary

How Swift Chooses Which Dispatch to Use

Practical Design Guidelines

Prefer Static Dispatch When

Prefer Dynamic Dispatch When

Common Misconceptions

"Swift always uses static dispatch"

“Dynamic dispatch is slow and should be avoided”

“Protocols are slow”

Final Thoughts

Copy-on-Write(CoW) in Swift - How It Works and Why It Optimizes Memory

What Is Copy-on-Write?

The Problem Copy-on-Write Solves

Observing Copy-on-Write in Action

Example 1 — Assignment Without Mutation

Example 2 — Mutation Triggers Copy

How Swift Knows When to Copy

Deep Dive: isKnownUniquelyReferenced

Why the Parameter Is inout

What “Known” Means

Value Semantics Is Not Copy-on-Write

Why Some Types Use Copy-on-Write

The Architectural Distinction

Implementing Copy-on-Write Manually

Step 1 — Reference Storage

Step 2 — Struct Wrapper

The Critical Mutation Gate: ensureUnique()

Why ensureUnique() Is mutating

What ensureUnique() Actually Does

Step-by-Step Execution Flow

Step 1 — Assignment

Step 2 — Mutation Begins

Step 3 — Copy Created

Step 4 — Safe Mutation

Why This Pattern Is Essential

Performance Characteristics

Why Swift Uses Copy-on-Write

Key Design Principles for Custom CoW Types

Final Thoughts

AsyncStream & AsyncThrowingStream in Swift - Real-Time Data Sync Explained

`GeometryReader`

`GeometryProxy` - The Core Abstraction

`size`

`frame(in:)`

`safeAreaInsets`

`.local`

`.global`

`.named("custom")`

`.onGeometryChange` - The Modern Way

`GeometryReader` vs `.onGeometryChange`

Geometry vs the `Layout` Protocol

Wrapping entire screens in `GeometryReader`

Static Dispatch with `final` Classes

How `@objc` and `dynamic` Change Dispatch

Deep Dive: `isKnownUniquelyReferenced`

Why the Parameter Is `inout`

The Critical Mutation Gate: `ensureUnique()`

Why `ensureUnique()` Is `mutating`

What `ensureUnique()` Actually Does

`AsyncSequence`: The Foundation

What is `AsyncStream`?

Why `AsyncStream` Exists

How `AsyncStream` Works (Conceptually)

Anatomy of `AsyncStream`

Important Characteristics of `AsyncStream`

What is `AsyncThrowingStream`?

Why `AsyncThrowingStream` Exists

Anatomy of `AsyncThrowingStream`

Key Characteristics of `AsyncThrowingStream`

`AsyncStream` vs `AsyncThrowingStream` (Mental Model)

Step 1: Model Firestore as an `AsyncThrowingStream`

Where `AsyncStream` Fits in Reckord

What Is `EnvironmentKey`?

What Is `EnvironmentValues`?

Modeling Theme Choices with `Theme`

Introducing `@Observable`

Correct Initialization Using `@State`

Old (`ObservableObject`)

New (`@Observable`)

When Should You Use `@Observable`?