Sagar Unagar's Blog

associatedtype in Swift Explained - A Complete Guide with SwiftUI Examples

Sat, 18 Apr 2026 00:00:00 GMT

Swift’s type system is designed to strike a balance between flexibility and compile-time safety. At the center of this balance lies a feature that often feels abstract at first but becomes indispensable as your codebase grows:

associatedtype

If you’ve worked with protocols like Sequence, built generic APIs, or written SwiftUI views, you’ve already depended on it whether you realized it or not.

This article takes a deep, practical look at:

What associatedtype is
Why it exists
How it differs from generics
How SwiftUI is built on top of it
Real world architectural patterns

What is `associatedtype`?

An associatedtype defines a placeholder type inside a protocol.

It allows the protocol to say:

“I operate on a type but the conforming type will decide what that is.”

Basic Example

protocol Container {
    associatedtype Item

    func add(_ item: Item)
    func get() -> Item
}

Here:

Item is not defined yet
Each conforming type provides its own concrete type

Why This Matters

Without associatedtype, protocols would be rigid:

protocol StringContainer {
    func add(_ item: String)
}

This locks you into one type.

With associatedtype, you unlock generic behavior at the protocol level.

`associatedtype` vs Generics

At first glance, associatedtype looks similar to generics but they solve different problems.

Generics

struct Box<T> {
    let value: T
}

Type is chosen by the caller
Used to build flexible concrete types

Associated Types

protocol Box {
    associatedtype Value
    var value: Value { get }
}

Type is chosen by the conformer
Used to define flexible abstractions

Mental Model

Generics → “I will work with any type you give me”

Associated Type → “I will define the type when I conform”

Concrete Example

Without `associatedtype`

protocol Animal {
    func eat(food: String)
}

Too restrictive.

With `associatedtype`

protocol Animal {
    associatedtype Food
    func eat(_ food: Food)
}

Now each type defines its own food.

Conforming Types

struct Cow: Animal {
    func eat(_ food: String) {
        print("Cow eats \(food)")
    }
}

struct Lion: Animal {
    func eat(_ food: Int) {
        print("Lion eats \(food) hamburger\(food > 1 ? "s" : "")")
    }
}

Swift infers:

Cow.Food == String
Lion.Food == Int

Explicit Type Binding

struct Bird: Animal {
    typealias Food = String

    func eat(_ food: String) {
        print("Bird eats \(food)")
    }
}

Useful when inference isn’t enough.

Associated Types in the Standard Library

You use this daily.

Sequence

public protocol Sequence {
    associatedtype Element
}

Example:

let numbers: [Int] = [1, 2, 3]

Here:

Array.Element == Int

This is what enables Swift’s powerful collection system.

Adding Constraints

Associated types can be constrained:

protocol Cache {
    associatedtype Key: Hashable
    associatedtype Value

    mutating func insert(_ value: Value, for key: Key)
    func get(_ key: Key) -> Value?
}

Implementation

struct MemoryCache<K: Hashable, V>: Cache {
    private var storage: [K: V] = [:]

    mutating func insert(_ value: V, for key: K) {
        storage[key] = value
    }

    func get(_ key: K) -> V? {
        storage[key]
    }
}

Conditional Behavior with `where`

protocol Container {
    associatedtype Item
    func items() -> [Item]
}

extension Container where Item: Comparable {
    func sortedItems() -> [Item] {
        items().sorted()
    }
}

👉 Behavior adapts based on the associated type.

Why `associatedtype` Matters in SwiftUI

This is where things get real.

The `View` Protocol

The View protocol is defined as:

public protocol View {
    associatedtype Body: View
    @ViewBuilder var body: Self.Body { get }
}

Why Not `var body: View`?

Because SwiftUI is designed for:

Compile-time optimization
Structural typing
Zero-cost abstractions

If it used:

var body: View

It would require:

Type erasure
Runtime dispatch
Performance loss

Instead

associatedtype Body

This allows SwiftUI to:

Know exact types at compile time
Optimize rendering
Avoid runtime overhead

The Problem: “Why can’t I write `[View]`?”

var views: [View] // ❌

This fails because:

View has an associatedtype
Swift cannot determine a single concrete type

What’s Really Happening

Each view has a different underlying type:

Text("Hello")
Image(systemName: "star")
VStack { ... }

Each has a different Body.

Swift cannot unify them into one type.

The Solution: Type Erasure (`AnyView`)

var views: [AnyView]

let views = [
    AnyView(Text("Hello")),
    AnyView(Image(systemName: "star"))
]

What `AnyView` Does

Wraps different view types
Hides their concrete type
Provides a single uniform type

Trade-offs

Using AnyView:

Loses compile-time guarantees
Reduces SwiftUI optimizations
Can impact performance

Better Patterns

1. Use @ViewBuilder

@ViewBuilder
func makeView(isLoggedIn: Bool) -> some View {
    if isLoggedIn {
        Text("Welcome")
    } else {
        Image(systemName: "lock")
    }
}

2. Use Enums

enum Screen {
    case home
    case profile
}

3. Use Generics

struct Container<Content: View>: View {
    let content: Content

    var body: some View {
        content
    }
}

Advanced Pattern: `associatedtype` + ViewModel

This is where associatedtype shines in real world SwiftUI architecture.

Protocol Definition

protocol ViewModel {
    associatedtype State
    var state: State { get }
}

Why This Matters

This allows each ViewModel to define its own state structure.

Example

struct UserViewModel: ViewModel {
    struct State {
        let name: String
        let age: Int
    }

    var state: State
}

struct ProductViewModel: ViewModel {
    struct State {
        let title: String
        let price: Double
    }

    var state: State
}

What You Gain

Strong typing
Flexible architecture
Feature isolation

SwiftUI Integration

struct UserView: View {
    let viewModel: UserViewModel

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

Using `any ViewModel`

With modern Swift, you can now write:

var viewModels: [any ViewModel]

This uses an existential type, enabled by the any keyword.

To learn more about existential types, read: Swift some vs any - Understanding Opaque Types and Existential Types

👉 It tells Swift:

“Store values that conform to ViewModel, regardless of their concrete type.”

But There’s a Catch (Important)

While this compiles, it introduces a key limitation:

let vm = viewModels[0]
vm.state // ❌ Not accessible in a useful way

Why?

Because:

Each ViewModel has a different State
The existential any ViewModel erases that associated type
Swift no longer knows what State actually is

What You Can and Cannot Do

✅ Allowed

var viewModels: [any ViewModel]

You can:

Store heterogeneous ViewModels
Pass them around abstractly

❌ Not Practical

vm.state // type is unknown

You cannot:

Safely access state
Use it without casting or further abstraction

When `any ViewModel` Makes Sense

Use it when:

You only care about shared behavior (not associated types)
You’re building loosely coupled systems
You’re passing ViewModels across module boundaries

When It Breaks Down

If your UI depends on State (which it almost always does in SwiftUI):

👉 any ViewModel becomes insufficient.

Production Patterns

1. Generic Views

struct ContentView<VM: ViewModel>: View {
    let viewModel: VM

    var body: some View {
        Text(verbatim: "\(viewModel.state)")
    }
}

2. Constrained State

protocol ViewModel {
    associatedtype State: Equatable
    var state: State { get }
}

3. `ObservableObject` Integration

protocol ViewModel: ObservableObject {
    associatedtype State
    var state: State { get }
}

class UserViewModel: ViewModel {
    struct State {
        var name: String
    }

    @Published var state = State(name: "John")
}

4. Type Erasure for ViewModels

class AnyViewModel<State>: ViewModel {
    private let _state: () -> State

    var state: State { _state() }

    init<VM: ViewModel>(_ vm: VM) where VM.State == State {
        _state = { vm.state }
    }
}

5. Enum Based State

enum AppState {
    case user(UserState)
    case product(ProductState)
}

Key Takeaways

associatedtype defines flexible placeholder types in protocols
It enables strong, compile-time abstractions
It powers:
- Swift Standard Library (Sequence)
- SwiftUI (View)
It comes with a trade-off:
- ❌ Cannot be used as a concrete type
- ✅ Enables high performance and safety

Final Thoughts

associatedtype is one of those features that can feel abstract when you first encounter it but over time, it becomes a cornerstone of how you design expressive, scalable Swift code.

At its core, it enables a powerful idea:

Protocols can define behavior without locking themselves to concrete types.

This is what allows Swift to maintain a delicate balance between flexibility and strict type safety.

If you have suggestions, feel free to connect with me on X and send me a DM. If this article helped you, Buy me a coffee.

Lazy Properties in Swift - Why They Don’t Always Work in SwiftUI

Sat, 11 Apr 2026 00:00:00 GMT

Swift provides a powerful set of tools to manage initialization, performance, and memory. Among them, lazy properties stand out as a simple yet highly effective way to defer work until it is actually needed.

At first glance, lazy may look like a small keyword. In practice, it enables better performance, cleaner initialization patterns, and more predictable ownership-when used correctly.

This article explores lazy properties in depth: what they are, how they work, when to use them, and how they behave in real-world SwiftUI applications.

What is a Lazy Property?

A lazy stored property is a property whose initial value is not computed until it is accessed for the first time.

You declare it using the lazy keyword:

class DataLoader {
    lazy var data: [String] = {
        print("Loading data...")
        return ["Apple", "Banana", "Cherry"]
    }()
}

Key Idea

Regular stored properties → initialized during instance creation
Lazy stored properties → initialized on first access

Why Lazy Properties Matter

Lazy properties solve three common problems in production code.

1. Avoid Unnecessary Work

If a property is expensive to create but not always needed, lazy initialization prevents wasted computation.

class ImageProcessor {
    lazy var filter = createHeavyFilter()

    private func createHeavyFilter() -> String {
        print("Creating filter...")
        return "Filter Ready"
    }
}

If filter is never accessed, the work is never performed.

2. Improve Performance and Startup Time

Lazy properties defer work, which can:

Reduce initial load time
Improve responsiveness
Avoid blocking the main thread early

This is especially important in UI-heavy applications.

3. Enable Self-Dependent Initialization

Lazy properties can reference self, because they are initialized after the instance is fully created.

class User {
    let name: String

    lazy var greeting: String = {
        return "Hello, \(self.name)"
    }()

    init(name: String) {
        self.name = name
    }
}

This is not possible with regular stored properties.

How Lazy Properties Work

Conceptually, Swift implements lazy properties as:

A stored optional backing value
A one-time initialization closure
Cached result after first execution

Equivalent behavior:

private var _data: [String]? = nil

var data: [String] {
    if let value = _data {
        return value
    }
    let newValue = ["Apple", "Banana"]
    _data = newValue
    return newValue
}

Swift abstracts this pattern with the lazy keyword.

Syntax Variations

Simple Lazy Property

lazy var message = "Hello"

Lazy Property with Closure

lazy var formatter: DateFormatter = {
    let formatter = DateFormatter()
    formatter.dateStyle = .medium
    return formatter
}()

Lazy Property Using a Function

lazy var data = loadData()

func loadData() -> [Int] {
    return [1, 2, 3]
}

Rules and Characteristics

Must Be Declared with `var`

lazy var value = 10   // ✅
lazy let value = 10   // ❌

Only Stored Properties Can Be Lazy

Computed properties cannot be lazy.

Initialized Only Once

let loader = DataLoader()

print(loader.data) // Initializes
print(loader.data) // Reuses cached value

Not Thread-Safe by Default

Lazy properties are not guaranteed to be thread-safe.

If accessed from multiple threads simultaneously, initialization may occur more than once.

Real-World Use Cases (SwiftUI + Production Guidance)

Lazy properties are often introduced as a performance optimization. In real-world code, their usefulness depends on lifecycle and ownership especially in SwiftUI.

1. Expensive Object Creation

struct ContentView: View {
    private lazy var formatter: DateFormatter = {
        print("Creating formatter...")
        let formatter = DateFormatter()
        formatter.dateStyle = .long
        return formatter
    }()

    var body: some View {
        Text(formatter.string(from: Date()))
    }
}

Production Insight

This looks correct but in SwiftUI:

Views are value types
They can be recreated frequently

This means:

A lazy property inside a SwiftUI view is not guaranteed to behave like a persistent cache.

Above block of code wont compile, reason being:

Lazy properties require mutation on first access. Since SwiftUI views are structs and body is non-mutating, lazy properties cannot be used directly inside SwiftUI views.

Recommended Approach

Use state or object-backed storage:

struct ContentView: View {
    @State private var formatter = DateFormatter()

    var body: some View {
        Text(formatter.string(from: Date()))
    }
}

Or:

import Combine
class FormatterProvider: ObservableObject {
    lazy var formatter: DateFormatter = {
        print("Creating formatter...")
        let formatter = DateFormatter()
        formatter.dateStyle = .long
        return formatter
    }()
}

struct ContentView: View {
    @StateObject private var provider = FormatterProvider()

    var body: some View {
        Text(provider.formatter.string(from: Date()))
    }
}

Why This Works

FormatterProvider is a class → lazy works correctly
@StateObject ensures stable lifecycle
Formatter is created only once

2. Deferring Heavy View Construction

struct DashboardView: View {
    private lazy var chartView: some View = {
        return ChartView(data: loadLargeDataset())
    }()

    var body: some View {
        VStack {
            Text("Dashboard")
            chartView
        }
    }
}

Production Insight

This pattern is misleading and wont compile.

SwiftUI already:

Lazily evaluates body
Optimizes rendering internally

You rarely need lazy for views themselves.

Better Pattern: Lazy Data, Not Lazy Views

struct DashboardView: View {
    @State private var data: [Int]? = nil

    var body: some View {
        VStack {
            if let data {
                ChartView(data: data)
            } else {
                ProgressView()
                    .onAppear {
                        data = loadLargeDataset()
                    }
            }
        }
    }

    private func loadLargeDataset() -> [Int] {
        return Array(0...10_000)
    }
}

This pattern works because it:

Uses persistent state (@State)
Triggers work at the right lifecycle moment (onAppear)
Keeps UI predictable and declarative

In SwiftUI, you don’t “delay initialization” with lazy.
You control state and lifecycle explicitly.

3. Dependency-Based Initialization

class NetworkManager {
    let baseURL: String

    lazy var fullURL: String = {
        return "\(baseURL)/api/v1"
    }()

    init(baseURL: String) {
        self.baseURL = baseURL
    }
}

This is the ideal use case for lazy:

A value that depends on self, is not needed immediately, and should be computed once and cached.

4. Caching Computed Results

class Fibonacci {
    lazy var result: [Int] = compute()

    private func compute() -> [Int] {
        print("Computing...")
        return [0, 1, 1, 2, 3, 5, 8]
    }
}

This pattern expresses intent directly:
> compute this value once, only when needed, and reuse it.

That’s what makes it:

Clean → minimal and readable
Efficient → avoids redundant work
Expressive → communicates behavior clearly

Lazy vs Computed Properties

Feature	Lazy Property	Computed Property
Storage	Stored	Not stored
Execution	Once	Every access
Performance	Cached	Recomputed
Use Case	Expensive setup	Dynamic values

Common Pitfalls

Retain Cycles

Closures can capture self strongly:

lazy var value: String = {
    return self.compute()
}()

Use [weak self] if needed.

Hidden Performance Cost

Lazy defers work but that cost still exists. If triggered on the main thread, it can cause UI delays.

Thread Safety

Lazy properties are not inherently safe in concurrent environments.

Best Practices

Prefer lazy in classes (reference types)
Use for expensive or optional initialization
Avoid in SwiftUI views unless necessary
Use for:
- Formatters
- Services
- Cached computations

When NOT to Use Lazy

Avoid lazy when:

Value is cheap to compute
Always needed immediately
Requires strict thread safety
You rely on stable lifecycle in SwiftUI

Opinionated Guidelines (Production)

Use lazy when:

You want deferred + cached computation
Initialization depends on self
You are inside a class with stable identity

Avoid lazy when:

You are inside SwiftUI struct views
You need predictable lifecycle guarantees
You are optimizing prematurely

Final Thoughts

Lazy properties are often misunderstood as a micro-optimization. In reality, they are a lifecycle and ownership tool.

Used correctly, they help you:

Defer meaningful work
Improve performance
Simplify initialization logic
Used incorrectly, they can introduce subtle bugs-especially in SwiftUI.

The goal is not to use lazy everywhere, but to use it where lifecycle control matters.

If you have suggestions, feel free to connect with me on X and send me a DM. If this article helped you, Buy me a coffee.

Mutex in Swift - Protecting Shared Mutable State with Locks

Sat, 04 Apr 2026 00:00:00 GMT

In modern Swift development, managing shared mutable state is a fundamental challenge. As applications become increasingly concurrent, ensuring that multiple threads do not access or modify the same data simultaneously—leading to data races—is paramount.

While Actors are the primary tool for isolation in Swift Concurrency, there are performance-critical scenarios where a lower-level synchronization primitive is required. The Mutex type, part of the Synchronization library, provides a high-performance, synchronous solution for protecting shared state.

In this article, we will explore the core mechanics of the Mutex primitive in Swift. You will learn how to use this synchronization tool to safeguard shared mutable state, understand the technical reasoning for choosing it over high-level Actors, and see practical implementations that integrate seamlessly with Swift Concurrency.

What is Mutex??

A Mutex (short for Mutual Exclusion) is a synchronization primitive that ensures only one thread can access a resource at any given time. In Swift, Mutex<Value> is a generic type that wraps a piece of data and gatekeeps access to it.

Unlike asynchronous isolation patterns, a Mutex is synchronous. When a thread requests access to the protected value, it will "block" (wait) until the resource is available, rather than suspending the current task.

Key Characteristics

Thread Safety: It eliminates data races by enforcing exclusive access.
Value Wrapping: The data being protected is stored directly inside the Mutex, ensuring it cannot be accessed without proper locking.
Sendability: Mutex is inherently Sendable, making it safe to pass across concurrency boundaries.
Performance: It is designed for low-latency, high-frequency synchronization where the overhead of an Actor might be undesirable.

Why Mutex Matters?

In the Swift Concurrency model, Actors are excellent for high-level domain logic. However, they are asynchronous by nature. Every time you access an Actor’s state, you must use the await keyword, which allows the system to suspend the current task.

There are specific cases where await is not ideal:

Synchronous Contexts: When you need to protect state inside a function that cannot be async.
Performance Sensitivity: When the overhead of task switching and suspension outweighs the work being done.
Tight Loops: When updating a counter or a small cache thousands of times per second.

Comparison: Mutex vs. Actors

Feature	Mutex	Actors
Access Pattern	Synchronous (Blocking)	Asynchronous (Suspending)
Reentrancy	Non-reentrant	Reentrant
Complexity	Low-level / Primitive	High-level / Structured
Best For	Small, fast critical sections	Large-scale state management

How to Use Mutex

To use the Mutex type, you must import the Synchronization framework. This library provides primitives that are fine-tuned for the Swift runtime.

Basic Initialization

You define a Mutex by passing the initial value you wish to protect.

import Synchronization

// A simple shared counter protected by a Mutex
let loginAttempts = Mutex(0)

The `withLock` Method

The only way to access or modify the value inside a Mutex is through the withLock method. This method ensures the lock is acquired before your code runs and is automatically released when your code finishes.

loginAttempts.withLock { count in
    // Access is exclusive to this closure
    count += 1
}

Example: A Thread-Safe Atomic Cache

Below is an implementation of a ThreadSafeCache. This example demonstrates how to wrap a complex type (a Dictionary) and provide safe, synchronous access to it from multiple threads.

import Synchronization
import Foundation

final class ThreadSafeCache<Key: Hashable & Sendable, Value: Sendable>: Sendable {
    private let storage = Mutex([Key: Value]())

    // nonisolated allows these to be called synchronously from any context
    nonisolated func set(_ value: Value, for key: Key) {
        storage.withLock { dict in
            dict[key] = value
        }
    }

    nonisolated func value(for key: Key) -> Value? {
        storage.withLock { dict in
            dict[key]
        }
    }
}

// Usage
let userSessionCache = ThreadSafeCache<String, Date>()

// This can be safely called from multiple concurrent Tasks
Task.detached {
    userSessionCache.set(Date(), for: "user_123")
}

NOTE: The use of nonisolated on the methods - this is crucial for Swift 6 compatibility.

1. Encapsulation: By making storage private, we guarantee that the only way to touch the dictionary is through the Mutex interface.

2. Explicit Non-isolation: By marking methods nonisolated, we tell the compiler that these methods do not belong to any specific actor (like the Main Actor). This allows them to be called from a background thread without await.

3. In-place Mutation: Inside withLock, the dictionary is passed as an inout parameter. This allows you to modify the dictionary directly without copying the entire collection, which is highly efficient.

4. Scoped Locking: The lock is held only for the duration of the closure. Once the closure returns, the lock is released. This prevents "leaked" locks that can happen with manual lock() and unlock() calls.

5. Sendability: Because both the Key and Value are Sendable, and Mutex itself is Sendable, the entire ThreadSafeCache class is thread-safe and can be passed between tasks.

Common Pitfall: Main Actor Isolation

In Swift 6, you might encounter a warning when using your thread-safe class:

Main actor-isolated instance method 'set(_:for:)' cannot be called from outside of the actor; this is an error in the Swift 6 language mode

This usually happens because the variable instance was declared in a @MainActor context (like a View or a ViewController). Even though the class uses a Mutex, Swift's safety rules still protect the reference to that class.

The Fix: Mark the property as nonisolated if it is stored in a MainActor-isolated type:

@MainActor
class ViewModel {
    // Adding nonisolated tells the compiler this reference is safe to use anywhere
    nonisolated let cache = ThreadSafeCache<String, String>()

    func updateCache() {
        Task.detached {
            // Now this works synchronously without 'await'
            self.cache.set("Active", for: "session_status")
        }
    }
}

Performance and Best Practices

While Mutex is powerful, it should be used judiciously. Because it blocks the calling thread, it can lead to performance bottlenecks if misused.

1. Keep Critical Sections Small
Perform the absolute minimum amount of work necessary inside the withLock closure. Avoid performing I/O, networking, or heavy computation while holding a lock.

2. Avoid Nested Locking
Do not call withLock on the same Mutex instance while already inside a withLock closure. This will cause a deadlock.

3. Prefer Actors for Complexity
If your shared state involves complex logic or needs to perform asynchronous work, an Actor is the better choice. Use Mutex for simple values or collections that need high-speed, synchronous access.

Final Thoughts

The Mutex type is a vital addition to the Swift developer’s toolkit. It provides a bridge between the safety requirements of modern concurrency and the performance needs of low-level programming.

Use Mutex for small, fast, synchronous state protection.
Use Actors for high-level, asynchronous domain modeling.
Keep locked closures as short as possible to maintain application responsiveness.

If you have suggestions, feel free to connect with me on X and send me a DM. If this article helped you, Buy me a coffee.

Animatable in SwiftUI Explained - Complete Guide with Examples & Deep Dive

Sat, 28 Mar 2026 00:00:00 GMT

SwiftUI provides a powerful, declarative animation system that enables smooth, expressive user interfaces. In most cases, animations can be achieved using built in APIs like withAnimation or .animation(_:).

However, when you need precise control over how values change over time, SwiftUI exposes a deeper mechanism: the Animatable protocol.

This article explores how Animatable works, why it matters, and how to use it to build custom, data-driven animations.

What is `Animatable`?

Animatable is a protocol that allows a type to define which of its values should be interpolated during animation.

var animatableData: Self.AnimatableData { get set }

The associated type must conform to VectorArithmetic, which enables SwiftUI to perform interpolation between values.

Why Does `Animatable` Matter?

SwiftUI does not animate views directly. Instead, it animates data, and views are recomputed from that data.

When a value changes inside a withAnimation block:

SwiftUI captures the initial value
Interpolates intermediate values
Recomputes the view on each frame

Without Animatable, changes are treated as instant jumps.

💡 SwiftUI animates data, not views.

How SwiftUI Uses `Animatable`

Every animation follows this pipeline:

State Change
    ↓
withAnimation
    ↓
animatableData
    ↓
Interpolated values
    ↓
View recomputed
    ↓
Rendered frame

Each frame is a fresh evaluation of your body.

Conforming to `Animatable`

To make a custom type animatable:

Conform to Animatable (or Shape)
Expose animatable values via animatableData
Let SwiftUI interpolate those values

Using `@Animatable` and `@AnimatableIgnored` Macros

Modern SwiftUI introduces macros that simplify working with Animatable, reducing boilerplate and improving readability.

Why These Macros Exist

Traditionally, you had to manually implement:

var animatableData: VectorArithmetic {
    get { ... }
    set { ... }
}

This becomes repetitive and harder to maintain as complexity grows.

`@Animatable`

The @Animatable macro automatically synthesizes animatableData.

@Animatable
struct RoundedRectangleShape: Shape {
    var cornerRadius: CGFloat

    func path(in rect: CGRect) -> Path {
        Path(roundedRect: rect, cornerRadius: cornerRadius)
    }
}

What It Does

Detects animatable properties
Generates animatableData
Handles interpolation automatically

💡 You define what, SwiftUI handles how.

Multiple Properties Example

@Animatable
struct WaveShape: Shape {
    var amplitude: CGFloat
    var frequency: CGFloat

    func path(in rect: CGRect) -> Path {
        // drawing logic
    }
}

SwiftUI internally behaves like:

AnimatablePair(amplitude, frequency)

`@AnimatableIgnored`

Used to exclude properties from animation.

@Animatable
struct CustomShape: Shape {
    var progress: Double

    @AnimatableIgnored
    var color: Color

    func path(in rect: CGRect) -> Path {
        // drawing logic
    }
}

Why It Matters

Some types should not be animated:

Color
String
Bool

These can break interpolation.

💡 @Animatable defines what animates, @AnimatableIgnored defines what doesn’t.

When to Use Macros

Use macros when:

You want cleaner code
You have simple animatable properties

Avoid when:

You need custom interpolation logic
You’re implementing VectorArithmetic

Example 1: Animating a Custom Shape (Corner Radius)

import SwiftUI

struct RoundedRectangleShape: Shape {
    var cornerRadius: CGFloat

    var animatableData: CGFloat {
        get { cornerRadius }
        set { cornerRadius = newValue }
    }

    func path(in rect: CGRect) -> Path {
        Path(roundedRect: rect, cornerRadius: cornerRadius)
    }
}

struct CornerRadiusExampleView: View {
    @State private var radius: CGFloat = 0

    var body: some View {
        VStack(spacing: 20) {
            RoundedRectangleShape(cornerRadius: radius)
                .fill(Color.blue.gradient)
                .frame(width: 200, height: 200)

            Button("Toggle Radius") {
                withAnimation(.easeInOut(duration: 1)) {
                    radius = radius == 0 ? 60 : 0
                }
            }
        }
        .padding()
    }
}

Output:

What is `animatableData`?

animatableData is the core property that connects your type to SwiftUI’s animation system.

It tells SwiftUI:

“These are the values you can interpolate over time.”

In this example:

var animatableData: CGFloat

You are explicitly saying:

The animation should happen on cornerRadius
SwiftUI can interpolate it as a numeric value

Why Does `animatableData` Exist?

SwiftUI animations are generic and type agnostic.

The framework does not know:

What your custom properties represent
Which ones should animate
How to interpolate them

So you must expose animatable values through animatableData.

How SwiftUI Uses `animatableData`

When this code runs:

withAnimation {
    radius = 60
}

SwiftUI performs the following steps:

Capture Initial Value

cornerRadius = 0

Determine Target Value

cornerRadius = 60

Interpolate Using animatableData

0 → 8 → 16 → 24 → 32 → 48 → 60

Update Your Shape

For each frame:

cornerRadius = newValue

Recompute the Path

path(in:)

Why Getter and Setter Matter

get { cornerRadius }
set { cornerRadius = newValue }

Getter → gives SwiftUI the current value
Setter → allows SwiftUI to inject interpolated values

Without the setter, your shape would never update during animation.

What Happens If You Remove `animatableData`?

If you remove this:

var animatableData: CGFloat {
    get { cornerRadius }
    set { cornerRadius = newValue }
}

SwiftUI loses the ability to:

Interpolate values
Generate intermediate frames

Result:

0 → 60 (instant jump, no animation)

💡 animatableData is the bridge between your state and SwiftUI’s animation engine.

Example 2: Animating Multiple Values with `AnimatablePair`

import SwiftUI

struct WaveShape: Shape {
    var amplitude: CGFloat
    var frequency: CGFloat

    var animatableData: AnimatablePair<CGFloat, CGFloat> {
        get { AnimatablePair(amplitude, frequency) }
        set {
            amplitude = newValue.first
            frequency = newValue.second
        }
    }

    func path(in rect: CGRect) -> Path {
        var path = Path()

        for x in stride(from: 0, through: rect.width, by: 1) {
            let relativeX = x / rect.width
            let y = amplitude * sin(frequency * relativeX * .pi * 2)

            if x == 0 {
                path.move(to: CGPoint(x: x, y: y + rect.midY))
            } else {
                path.addLine(to: CGPoint(x: x, y: y + rect.midY))
            }
        }

        return path
    }
}

struct WaveExampleView: View {
    @State private var amplitude: CGFloat = 10
    @State private var frequency: CGFloat = 1

    var body: some View {
        VStack(spacing: 20) {
            WaveShape(amplitude: amplitude, frequency: frequency)
                .stroke(Color.blue.gradient, lineWidth: 2)
                .frame(height: 200)

            Button("Animate Wave") {
                withAnimation(.easeInOut(duration: 1)) {
                    amplitude = amplitude == 10 ? 50 : 10
                    frequency = frequency == 1 ? 3 : 1
                }
            }
        }
        .padding()
    }
}

Output:

What is `AnimatablePair`?

AnimatablePair is a built-in SwiftUI type that allows you to combine two animatable values into a single animatable unit.

AnimatablePair<First, Second>

Both First and Second must conform to VectorArithmetic.

Why Does `AnimatablePair` Exist?

SwiftUI’s animation system expects one animatable value:

var animatableData: VectorArithmetic

But real-world UI often depends on multiple values:

A wave needs both amplitude and frequency
A rectangle might need width and height
A transform might need scale and rotation

AnimatablePair solves this by acting as a container that SwiftUI can still interpolate.

How SwiftUI Uses `AnimatablePair`

Internally, SwiftUI treats AnimatablePair as a 2D vector:

(amplitude, frequency)

When animation runs:

(10, 1) → (50, 3)

SwiftUI interpolates both dimensions independently:

Frame 1: (10, 1)
Frame 2: (20, 1.5)
Frame 3: (30, 2)
Frame 4: (40, 2.5)
Frame 5: (50, 3)

Why the Setter is Critical

set {
    amplitude = newValue.first
    frequency = newValue.second
}

This ensures that:

Interpolated values from SwiftUI
Are written back into your properties
And used inside path(in:)

Without this, animation will not update correctly.

💡 AnimatablePair allows SwiftUI to treat multiple values as a single animatable vector.

Example 3: Animating Complex Data with `VectorArithmetic`

import SwiftUI

struct AnimatableVector: VectorArithmetic {
    var values: [CGFloat]

    static var zero: AnimatableVector {
        AnimatableVector(values: [0, 0, 0])
    }

    static func + (lhs: AnimatableVector, rhs: AnimatableVector) -> AnimatableVector {
        AnimatableVector(values: zip(lhs.values, rhs.values).map(+))
    }

    static func - (lhs: AnimatableVector, rhs: AnimatableVector) -> AnimatableVector {
        AnimatableVector(values: zip(lhs.values, rhs.values).map(-))
    }

    mutating func scale(by rhs: Double) {
        values = values.map { $0 * CGFloat(rhs) }
    }

    var magnitudeSquared: Double {
        values.reduce(0) { $0 + Double($1 * $1) }
    }
}

struct BarChartShape: Shape {
    var values: AnimatableVector

    var animatableData: AnimatableVector {
        get { values }
        set { values = newValue }
    }

    func path(in rect: CGRect) -> Path {
        var path = Path()
        let barWidth = rect.width / CGFloat(values.values.count)

        for (index, value) in values.values.enumerated() {
            let x = CGFloat(index) * barWidth
            let height = rect.height * value

            path.addRect(
                CGRect(
                    x: x,
                    y: rect.height - height,
                    width: barWidth - 6,
                    height: height
                )
            )
        }

        return path
    }
}

struct BarChartExampleView: View {
    @State private var data = AnimatableVector(values: [0.2, 0.4, 0.3])

    var body: some View {
        VStack(spacing: 20) {
            BarChartShape(values: data)
                .fill(Color.blue.gradient)
                .frame(height: 200)

            Button("Randomize Data") {
                withAnimation(.easeInOut(duration: 1)) {
                    data = AnimatableVector(values: [
                        .random(in: 0.1...1),
                        .random(in: 0.1...1),
                        .random(in: 0.1...1)
                    ])
                }
            }
        }
        .padding()
    }
}

Output:

What is `VectorArithmetic`?

VectorArithmetic is a protocol that defines how values behave like mathematical vectors.

It enables SwiftUI to:

Add values (+)
Subtract values (-)
Scale values (scale(by:))
Measure distance (magnitudeSquared)

Why Does SwiftUI Require `VectorArithmetic`?

Animation is fundamentally interpolation between values.

SwiftUI performs operations like:

current + (target - current) * progress

To do this generically, SwiftUI needs:

Arithmetic operations
Consistent scaling
Distance calculation

That’s exactly what VectorArithmetic provides.

How It Applies to This Example

Your data:

[0.2, 0.4, 0.3]

Target:

[0.8, 0.1, 0.6]

SwiftUI interpolates element-wise:

Frame 1: [0.2, 0.4, 0.3]
Frame 2: [0.4, 0.3, 0.4]
Frame 3: [0.6, 0.2, 0.5]
Frame 4: [0.8, 0.1, 0.6]

Why Custom Implementation is Needed

SwiftUI does not know how to animate:

[CGFloat]

So you define:

How values combine (+)
How they differ (-)
How they scale (scale)

This makes your type animatable.

💡 VectorArithmetic turns your data into a multi-dimensional space that SwiftUI can animate through.

Example 4: Animating a Progress Ring

import SwiftUI

struct ProgressRing: Shape {
    var progress: Double

    var animatableData: Double {
        get { progress }
        set { progress = newValue }
    }

    func path(in rect: CGRect) -> Path {
        var path = Path()

        let endAngle = Angle(degrees: 360 * progress)

        path.addArc(
            center: CGPoint(x: rect.midX, y: rect.midY),
            radius: rect.width / 2,
            startAngle: .degrees(-90),
            endAngle: endAngle - .degrees(90),
            clockwise: false
        )

        return path
    }
}

struct ProgressRingExampleView: View {
    @State private var progress = 0.0

    var body: some View {
        VStack(spacing: 20) {
            ProgressRing(progress: progress)
                .stroke(Color.blue.gradient, lineWidth: 12)
                .frame(width: 150, height: 150)

            Button("Start Animation") {
                progress = 0
                withAnimation(.linear(duration: 2)) {
                    progress = 1.0
                }
            }
        }
        .padding()
    }
}

Output:

SwiftUI interpolates:

0 → 0.2 → 0.4 → 0.6 → 0.8 → 1

Each frame increases the arc angle:

Angle = 360 × progress

💡 The ring is just a visual representation of a single number.

Final Mental Model

All animations follow this pipeline:

State Change
    ↓
withAnimation
    ↓
animatableData
    ↓
Interpolated values
    ↓
View recomputed
    ↓
New frame rendered

Key Takeaways

SwiftUI animations are data-driven
Animatable defines what can interpolate
Each frame recomputes your view
AnimatablePair handles multiple values
VectorArithmetic enables complex animations

Final Thoughts

💡 If SwiftUI can interpolate your data, it can animate your UI.

If you have suggestions, feel free to connect with me on X and send me a DM. If this article helped you, Buy me a coffee.

Swift Algorithms - Apple’s Hidden Collection and Sequence APIs You Should Be Using

Sat, 21 Mar 2026 00:00:00 GMT

Swift’s standard library already gives us strong collection primitives. Yet many developers still write nested loops, temporary buffers, and index math that is harder to read and easier to break.

Apple’s open-source swift-algorithms package fills that gap with focused sequence and collection APIs designed for correctness, clarity, and predictable performance.

Many Swift developers still do not know this package exists, even though it is maintained by Apple and widely used in production Swift code.

In this article, we will learn Swift Algorithms in a practical way and cover these operations:

Combinations
Permutations
Product
Chunked
Chain
Cycle
Unique
Random Sampling
Indexed
Partition
Rotate

Why Swift Algorithms Matters

Swift Algorithms is an incubation package for collection and sequence operations that may later move into the Swift standard library. That means these APIs are explored with real-world feedback first.

In day-to-day development, this package gives three big benefits:

Readability: intent-focused operations replace handwritten control flow.
Correctness: less custom state management means fewer logic traps.
Performance transparency: most APIs document their complexity and constraints clearly.

Add Swift Algorithms to Your Project

Add the package to your Package.swift:

.package(url: "https://github.com/apple/swift-algorithms", from: "1.2.1"),

Then add the product to your target dependencies:

.target(
    name: "AppTarget",
    dependencies: [
        .product(name: "Algorithms", package: "swift-algorithms")
    ]
)

And import it in Swift files where needed:

import Algorithms

1. Combinations

Use combinations(ofCount:) when you need groups and order inside a group does not matter.

The combinations(ofCount:) method returns every different combination of size k.

Each combination keeps the same element order as the original collection.

If a value appears multiple times in the source, each position is treated as a separate element. So repeated looking combinations can appear.

import Algorithms

let users = ["Asha", "Ben", "Chloe", "Diego"]
let pairs = users.combinations(ofCount: 2)

for pair in pairs {
    print(pair)
}

Output:

["Asha", "Ben"]
["Asha", "Chloe"]
["Asha", "Diego"]
["Ben", "Chloe"]
["Ben", "Diego"]
["Chloe", "Diego"]

You can also pass a range like 2...3 to generate combinations of multiple sizes.

import Algorithms

let numbers = [10, 20, 30, 40]
for combo in numbers.combinations(ofCount: 2...3) {
    print(combo)
}

Output:

[10, 20]
[10, 30]
[10, 40]
[20, 30]
[20, 40]
[30, 40]
[10, 20, 30]
[10, 20, 40]
[10, 30, 40]
[20, 30, 40]

Good use cases:

Pair-programming assignments
Team subgroup generation
Feature flag test matrices where order does not matter

Important behavior:

Results follow lexicographic order based on the original collection order.
Duplicate values in the source are treated as distinct positions.

2. Permutations

Use permutations() when order matters.

The permutations() method returns all full permutations.

permutations(ofCount:) returns partial permutations of length k.

Results are produced in lexicographic order based on original element positions.

If the source contains repeated values, they are treated as separate positions. So duplicates can appear.

Use uniquePermutations() when you want only unique outputs.

import Algorithms

let steps = ["Login", "Verify", "Checkout"]
for flow in steps.permutations() {
    print(flow)
}

Output:

["Login", "Verify", "Checkout"]
["Login", "Checkout", "Verify"]
["Verify", "Login", "Checkout"]
["Verify", "Checkout", "Login"]
["Checkout", "Login", "Verify"]
["Checkout", "Verify", "Login"]

Need partial orderings? Use permutations(ofCount:):

for flow in steps.permutations(ofCount: 2) {
    print(flow)
}

Output:

["Login", "Verify"]
["Login", "Checkout"]
["Verify", "Login"]
["Verify", "Checkout"]
["Checkout", "Login"]
["Checkout", "Verify"]

If source values may repeat and you only want unique outputs, use uniquePermutations():

let values = [1, 1, 2]
for p in values.uniquePermutations() {
    print(p)
}

Output:

[1, 1, 2]
[1, 2, 1]
[2, 1, 1]

3. Product

Use product(_:_:) for Cartesian products across two inputs.

It returns every pair made from the first sequence and the second collection.

In simple terms, it behaves like a nested loop: for each element in the first input, iterate all elements in the second input.

The second input must be a Collection because it is traversed many times.

If either input is empty, the result is empty.

import Algorithms

let regions = ["US", "EU", "IN"]
let plans = ["Free", "Pro"]

for (region, plan) in product(regions, plans) {
    print("\(region)-\(plan)")
}

Output:

US-Free
US-Pro
EU-Free
EU-Pro
IN-Free
IN-Pro

You can write nested loops for this, but product is easier to read and reuse.

4. Chunked

Chunking APIs split a collection into consecutive, non-overlapping subsequences.

Unlike split, chunking keeps every original element.

That means joining all chunks gives you back the same collection.

chunked(by:) groups by a relationship between neighboring elements.

chunked(on:) groups by equal projected keys.

chunks(ofCount:) creates fixed-size chunks.

evenlyChunked(in:) creates a fixed number of near-equal chunks.

`chunked(by:)` - split by adjacent relationship

import Algorithms

let readings = [2, 4, 5, 1, 3, 7, 2]
let ascendingRuns = readings.chunked(by: { $0 <= $1 })
print(ascendingRuns.map { Array($0) })

Output:

[[2, 4, 5], [1, 3, 7], [2]]

`chunked(on:)` - split by projected key changes

let names = ["Ava", "Amy", "Brian", "Bella", "Chris"]
let groups = names.chunked(on: { $0.first! })
print(groups.map { ($0.0, Array($0.1)) })

Output:

[("A", ["Ava", "Amy"]), ("B", ["Brian", "Bella"]), ("C", ["Chris"])]

`chunks(ofCount:)` - fixed-size windows

let jobs = Array(1...10)
let batches = jobs.chunks(ofCount: 3)
print(batches.map { Array($0) })

Output:

[[1, 2, 3], [4, 5, 6], [7, 8, 9], [10]]

`evenlyChunked(in:)` - split into N near-even parts

let allItems = Array(0..<15)
let shards = allItems.evenlyChunked(in: 4)
print(shards.map { Array($0) })

Output:

[[0, 1, 2, 3], [4, 5, 6, 7], [8, 9, 10, 11], [12, 13, 14]]

Practical use cases:

Pagination and worker batching
Grouping telemetry by key transitions
Breaking large datasets for parallel processing

5. Chain

Use chain(_:_:) to concatenate two sequences of the same element type without allocating intermediate storage.

It yields every element of the first sequence.

Then it yields every element of the second sequence.

Compared with building arrays and calling joined(), chain avoids unnecessary allocation.

It also works naturally with different underlying sequence types.

import Algorithms

let top = [101, 102, 103]
let rest = 200...202

let allIDs = chain(top, rest)
print(Array(allIDs))

Output:

[101, 102, 103, 200, 201, 202]

Why not [top, Array(rest)].joined()?

chain supports heterogeneous sequence types.
You avoid extra materialization work.
Conditional collection conformances are preserved when possible.

6. Cycle

Cycle APIs repeat a collection’s elements in original order.

Use cycled() for repeating a collection forever, producing an infinite sequence, and cycled(times:) for bounded repetition.

The infinite form is intentionally sequence-only.

An infinite value cannot behave like a practical finite collection.

import Algorithms

for value in ["Red", "Blue"].cycled(times: 3) {
    print(value)
}

Output:

Red
Blue
Red
Blue
Red
Blue

Common patterns:

Repeating UI states in previews
Round-robin assignment simulation
Pattern generation in deterministic test fixtures

7. Unique

Returns a sequence with only the unique elements of this sequence, in the order of the first occurrence of each unique element.

Use uniqued() to remove duplicate elements while preserving first-seen order.

uniqued() uses the element itself as the uniqueness key (for Hashable elements).

uniqued(on:) uses a projected key, such as \.id.

In both cases, the first time a key appears is kept.

Later repeats are dropped.

The relative order of kept elements stays the same.

import Algorithms

let tags = ["swift", "ios", "swift", "performance", "ios"]
let deduped = Array(tags.uniqued())
print(deduped)

Output:

["swift", "ios", "performance"]

Use uniqued(on:) for projection based uniqueness:

struct User {
    let id: Int
    let email: String
}

let users = [
    User(id: 1, email: "a@example.com"),
    User(id: 2, email: "b@example.com"),
    User(id: 1, email: "a2@example.com")
]

let uniqueUsers = users.uniqued(on: \.id)
print(uniqueUsers.map(\.email))

Output:

["a@example.com", "b@example.com"]

8. Random Sampling

Randomly selects the specified number of elements from given collection.

randomSample(count:) returns sampled elements in random order.

randomStableSample(count:) returns sampled elements in the same relative order as the source collection.

If count is greater than the collection size, all elements are returned.

If you need reproducible behavior in tests, use overloads that accept a custom random-number generator.

import Algorithms

let source = Array(1...100)
let sample = source.randomSample(count: 5)
print(sample)

Output (example, changes every run):

[44, 27, 97, 58, 37]

Need order preserved relative to source? Use randomStableSample(count:):

let stable = source.randomStableSample(count: 5)
print(stable)

Output (example, preserves source order):

[28, 33, 44, 62, 75]

To control randomness explicitly, pass your own RandomNumberGenerator:

var rng = SystemRandomNumberGenerator()
let controlledSample = source.randomSample(count: 5, using: &rng)
print(controlledSample)

Output:

[28, 24, 26, 87, 5] //Returns 5 sampled elements using the RandomNumberGenerator you pass in.

9. Indexed

The indexed() method is similar to the standard library’s enumerated() method, but provides the index with each element instead of a zero-based counter.

It returns pairs of (index, element).

Here, index is the actual index type of the collection, not an auto-incrementing Int counter.

This is important for slices and custom collections where true indices carry semantic meaning.

import Algorithms

let array = ["a", "b", "c", "d"]
let slice = array[1...2]   // ["b", "c"]

for (index, value) in slice.indexed() {
    print(index, value)
}

Output:

1 b
2 c

enumerated() always uses an Int counter starting from zero. indexed() pairs each element with its true collection index, which matters for non-zero-based and custom index collections.

10. Partition

Partition APIs help split data into two groups using a predicate.

The standard library already has partition(by:), but it is not stable.

Swift Algorithms adds stable partitioning, subrange partitioning, and partitioningIndex(where:) to locate the split index in already partitioned data.

It also adds partitioned(by:) for a non-mutating tuple of both groups.

`stablePartition(by:)` for mutable collections

import Algorithms

var numbers = [10, 20, 30, 40, 50]
let pivot = numbers.stablePartition(by: { $0.isMultiple(of: 20) })
// left side: elements where predicate is false (original order preserved)
// right side: elements where predicate is true (original order preserved)
print(pivot)
print(numbers)

Output:

3
[10, 30, 50, 20, 40]

`partitioningIndex(where:)` for already partitioned collections

let prepartitioned = [1, 3, 5, 2, 4, 6]
let split = prepartitioned.partitioningIndex(where: { $0.isMultiple(of: 2) })
print(split)

Output:

`partitioned(by:)` for non-mutating tuple output

let words = ["cat", "elephant", "dog", "giraffe"]
let (short, long) = words.partitioned(by: { $0.count > 3 })
print(short)
print(long)

Output:

["cat", "dog"]
["elephant", "giraffe"]

11. Rotate

Use rotate(toStartAt:) to mutate a collection so a chosen index becomes the new start.

rotate(toStartAt:) rotates an entire mutable collection.

rotate(subrange:toStartAt:) rotates only a specific range.

This is useful for in-place reordering and divide-and-conquer algorithms.

Each call returns the index where the old start element moved.

import Algorithms

var queue = [10, 20, 30, 40, 50]
let newIndex = queue.rotate(toStartAt: 2)
// queue == [30, 40, 50, 10, 20]
print(newIndex)
print(queue)

Output:

3
[30, 40, 50, 10, 20]

Range-based rotation is useful in divide-and-conquer style mutations:

var queue = [10, 20, 30, 40, 50]
let newIndex = queue.rotate(toStartAt: 2)
// queue == [30, 40, 50, 10, 20]
queue.rotate(subrange: 0..<3, toStartAt: 1)
print(queue)

Output:

[40, 50, 30, 10, 20]

Standard Library vs Swift Algorithms: When to Choose What

Use standard library APIs when the operation is simple and already expressive:

map, filter, reduce
split when separators should be removed
enumerated when a plain counter is enough

Use Swift Algorithms when a dedicated API makes your intent clearer:

You need combinations or permutations
You need stable/unstable sampling semantics
You need true indices, stable partitioning, or in-place rotation helpers
You want to replace non-obvious loop machinery with named algorithms

Common Pitfalls and How to Avoid Them

Combinatorial explosion: permutations and combinations grow rapidly. Limit ofCount early.
Sequence vs collection assumptions: some APIs require Collection for repeated traversal or count access.
Stable vs unstable semantics: choose sampling/partitioning methods deliberately based on ordering needs.
Index correctness: use indexed() for nontrivial collections where offsets are not true indices.

A Practical Adoption Checklist

Use this checklist when introducing Swift Algorithms in production code:

Start with one module that has algorithm-heavy loops.
Replace custom loops with named APIs only where readability improves.
Keep performance-sensitive paths benchmarked before and after.
Add tests for ordering-sensitive behavior (stable vs unstable results).
Document team conventions for when to prefer package APIs over hand-written loops.

Final Thoughts

Swift Algorithms does not replace the standard library. It extends it with focused APIs for common collection problems.

If your project works heavily with sequences and collections, this package quickly improves readability and reduces loop-level bugs.

Official resources:

If you have suggestions, feel free to connect with me on X and send me a DM. If this article helped you, Buy me a coffee.

Swift some vs any - Understanding Opaque Types and Existential Types

Sat, 14 Mar 2026 00:00:00 GMT

Swift’s type system is designed to provide both strong compile-time guarantees and high runtime performance. One of the key features enabling this balance is Swift’s approach to protocol-based abstraction.

Two keywords that often confuse developers especially when working with protocols and generics are:

some
any

These keywords correspond to two different concepts in Swift’s type system:

Opaque Types (some)
Existential Types (any)

Although both are used with protocols, they represent fundamentally different abstraction models.

Understanding when to use each is important when designing APIs, writing performant code, or working with frameworks like SwiftUI where some View appears everywhere.

In this article we will explore:

What opaque and existential types are
Why Swift introduced some and any
How they differ conceptually
Their performance characteristics
How Swift implements them internally
Best practices for using them in real-world code

The Problem: Protocols as Types

Protocols define behavioral contracts.

For example:

protocol Animal {
    func speak()
}

Types conform to the protocol by implementing its requirements:

struct Dog: Animal {
    func speak() {
        print("Woof")
    }
}

Now suppose we want to return a protocol type from a function:

func makeAnimal() -> Animal {
    Dog()
}

At first glance this seems reasonable. However, Swift’s type system historically struggled with certain protocols - especially those with associatedtype or Self requirements.

For example:

protocol Vehicle {
    associatedtype Fuel
    func refuel(with fuel: Fuel)
}

Because this protocol contains an associated type, Swift cannot determine the concrete type of Fuel when the protocol is used directly.

struct Petrol {}

struct ElectricCharge {}

struct Car: Vehicle {
    func refuel(with fuel: Petrol) {
        print("Car refueled with petrol")
    }
}

struct ElectricCar: Vehicle {
    func refuel(with fuel: ElectricCharge) {
        print("Electric car charging")
    }
}

Now imagine we want a factory function that returns a vehicle.

A first attempt might look like this:

func makeVehicle() -> Vehicle {
    Car()
}

However, this returns compile time warning:

Use of protocol 'Vehicle' as a type must be written 'any Vehicle'; this will be an error in a future Swift language mode

This ambiguity created a need for two different abstraction mechanisms:

A way to return a specific concrete type while hiding its identity
A way to store any value that conforms to a protocol

Swift addresses these needs using:

some → opaque types
any → existential types

Opaque Types (`some`)

What Is an Opaque Type?

An opaque type represents a specific concrete type that conforms to a protocol, but whose identity is hidden from the caller.

The key idea is simple:

The compiler knows the concrete type, but the caller does not.

Example

protocol Shape {
    func area() -> Double
}

struct Circle: Shape {
    let radius: Double

    func area() -> Double {
        .pi * radius * radius
    }
}

struct Square: Shape {
    let size: Double

    func area() -> Double {
        size * size
    }
}

func makeShape() -> some Shape {
    Circle(radius: 10)
}

Here:

makeShape() returns a concrete type (Circle)
The caller only knows that the return type conforms to Shape
The underlying type is hidden

Usage:

let shape = makeShape()
print(shape.area())

Even though the caller sees Shape, the compiler still knows the returned type is Circle.

Why Opaque Types Matter

Opaque types allow you to hide implementation details while preserving static type information.

This has two major advantages.

API Stability

If you expose a concrete type:

func makeShape() -> Circle

Your API becomes tightly coupled to the implementation.

Instead you can write:

func makeShape() -> some Shape

This allows you to change the underlying type later without breaking callers.

Performance

Because the compiler still knows the exact type, Swift can perform powerful optimizations:

Static dispatch
Function inlining
Compile-time specialization

As a result, opaque types have almost zero runtime overhead.

Important Rule of Opaque Types

A function returning some Protocol must return the same concrete type in every return path.

This will not compile:

func makeShape(flag: Bool) -> some Shape {
    if flag {
        return Circle(radius: 10)
    } else {
        return Square(size: 10) // ❌ compile error
    }
}

Compile time error:

Function declares an opaque return type 'some Shape', but the return statements in its body do not have matching underlying types

Why?

Because some Shape means:

There exists one specific concrete type, but its identity is hidden.

Allowing multiple types would violate that guarantee.

Real-World Example: SwiftUI

SwiftUI relies heavily on opaque types.

You will frequently see this declaration:

var body: some View

Example:

struct ContentView: View {
    var body: some View {
        Text("Hello")
    }
}

Although it appears that body returns View, Swift actually generates a concrete view type behind the scenes.

Opaque types allow SwiftUI to:

avoid expensive type erasure
maintain compile-time safety
generate highly optimized view hierarchies

Existential Types (`any`)

What Is an Existential Type?

An existential type represents a container that can hold any value conforming to a protocol.

Unlike opaque types, the underlying type may vary at runtime.

Existential types are written using the any keyword.

Example

protocol Animal {
    func speak()
}

struct Dog: Animal {
    func speak() {
        print("Woof")
    }
}

struct Cat: Animal {
    func speak() {
        print("Meow")
    }
}

Now consider a function that returns a random animal:

func randomAnimal() -> any Animal {
    Bool.random() ? Dog() : Cat()
}

Usage:

let animal = randomAnimal()
animal.speak()

Here the variable animal might contain:

a Dog
a Cat

The concrete type is determined at runtime.

How Existential Types Work Internally

To understand the cost of existential types, it helps to look at how Swift represents them internally.

When you write:

let animal: any Animal = Dog()

Swift creates an existential container.

Conceptually, this container stores three pieces of information:

Existential Container
 ├─ Value
 ├─ Type Metadata
 └─ Witness Table

Stored Value

The container stores the concrete value (Dog in this case).

Small values may be stored directly in the container, while larger values may be allocated on the heap.

Type Metadata

Swift stores metadata describing the underlying type.

This allows the runtime to know things like:

the size of the value
alignment requirements
how to copy or destroy it

Witness Table

The witness table is what enables dynamic protocol dispatch.

A witness table contains function pointers that implement the protocol requirements for a specific type.

Conceptually:

Animal Witness Table for Dog
 └─ speak → Dog.speak()

When Swift executes:

animal.speak()

It performs the following steps:

Look up the witness table inside the existential container
Find the function pointer for speak
Call the correct implementation

This is known as dynamic dispatch via witness tables.

Performance Comparison: Generics vs `some` vs `any`

Swift supports three different abstraction mechanisms:

Generics
Opaque types (some)
Existential types (any)

Although they look similar in code, they behave differently at the compiler level.

Generics

Example:

func process<T: Shape>(_ shape: T) {
    print(shape.area())
}

The compiler specializes this function for each concrete type.

Advantages:

Full compile-time knowledge
Static dispatch
Maximum performance

Opaque Types

Example:

func makeShape() -> some Shape {
    Circle(radius: 10)
}

Opaque types behave similarly to generics internally because the compiler still knows the underlying type.

Advantages:

Encapsulation of implementation
Static dispatch
Zero runtime overhead

Existential Types

Example:

func process(_ shape: any Shape) {
    print(shape.area())
}

Here the concrete type is unknown at compile time, so Swift must use runtime polymorphism.

This introduces:

existential containers
witness table lookups
dynamic dispatch

Conceptual Performance Comparison

Abstraction	Dispatch	Runtime Cost	Typical Use
Generics	Static	None	Algorithms
`some`	Static	None	Returning protocol types
`any`	Dynamic	Small overhead	Heterogeneous storage

When Should You Use Each?

Prefer Generics

When writing reusable algorithms.

func process<T: Shape>(_ shape: T)

Prefer `some`

When returning protocol types while hiding implementation details.

func makeView() -> some View

Use `any` When Necessary

When storing heterogeneous values or working with runtime polymorphism.

var animals: [any Animal] = [
    Dog(),
    Cat()
]

A Simple Mental Model

A useful rule of thumb:

some means

One specific concrete type exists, but it is hidden.

any means

This value may contain any type that conforms to the protocol.

Conclusion

Swift introduced some and any to make protocol abstraction more explicit and more efficient.

They represent two different design trade-offs:

Opaque types (some) hide a concrete type while preserving compile-time optimizations.
Existential types (any) allow dynamic polymorphism by storing values of multiple conforming types.

As a practical guideline:

Prefer generics for reusable algorithms.
Prefer some for return types.
Use any only when dynamic behavior is truly required.

Understanding this distinction helps you design better APIs, write more efficient Swift code, and reason more clearly about how Swift’s type system works.

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 ☕️

Thread Safety in Swift - Preventing Data Races with Locks, Queues, and Actors

Sat, 07 Mar 2026 00:00:00 GMT

Modern applications rarely execute on a single thread. Networking, background processing, UI updates, and database operations often run concurrently to keep applications responsive and performant.

While concurrency improves performance, it also introduces a new class of bugs that can be difficult to detect and reproduce: data races.

Swift provides powerful tools for concurrency, but to build reliable concurrent applications, developers must understand thread safety — how to ensure code behaves correctly when accessed from multiple threads simultaneously.

In this article, we will explore:

What thread safety means
Why thread safety matters
How data races occur
Techniques for achieving thread safety in Swift
How Swift’s modern concurrency model improves safety

By the end, you will have a strong conceptual foundation for designing safe concurrent systems in Swift.

What Is Thread Safety?

A piece of code is thread-safe if it behaves correctly when accessed by multiple threads at the same time.

In other words:

Multiple threads can read or modify shared data without causing inconsistent results or crashes.

Thread safety becomes important when dealing with shared mutable state.

Consider the following example:

class Counter {
    var value: Int = 0

    func increment() {
        value += 1
    }
}

This code appears harmless. However, if multiple threads call increment() simultaneously, the result may become incorrect.

The reason is that value += 1 is not an atomic operation. It actually consists of multiple steps:

Read the current value
Add one
Write the new value back

If two threads perform these steps concurrently, updates may be lost.

Why Thread Safety Matters?

Without proper synchronization, concurrent code can lead to several problems.

Data Races

A data race occurs when:

Two or more threads access the same memory location
At least one access is a write
The accesses are not synchronized

When this happens, the final result may become unpredictable.

Consider the following example:

class Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

Now imagine multiple threads calling increment() at the same time:

let counter = Counter()
let group = DispatchGroup()

for _ in 0..<1000 {
    group.enter()

    DispatchQueue.global().async {
        counter.increment()
        group.leave()
    }
}

group.wait()

print(counter.value)

Intuitively, we might expect the output to always be:

However, when you run this code multiple times, you may see results like:

941
876
997

The result varies because multiple threads are modifying the same value concurrently.

Crashes

Many Swift types, including collections like Array and Dictionary, are not safe for concurrent mutation.

Consider the following example:

var numbers: [Int] = []
let group = DispatchGroup()

for i in 0..<10000 {
    group.enter()

    DispatchQueue.global().async {
        numbers.append(i)
        group.leave()
    }
}

group.wait()

print(numbers.count)

At first glance, we might expect the final count to always be:

However, because multiple threads are mutating the same array concurrently, the result may become unpredictable.

Possible outcomes include:

9831
9974
10000

Or in some cases the program may crash with errors such as:

Swift/UnsafePointer.swift:1104: Fatal error: UnsafeMutablePointer.initialize overlapping range

signal SIGABRT

EXC_BAD_ACCESS

Concurrent modification of collections can lead to memory corruption and crashes.

Inconsistent State

Shared objects can become partially updated when multiple threads modify them simultaneously.

Example:

class BankAccount {
    var balance: Int = 0
}

If two threads update balance at the same time, the final value may be incorrect.

Common Sources of Thread Safety Issues

Thread safety issues usually arise when mutable state is shared across threads.

Typical examples include:

Shared arrays or dictionaries
Global variables
Singleton objects
Shared caches
Mutable properties inside classes

Example:

class Logger {

    var logs: [String] = []

    func add(_ message: String) {
        logs.append(message)
    }
}

let logger = Logger()

DispatchQueue.concurrentPerform(iterations: 5) { i in
    logger.add("Log \(i)")
}

print("Expected logs:", 5)
print("Actual logs:", logger.logs.count)

Output:

Expected logs: 5
Actual logs: 4

If multiple threads call add() concurrently, the underlying array may become corrupted.

Strategies for Achieving Thread Safety

There are several techniques developers use to write thread-safe code in Swift.

The most common approaches include:

Avoid shared mutable state
Use serial dispatch queues
Use locks
Use actors
Prefer immutable data

Each technique offers different trade-offs in complexity, safety, and performance.

Avoid Shared Mutable State

The simplest way to achieve thread safety is to avoid shared mutable state entirely.

Instead of sharing mutable objects between threads, pass copies of data.

Example:

struct User {
    let name: String
    let age: Int
}

Since the properties are immutable, multiple threads can safely read them without synchronization.

Swift’s value types encourage this pattern.

Using Serial Dispatch Queues

A common approach to protecting shared state is using a serial dispatch queue.

A serial queue ensures that tasks execute one at a time, preventing simultaneous access.

Example:

class SafeCounter {

    private var value = 0
    private let queue = DispatchQueue(label: "counter.queue")

    func increment() {
        queue.sync {
            value += 1
        }
    }

    func getValue() -> Int {
        queue.sync {
            value
        }
    }
}

let counter = SafeCounter()
let group = DispatchGroup()

let iterations = 10000

for _ in 0..<iterations {
    group.enter()

    DispatchQueue.global().async {
        counter.increment()
        group.leave()
    }
}

group.wait()

print("Expected:", iterations)
print("Actual:", counter.getValue())

Output:

Expected: 10000
Actual: 10000

All access to value occurs on the same queue, guaranteeing mutual exclusion.

Advantages:

Simple and easy to reason about
No manual lock management

Drawbacks:

Blocking calls (sync) may affect performance if overused

Using Locks

Another common technique is protecting critical sections with locks.

Locks ensure that only one thread can access a specific piece of code at a time.

Example using NSLock:

class SafeCounter {

    private var value = 0
    private let lock = NSLock()

    func increment() {
        lock.lock()
        value += 1
        lock.unlock()
    }

    func getValue() -> Int {
        lock.lock()
        defer { lock.unlock() }
        return value
    }
}

let counter = SafeCounter()
let group = DispatchGroup()

let iterations = 10000

for _ in 0..<iterations {
    group.enter()

    DispatchQueue.global().async {
        counter.increment()
        group.leave()
    }
}

group.wait()

print("Expected:", iterations)
print("Actual:", counter.getValue())

Output:

Expected: 10000
Actual: 10000

The lock ensures that concurrent threads cannot modify value simultaneously.

Advantages:

Efficient and low-level control
Minimal overhead

Drawbacks:

Easy to misuse
Risk of deadlocks if locks are not managed carefully

Using Actors for Thread Safety

Actors are a concurrency feature introduced in Swift 5.5 to simplify thread-safe programming.

An actor protects its internal state by ensuring only one task can access it at a time.

Example:

actor Counter {

    private var value = 0

    func increment() {
        value += 1
    }

    func getValue() -> Int {
        value
    }
}

Using the actor:

let counter = Counter()

Task {
    await counter.increment()
}

The await keyword indicates asynchronous interaction with the actor.

Swift guarantees that access to the actor’s internal state is serialized, preventing concurrent mutations.

Immutable Data

Immutable data structures are inherently thread-safe.

let numbers = [1,2,3,4]

Since the array is never mutated, multiple threads can read it safely.

Many functional programming patterns rely heavily on immutability.

Comparing Approaches

Technique	Safety	Complexity	Performance
Avoid shared state	Very high	Low	High
Serial queues	High	Low	Moderate
Locks	Medium	Medium	High
Actors	Very high	Low	High
Immutable data	Very high	Low	High

Detecting Thread Safety Issues

Xcode provides a powerful tool called Thread Sanitizer that helps detect concurrency bugs.

You can enable it in:

Scheme → Diagnostics → Thread Sanitizer

Thread Sanitizer detects:

Data races
Unsafe concurrent memory access
Synchronization issues

Running your application with this tool can help identify problems that are difficult to reproduce.

Best Practices for Writing Thread-Safe Swift Code

Prefer value types and immutable data
Avoid shared mutable state whenever possible
Use actors for shared state in modern Swift
Use serial queues when actors are not appropriate
Be cautious with locks
Use Thread Sanitizer during development

These practices help reduce the complexity of concurrent programming.

Final Thoughts

Concurrency is essential for modern applications, but it introduces significant complexity.

Traditional techniques rely on protecting shared mutable state using synchronization primitives like locks and queues.

Swift’s modern concurrency model takes a different approach by encouraging data isolation.

Actors combine:

isolated state
asynchronous messaging
serialized execution

This design dramatically reduces the risk of data races and makes concurrent code easier to reason about.

By combining good design principles, immutability, and Swift’s concurrency tools, developers can build applications that scale safely across multiple threads.

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 ☕️

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

associatedtype in Swift Explained - A Complete Guide with SwiftUI Examples

What is associatedtype?

Basic Example

Why This Matters

associatedtype vs Generics

Generics

Associated Types

Mental Model

Concrete Example

Without associatedtype

With associatedtype

Conforming Types

Explicit Type Binding

Associated Types in the Standard Library

Adding Constraints

Implementation

Conditional Behavior with where

Why associatedtype Matters in SwiftUI

The View Protocol

Why Not var body: View?

Instead

The Problem: “Why can’t I write [View]?”

What’s Really Happening

The Solution: Type Erasure (AnyView)

What AnyView Does

Trade-offs

Better Patterns

Advanced Pattern: associatedtype + ViewModel

Protocol Definition

Why This Matters

Example

What You Gain

SwiftUI Integration

Using any ViewModel

But There’s a Catch (Important)

What You Can and Cannot Do

When any ViewModel Makes Sense

When It Breaks Down

Production Patterns

1. Generic Views

2. Constrained State

3. ObservableObject Integration

4. Type Erasure for ViewModels

5. Enum Based State

Key Takeaways

Final Thoughts

Lazy Properties in Swift - Why They Don’t Always Work in SwiftUI

What is a Lazy Property?

Key Idea

Why Lazy Properties Matter

1. Avoid Unnecessary Work

2. Improve Performance and Startup Time

3. Enable Self-Dependent Initialization

How Lazy Properties Work

Syntax Variations

Simple Lazy Property

Lazy Property with Closure

Lazy Property Using a Function

Rules and Characteristics

Must Be Declared with var

Only Stored Properties Can Be Lazy

Initialized Only Once

Not Thread-Safe by Default

Real-World Use Cases (SwiftUI + Production Guidance)

1. Expensive Object Creation

2. Deferring Heavy View Construction

3. Dependency-Based Initialization

4. Caching Computed Results

Lazy vs Computed Properties

Common Pitfalls

Retain Cycles

Hidden Performance Cost

Thread Safety

Best Practices

When NOT to Use Lazy

Opinionated Guidelines (Production)

Use lazy when:

Avoid lazy when:

Final Thoughts

What is `associatedtype`?

`associatedtype` vs Generics

Without `associatedtype`

With `associatedtype`

Conditional Behavior with `where`

Why `associatedtype` Matters in SwiftUI

The `View` Protocol

Why Not `var body: View`?

The Problem: “Why can’t I write `[View]`?”

The Solution: Type Erasure (`AnyView`)

What `AnyView` Does

Advanced Pattern: `associatedtype` + ViewModel

Using `any ViewModel`

When `any ViewModel` Makes Sense

3. `ObservableObject` Integration

Must Be Declared with `var`

The `withLock` Method

What is `Animatable`?

Why Does `Animatable` Matter?

How SwiftUI Uses `Animatable`

Conforming to `Animatable`

Using `@Animatable` and `@AnimatableIgnored` Macros

`@Animatable`

`@AnimatableIgnored`

What is `animatableData`?

Why Does `animatableData` Exist?

How SwiftUI Uses `animatableData`

What Happens If You Remove `animatableData`?

Example 2: Animating Multiple Values with `AnimatablePair`

What is `AnimatablePair`?

Why Does `AnimatablePair` Exist?

How SwiftUI Uses `AnimatablePair`

Example 3: Animating Complex Data with `VectorArithmetic`

What is `VectorArithmetic`?

Why Does SwiftUI Require `VectorArithmetic`?

`chunked(by:)` - split by adjacent relationship

`chunked(on:)` - split by projected key changes

`chunks(ofCount:)` - fixed-size windows

`evenlyChunked(in:)` - split into N near-even parts

`stablePartition(by:)` for mutable collections

`partitioningIndex(where:)` for already partitioned collections

`partitioned(by:)` for non-mutating tuple output

Opaque Types (`some`)