DEV Community: Sebastien Lato

SwiftUI Rate Limiting & Backpressure (Protect Your Backend From Your Own App)

Sebastien Lato — Sun, 08 Mar 2026 17:13:44 +0000

Most apps call APIs like this:

try await api.fetchFeed()

That works…

until something triggers many requests at once.

Examples:

infinite refresh loops
aggressive background sync
multiple views requesting the same data
retry storms after network recovery
multiple devices syncing simultaneously

Suddenly your app becomes the biggest threat to your own backend.

This post shows how to implement rate limiting and backpressure in SwiftUI so your networking layer is:

backend-safe
quota-aware
retry-friendly
battery-conscious
production-grade

🧠 The Core Principle

A healthy system controls its request rate.

Even when everything is working, uncontrolled traffic can overload APIs.

🧱 1. What Is Rate Limiting?

Rate limiting controls how many requests can occur during a time window.

Example rule:

10 requests per second

If more requests arrive, they must:

wait
queue
or be rejected

This protects both:

the backend
the client device

🧬 2. Token Bucket Model

A common approach is the token bucket algorithm.

Concept:

Bucket contains tokens
Each request consumes one token
Tokens refill over time

If the bucket is empty:

Request must wait

🧱 3. Simple Rate Limiter Implementation

actor RateLimiter {

    private let maxTokens: Int
    private let refillInterval: TimeInterval

    private var tokens: Int
    private var lastRefill: Date

    init(maxTokens: Int, refillInterval: TimeInterval) {
        self.maxTokens = maxTokens
        self.refillInterval = refillInterval
        self.tokens = maxTokens
        self.lastRefill = Date()
    }

    func acquire() async {
        refill()

        while tokens == 0 {
            try? await Task.sleep(nanoseconds: 100_000_000)
            refill()
        }

        tokens -= 1
    }

    private func refill() {
        let now = Date()
        let elapsed = now.timeIntervalSince(lastRefill)

        if elapsed >= refillInterval {
            tokens = maxTokens
            lastRefill = now
        }
    }
}

This ensures requests happen at a controlled pace.

🚦 4. Using the Rate Limiter

Wrap your API calls:

let limiter = RateLimiter(maxTokens: 5, refillInterval: 1)

func fetchFeed() async throws -> Feed {

    await limiter.acquire()

    return try await api.fetchFeed()
}

Now your app cannot exceed 5 requests per second.

🔄 5. What Is Backpressure?

Backpressure prevents systems from producing more work than they can handle.

Example scenario:

Scroll view triggers 50 image loads

Without backpressure:

50 network requests instantly

With backpressure:

Requests queue and execute gradually

This protects:

CPU
memory
network
backend APIs

📦 6. Request Queue Pattern

Queue requests instead of executing immediately.

actor RequestQueue {

    private var queue: [() async -> Void] = []

    func enqueue(_ task: @escaping () async -> Void) {
        queue.append(task)
        processNext()
    }

    private func processNext() {
        guard !queue.isEmpty else { return }

        let task = queue.removeFirst()

        Task {
            await task()
            processNext()
        }
    }
}

This ensures controlled execution.

🔋 7. Why Mobile Apps Need Rate Limiting

Mobile environments are unpredictable.

Common issues:

API quotas
slow cellular connections
background sync bursts
multi-tab refresh loops

Without limits:

the backend gets flooded
battery drains faster
UI becomes unstable

Rate limiting stabilizes the system.

🌐 8. Combine With Circuit Breakers

From the previous post:

Circuit Breakers → stop requests during failures
Rate Limiting → control requests during success

Together they form complete network resilience.

🧪 9. Testing Rate Limiting

Test scenarios:

rapid refresh loops
large scroll lists triggering network calls
background sync bursts
retry storms

Verify that:

request rate remains stable
the queue processes correctly
no backend overload occurs

⚠️ 10. Common Anti-Patterns

Avoid:

unlimited parallel requests
retrying immediately after failure
per-view network calls without coordination
ignoring server rate limits
not deduplicating identical requests

These cause:

request storms
API bans
battery drain
backend instability

🧠 Mental Model

Think:

User Action
 → Request Queue
   → Rate Limiter
     → Network Request
       → API

Not:

“Fire every request immediately.”

🚀 Final Thoughts

Rate limiting and backpressure give your app:

predictable network behavior
backend protection
smoother performance
better battery usage
production-grade resilience

This is the difference between:

an app that overwhelms its backend
and a system that scales safely

SwiftUI Circuit Breakers & Network Resilience Patterns (Prevent Cascading Failures)

Sebastien Lato — Sat, 07 Mar 2026 20:48:10 +0000

Most apps call APIs like this:

try await api.fetchUser()

That works…

until the server starts failing.

Then your app does this:

retries immediately
sends hundreds of failing requests
drains battery
overloads the backend
slows down the UI
worsens the outage

This is called a cascading failure.

A production app needs protection mechanisms.

This post shows how to implement circuit breakers and network resilience patterns in SwiftUI that are:

failure-aware
backend-friendly
battery-conscious
retry-safe
production-grade

🧠 The Core Principle

When a system is failing, stop making it worse.

Instead of retrying endlessly, the system must detect failures and pause requests.

🧱 1. What Is a Circuit Breaker?

A circuit breaker prevents repeated calls to a failing service.

It has three states:

Closed → Normal operation
Open → Requests blocked
Half-Open → Testing recovery

Flow:

Requests Fail
→ Circuit Opens
→ Requests Blocked
→ Recovery Test
→ Circuit Closes

🔌 2. Define Circuit States

enum CircuitState {
    case closed
    case open(until: Date)
    case halfOpen
}

Meaning:

Closed → requests allowed
Open → requests blocked temporarily
Half-open → allow limited requests to test recovery

🧬 3. Basic Circuit Breaker Implementation

final class CircuitBreaker {

    private(set) var state: CircuitState = .closed
    private var failureCount = 0
    private let failureThreshold = 5
    private let timeout: TimeInterval = 30

    func recordFailure() {
        failureCount += 1

        if failureCount >= failureThreshold {
            state = .open(until: Date().addingTimeInterval(timeout))
        }
    }

    func recordSuccess() {
        failureCount = 0
        state = .closed
    }
}

Failures accumulate until the circuit opens.

🚦 4. Blocking Requests When Circuit Is Open

Before performing a request:

func canExecute() -> Bool {
    switch state {
    case .closed:
        return true

    case .open(let until):
        return Date() > until

    case .halfOpen:
        return true
    }
}

Usage:

guard breaker.canExecute() else {
    throw NetworkError.circuitOpen
}

This protects the backend.

🔄 5. Transition to Half-Open

When timeout expires:

case .open(let until):
    if Date() > until {
        state = .halfOpen
        return true
    }

Only a small number of requests should test recovery.

If they succeed → close circuit.

If they fail → reopen.

🔋 6. Why Mobile Apps Need Circuit Breakers

Mobile networks are unstable.

Common failure scenarios:

server outage
DNS issues
TLS failures
rate limiting
cellular packet loss

Without circuit breakers:

your app spams the backend
battery drains rapidly
retries amplify the outage

Circuit breakers prevent this.

🧱 7. Integrating with API Clients

Wrap network calls:

func performRequest<T>(_ operation: () async throws -> T) async throws -> T {

    guard breaker.canExecute() else {
        throw NetworkError.circuitOpen
    }

    do {
        let result = try await operation()
        breaker.recordSuccess()
        return result
    } catch {
        breaker.recordFailure()
        throw error
    }
}

This makes resilience automatic.

🌐 8. Combine with Retry Strategies

Circuit breakers work with retries.

Example flow:

Request
→ Failure
→ Retry (exponential backoff)
→ Failure threshold reached
→ Circuit opens
→ Requests paused

This prevents retry storms.

🧪 9. Testing Circuit Breakers

Test scenarios:

repeated server errors
timeout storms
network disconnections
recovery after outage
half-open transition

Verify that:

requests stop during outages
requests resume after recovery

⚠️ 10. Common Anti-Patterns

Avoid:

infinite retries
retrying immediately after failure
ignoring server rate limits
retrying while offline
not tracking failure counts

These cause:

backend overload
cascading outages
battery drain

🧠 Mental Model

Think:

Request
 → Failure Detection
   → Circuit Breaker
     → Pause Requests
       → Recovery Probe
         → Resume Traffic

Not:

“Just retry again.”

🚀 Final Thoughts

Circuit breakers give your app:

backend protection
smarter retry behavior
reduced battery usage
resilience during outages
predictable recovery

This is the difference between:

a fragile network client
and a production-grade mobile system

SwiftUI Soft Deletes & Data Lifecycle Policies (Designing for Recovery, Compliance & Trust)

Sebastien Lato — Sat, 28 Feb 2026 20:24:27 +0000

Most apps delete data like this:

context.delete(item)

That works…

until you need:

undo after app relaunch
sync reconciliation
audit trails
regulatory compliance (GDPR, retention policies)
multi-device recovery
accidental deletion protection
staged data removal

At that point, hard deletes become one of the most dangerous operations in your app.

This post shows how to design soft deletes and data lifecycle policies in SwiftUI that are:

recoverable
compliant
sync-safe
user-friendly
production-grade

🧠 The Core Principle

Deletion is a state — not an action.

Data should transition through lifecycle stages, not disappear instantly.

🧱 1. Hard Delete vs Soft Delete

Hard delete:

database.remove(item)

Soft delete:

item.deletedAt = Date()

Soft delete preserves:

history
undo capability
sync correctness

🧬 2. Model Deletion as State

struct Todo: Identifiable, Codable {
    let id: UUID
    var title: String
    var deletedAt: Date?
}

Active item:

deletedAt == nil

Deleted item:

deletedAt != nil

Deletion becomes a state transition.

🔁 3. Why Soft Deletes Matter in Sync Systems

Without soft deletes:

deletion may not sync correctly
remote devices may resurrect items
conflicts become ambiguous

With soft deletes:

deletion propagates like any update
reconciliation is deterministic
restores are possible

🧱 4. Querying Active Data

Never filter in UI.

Centralize logic:

func activeTodos() -> [Todo] {
    todos.filter { $0.deletedAt == nil }
}

Prevents accidental display of deleted items.

🔄 5. Undo & Restore Flows

Soft delete enables recovery:

func restore(_ item: inout Todo) {
    item.deletedAt = nil
}

This allows:

undo after crash
multi-device restore
user trust

⚖️ 6. Data Retention Policies

Not all deleted data should live forever.

Example lifecycle:

Active → Soft Deleted → Archived → Permanently Deleted

Model:

enum DataLifecycleState {
    case active
    case deleted(Date)
    case archived(Date)
}

This enables:

retention compliance
storage optimization
legal requirements

🌐 7. Soft Deletes & Multi-Device Sync

Scenario:

Device A deletes item
Device B edits item offline

With soft deletes:

conflict is detectable
resolution policy is clear

Without soft deletes:

item may reappear
state becomes inconsistent

🧪 8. Testing Deletion Safety

Test scenarios:

delete → restore → sync
delete on one device, edit on another
migration with deleted data
background sync of deletions
retention policy execution

Deletion bugs destroy trust.

⚠️ 9. Common Anti-Patterns

Avoid:

immediate hard deletes
filtering deleted items only in UI
losing deletion timestamps
not syncing deletion state
permanent deletion without retention window

These lead to:

ghost data
data loss
inconsistent sync
compliance risks

🧠 Mental Model

Think:

Active
 → Soft Deleted
   → Archived
     → Purged

Not:

“Delete and forget.”

🚀 Final Thoughts

Soft deletes and lifecycle policies give you:

safer user experience
reliable sync
compliance readiness
recovery from mistakes
long-term data trust

This is the difference between:

fragile deletion
and responsible data stewardship

SwiftUI Event Sourcing Lite (Audit Trails Without the Complexity)

Sebastien Lato — Thu, 26 Feb 2026 14:12:39 +0000

Most apps store state like this:

user.name = "Alice"

That works…

until you need:

audit trails
debugging production issues
undo beyond a single session
sync conflict investigation
regulatory compliance
“how did we get here?” answers

At that point, storing only the latest state becomes a liability.

This post shows how to implement Event Sourcing Lite in SwiftUI — a practical approach that gives you:

history tracking
reproducible state
better debugging
safer sync reconciliation
production-grade observability

Without the complexity of full event-sourced systems.

🧠 The Core Principle

State is a result of events — not a single snapshot.

If you only store the final state, you lose the story.

🧱 1. Snapshot vs Event-Based Storage

Traditional model:

User {
  id
  name
}

Event-based model:

UserCreated
UserNameUpdated
UserDeleted

Current state = replay of events.

🧬 2. What Is Event Sourcing Lite?

Full event sourcing replaces your database.

Event Sourcing Lite:

keeps your normal database
adds an append-only event log
records meaningful changes

You get traceability without rewriting your app.

📦 3. Define Domain Events

enum UserEvent: Codable {
    case created(id: UUID, name: String)
    case nameUpdated(id: UUID, newName: String)
    case deleted(id: UUID)
}

Events represent facts, not commands.

🧱 4. Event Store (Append-Only)

final class EventStore {
    func append(_ event: UserEvent) {
        // persist to database
    }

    func loadEvents() -> [UserEvent] {
        // fetch events
    }
}

Rules:

never update events
never delete events
append only

History must be immutable.

🔄 5. Rebuilding State from Events

func rebuildUserState(from events: [UserEvent]) -> User? {
    var user: User?

    for event in events {
        switch event {
        case let .created(id, name):
            user = User(id: id, name: name)
        case let .nameUpdated(_, newName):
            user?.name = newName
        case .deleted:
            user = nil
        }
    }

    return user
}

This enables:

debugging
consistency checks
migration recovery

🔁 6. Why This Helps Sync & Conflict Resolution

With events:

you can replay changes
you can merge event streams
conflicts become visible

Instead of:

“The state is wrong and we don’t know why.”

You can answer:

“This event caused the divergence.”

🧪 7. Debugging Production Issues

When a bug report arrives:

“My data disappeared.”

With event logs you can:

inspect event timeline
identify faulty updates
reproduce the state locally

Without logs, you’re guessing.

🧱 8. Event Sourcing Lite + Idempotency

Events must be idempotent.

Attach operation IDs:

struct EventEnvelope<Event: Codable>: Codable {
    let id: UUID
    let event: Event
    let timestamp: Date
}

Prevents duplicate event replay.

⚠️ 9. When NOT to Use Event Sourcing Lite

Avoid for:

trivial apps
ephemeral data
UI-only state
high-frequency telemetry

Use it for:

user data
financial operations
collaborative edits
audit requirements

⚠️ 10. Common Anti-Patterns

Avoid:

storing events without timestamps
mutating past events
logging UI noise instead of domain events
replaying events without idempotency
mixing commands with events

Events are facts — not intentions.

🧠 Mental Model

Think:

User Action
 → Domain Event
   → Append-Only Log
     → State Projection
       → UI

Not:

“Just overwrite the record.”

🚀 Final Thoughts

Event Sourcing Lite gives you:

audit trails
reproducible bugs
safer migrations
clearer sync reconciliation
long-term data trust

This is the difference between:

guessing what happened
and knowing exactly why

SwiftUI Idempotency & Duplicate Prevention (Correctness in Distributed Systems)

Sebastien Lato — Fri, 13 Feb 2026 18:10:52 +0000

Most apps assume actions happen once:

submitOrder()

That works…

until you introduce:

retries after network failure
background sync
offline queues
app relaunch recovery
migration reprocessing
slow server responses
user double taps

At that point, duplicate operations become one of the most dangerous bugs in your app.

This post shows how to design idempotent systems in SwiftUI that are:

safe to retry
duplicate-proof
crash-resilient
sync-friendly
production-grade

🧠 The Core Principle

Retrying an operation must not change the result.

If running an action twice creates a different outcome, your system is fragile.

🧱 1. What Is Idempotency?

An operation is idempotent if running it multiple times has the same effect as running it once.

Safe:

deleteItem(id)

Running twice → item is still deleted.

Unsafe:

createOrder()

Running twice → two orders created.

⚠️ 2. Why Mobile Apps Need Idempotency

Mobile environments guarantee retries:

network timeouts trigger retries
background tasks may run twice
app relaunch replays queued operations
sync engines retry failed operations
users double tap buttons

Without idempotency, you get:

duplicate charges
duplicated messages
corrupted state
inconsistent sync

🧬 3. Attach an Operation ID to Every Mutation

Every mutation must have a stable identity.

struct OperationID: Hashable, Codable {
    let value: UUID
}

Example operation:

struct CreateOrderOperation {
    let id: OperationID
    let payload: OrderPayload
}

The ID travels through:

local queue
network request
server processing
reconciliation

🌐 4. Server-Side Idempotency Keys

Send the operation ID with requests:

POST /orders
Idempotency-Key: 8F6C-1234-ABCD

Server logic:

if key is new → process
if key exists → return previous result

This guarantees safe retries.

📦 5. Local Deduplication Layer

Prevent duplicate execution locally.

final class OperationDeduplicator {
    private var processed: Set<OperationID> = []

    func shouldProcess(_ id: OperationID) -> Bool {
        processed.insert(id).inserted
    }
}

Usage:

guard deduplicator.shouldProcess(op.id) else { return }

Persist processed IDs for crash safety.

🔁 6. Idempotency in Sync Queues

With idempotency:

retries are safe
crash recovery is safe
migrations can replay operations
background sync won’t duplicate

Without it, retries corrupt data.

🧱 7. Designing Idempotent APIs

Prefer operations that include identity.

Bad:

POST /cart/items

Better:

PUT /cart/items/{itemID}

PUT is idempotent by design.

🔄 8. Handling Partial Failures

Network failure after server success is common.

Without idempotency:

retry creates duplicate

With idempotency:

retry returns existing result

Your system becomes self-healing.

⚠️ 9. Common Anti-Patterns

Avoid:

relying on timestamps for uniqueness
generating IDs on retry
storing processed IDs only in memory
assuming requests run once
not propagating IDs to server

These lead to:

duplicate charges
duplicated records
unrecoverable inconsistencies

🧪 10. Testing Idempotency

Test scenarios:

retry same operation 10×
crash before response received
replay queue after migration
simulate slow server responses
double-tap user actions

If your system survives these, it’s robust.

🧠 Mental Model

Think:

User Action
 → Operation ID
   → Persistent Queue
     → Retry
       → Server Deduplication
         → Consistent Result

Not:

“This request will only run once.”

🚀 Final Thoughts

Idempotency gives you:

safe retries
reliable sync
crash resilience
duplicate prevention
consistent distributed systems

This is the difference between:

a fragile mobile client
and a production-grade system

SwiftUI Data Migration & Schema Evolution (Safe Upgrades Without Data Loss)

Sebastien Lato — Thu, 12 Feb 2026 23:24:28 +0000

Most apps ship updates like this:

UserDefaults.standard.set(true, forKey: "newFlag")

That works…

until you need:

database schema changes
new required fields
offline data preservation
sync queue compatibility
multi-version clients in the wild
rollback safety
tenant-specific migrations

At that point, data migration becomes one of the riskiest parts of your app.

This post shows how to design a migration system in SwiftUI that is:

safe
deterministic
backward-compatible
testable
production-grade

🧠 The Core Principle

App versions change — user data must survive.

Your schema is a contract with every version you’ve ever shipped.

🧱 1. Version Your Data Schema

Never rely on implicit structure.

struct SchemaVersion: Codable {
    let version: Int
}

Persist current version:

let currentSchemaVersion = 3

🧬 2. Migration Engine Lives in Infrastructure

final class MigrationEngine {
    private let persistence: PersistenceLayer
    private let migrations: [MigrationStep]
}

It does not live in:

Views
ViewModels
feature modules

Migration is cross-cutting infrastructure.

🔁 3. Define Migration Steps

struct MigrationStep {
    let from: Int
    let to: Int
    let migrate: () throws -> Void
}

Example:

MigrationStep(from: 1, to: 2) {
    addField("lastOpenedAt", default: Date())
}

Migrations must be:

ordered
idempotent
atomic

📦 4. Run Migrations at App Launch

func performMigrations() throws {
    let storedVersion = loadVersion()
    for step in migrations where step.from == storedVersion {
        try step.migrate()
        saveVersion(step.to)
    }
}

Run before:

sync engine starts
ViewModels load data
background tasks resume

⚠️ 5. Backward Compatibility Matters

Users may skip versions.

Migration path must support:

v1 → v4

Not only:

v3 → v4

🔄 6. Migration & Sync Queue Compatibility

If schema changes:

queued operations may become invalid
payload formats may change

Strategy:

migrateQueuedOperations()

Never drop user actions silently.

🔋 7. Safe Rollback Strategy

App updates fail in the real world.

Rules:

never delete old columns immediately
support dual-read during transition
remove fields only after several versions

This prevents catastrophic data loss.

🧪 8. Testing Migrations

Test scenarios:

upgrade from every prior version
partial migrations
corrupted data
interrupted migrations

Migration bugs are permanent.

⚠️ 9. Common Migration Anti-Patterns

Avoid:

destructive schema changes
silent data resets
skipping version tracking
running migrations lazily
mixing migration with feature logic

These lead to:

data loss
sync failures
inconsistent state

🧠 Mental Model

Think:

Old Schema
 → Migration Engine
   → New Schema
     → Sync Engine
       → App Features

Not:

“We’ll just reset the database.”

🚀 Final Thoughts

A proper migration system gives you:

safe app upgrades
preserved user data
compatibility with old client
fewer production incidents
confidence to evolve your schema

This is the difference between:

a fragile app
and a long-lived product

SwiftUI Background Sync Engine Architecture (Reliable, Battery-Aware, Conflict-Safe)

Sebastien Lato — Wed, 11 Feb 2026 20:06:03 +0000

Most apps implement sync like this:

refreshData()

That works…
until you need:

offline edits
retries
background execution
conflict handling
battery awareness
exponential backoff
rate limiting
cross-tenant sync

At that point, sync becomes one of the hardest systems in your app.

This post shows how to design a background sync engine in SwiftUI that is:

reliable
resilient
battery-conscious
conflict-aware
testable
production-grade

🧠 The Core Principle

Sync is a state machine — not a network call.

If your sync logic lives in a ViewModel, it’s already fragile.

🧱 1. Define Sync States Explicitly

Never treat sync as boolean.

Bad:

isSyncing = true

Correct:

enum SyncState {
    case idle
    case scheduled
    case syncing
    case failed(Error)
    case paused
}

The engine transitions between states — predictably.

🧬 2. Sync Engine Lives in Infrastructure

final class SyncEngine {
    private let queue: SyncQueue
    private let api: APIClient
    private let persistence: PersistenceLayer
}

It does not live in:

views
ViewModels
feature modules

Sync is cross-cutting infrastructure.

📦 3. Operation Queue Model

Treat sync work as operations:

struct SyncOperation {
    let id: UUID
    let type: OperationType
    let payload: Data
    let retryCount: Int
}

Operations are:

persisted
retried
ordered
cancellable

Never fire-and-forget.

🔁 4. Persistent Sync Queue

Queue must survive:

app termination
device reboot
crashes

Store operations in local database.

On launch:

loadPendingOperations()
resumeProcessing()

🔄 5. Retry Strategy

Never retry infinitely.

Example:

func nextRetryDelay(for attempt: Int) -> TimeInterval {
    pow(2, Double(attempt)) // exponential backoff
}

Rules:

max retry count
pause on fatal errors
respect HTTP status codes
differentiate network vs server errors

⚡ 6. Background Execution Integration

Integrate with:

BGTaskScheduler
background fetch
push-triggered sync

Example:

BGTaskScheduler.shared.register(...)

Sync engine runs independent of UI.

🔋 7. Battery & Network Awareness

Before syncing:

check reachability
check battery level
check low power mode

Avoid syncing:

on cellular (if heavy)
during low battery
while app inactive unless necessary

Sync must be respectful.

🧠 8. Conflict Resolution Integration

When server responds with conflict:

case .conflict:
    resolveConflict(local, remote)

Resolution strategies:

last-write-wins
merge fields
server authority
manual resolution queue

Conflict handling must be centralized — not per feature.

🧪 9. Testing the Sync Engine

Mock:

API failures
network loss
partial success
background interruptions

Test scenarios:

retry exhaustion
queue recovery
duplicate prevention
idempotency

Sync bugs are subtle and expensive.

⚠️ 10. Common Sync Anti-Patterns

Avoid:

syncing from ViewModels
not persisting queue
retrying without backoff
ignoring conflicts
not handling app termination
duplicating operations

These lead to:

data corruption
server overload
angry users

🧠 Mental Model

Think:

Local Change
 → Sync Operation
   → Persistent Queue
     → Retry Engine
       → Server
         → Reconciliation

Not:

“Just refresh when needed”

🚀 Final Thoughts

A proper background sync engine gives you:

reliable offline behavior
predictable data consistency
fewer production bugs
better battery efficiency
scalable architecture

This is the difference between:

a demo app
and a real product

SwiftUI Plugin & Extension Architecture (Modular, Extensible Apps)

Sebastien Lato — Tue, 10 Feb 2026 15:48:45 +0000

Most apps start simple.

Then they grow:

new features
optional tools
enterprise add-ons
internal modules
experimental capabilities

Without structure, this leads to:

feature coupling
massive app containers
tangled dependencies
impossible refactors
slow builds

This post shows how to design a plugin & extension architecture in SwiftUI that:

keeps features modular
allows optional capabilities
scales with teams
supports future extensibility

This is how large apps stay maintainable.

🧠 The Core Principle

Features should be pluggable, not hardwired.

If removing a feature breaks your app, the architecture is too coupled.

🧱 1. Define a Plugin Protocol

Each feature becomes a plugin.

protocol AppPlugin {
    var id: String { get }
    func register(in container: AppContainer)
}

Plugins:

declare themselves
register dependencies
expose entry points

🧬 2. Plugin Responsibilities

A plugin may provide:

routes
services
feature flags
background tasks
UI entry points

Example:

struct ChatPlugin: AppPlugin {
    let id = "chat"

    func register(in container: AppContainer) {
        container.register(ChatService.self)
        container.register(ChatViewModel.self)
    }
}

The app doesn’t need to know how chat works.

📦 3. Plugin Registry

Central registry:

final class PluginRegistry {
    private(set) var plugins: [AppPlugin] = []

    func register(_ plugin: AppPlugin) {
        plugins.append(plugin)
    }
}

At app startup:

registry.register(ChatPlugin())
registry.register(AnalyticsPlugin())
registry.register(ProfilePlugin())

Then initialize them.

🧭 4. Dynamic Feature Availability

Plugins can be:

always-on
feature-flagged
role-based
environment-based

Example:

if flags.isEnabled(.chat) {
    registry.register(ChatPlugin())
}

Features now become runtime capabilities.

🧠 5. Plugin-Based Navigation

Each plugin can expose routes:

protocol RoutablePlugin: AppPlugin {
    var routes: [AppRoute] { get }
}

Example:

ChatPlugin.routes = [
    .chatList,
    .chatDetail
]

The router builds navigation dynamically.

🔐 6. Dependency Isolation

Plugins should:

depend on shared domain interfaces
avoid direct cross-plugin imports
communicate via protocols

Bad:

ChatPlugin → ProfilePlugin

Good:

ChatPlugin → UserServiceProtocol
ProfilePlugin → UserServiceProtocol

Plugins must remain independent.

🧪 7. Testing Plugins in Isolation

Because plugins are modular:

let container = TestContainer()
ChatPlugin().register(in: container)

You can test:

plugin features alone
plugin integrations
plugin failure modes

This reduces complexity.

🔁 8. Plugin Lifecycle

A plugin should support:

registration
activation
deactivation
cleanup

Example use cases:

enterprise modules
paid features
experimental tools
region-based capabilities

⚠️ 9. Common Plugin Architecture Anti-Patterns

Avoid:

plugins importing each other
plugins mutating global state
plugins without clear ownership
feature flags scattered in views
plugins that cannot be disabled

If you can’t remove it, it’s not a plugin.

🧠 Mental Model

Think:

App Core
 → Plugin Registry
   → Plugins
     → Services + Routes + Features

Not:

“Everything lives in the main app target”

🚀 Final Thoughts

A plugin architecture gives you:

modular features
safer refactors
faster builds
clearer ownership
future extensibility

This is how:

design tool
enterprise apps
collaborative platforms
complex SaaS products

stay maintainable over time.

SwiftUI Multi-Tenant Architecture (Accounts, Workspaces, Isolation)

Sebastien Lato — Mon, 09 Feb 2026 21:18:23 +0000

Single-user apps are simple.

But real products eventually need:

multiple accounts
team workspaces
organization switching
sandbox vs production data
different permission scopes

Without proper architecture, this leads to:

mixed user data
cache corruption
wrong account actions
impossible bug reports
“why is this showing someone else’s data?”

This post shows how to design a multi-tenant architecture in SwiftUI that:

isolates user data
supports account switching
prevents cross-tenant bugs
scales to teams and organizations

🧠 The Core Principle

Every piece of data must belong to a tenant.

If you don’t know which account owns a piece of state, your architecture is already unsafe.

🧱 1. Define the Tenant Model

A tenant represents a data boundary.

struct Tenant {
    let id: UUID
    let name: String
    let role: Role
}

enum Role {
    case personal
    case member
    case admin
}

This could represent:

a user account
a workspace
an organization
a project context

🧬 2. Tenant-Aware App State

Never store global user data.

Bad:

class AppState {
    var user: User
    var projects: [Project]
}

Correct:

class AppState {
    var activeTenant: Tenant
    var tenantStores: [UUID: TenantStore]
}

Each tenant has its own isolated state.

📦 3. Tenant Store

final class TenantStore: ObservableObject {
    @Published var user: User
    @Published var projects: [Project]
    @Published var settings: TenantSettings
}

This ensures:

no cross-tenant leaks
clean switching
independent lifecycles

🔁 4. Account Switching Architecture

Switching tenants should:

Save current state
Tear down feature stores
Activate new tenant store
Rebuild navigation

Example:

func switchTenant(to tenant: Tenant) {
    activeTenant = tenant
    currentStore = tenantStores[tenant.id]
}

Never reuse old state across tenants.

🧭 5. Tenant-Scoped Services

Services must be tenant-aware.

Bad:

apiClient.fetchProjects()

Correct:

apiClient.fetchProjects(for: tenantID)

Or inject a tenant-scoped client:

TenantAPIClient(tenantID: tenant.id)

Every request must carry tenant context.

🧠 6. Storage Isolation

Persist data per tenant:

/Storage
  /tenant_1
    projects.db
  /tenant_2
    projects.db

Or use namespaced keys:

"tenant_\(id)_settings"

Never share storage across tenants.

🧪 7. Testing Multi-Tenant Flows

You must test:

switching accounts
logging out and back in
background sync per tenant
cross-tenant isolation
permission differences

Multi-tenant bugs are subtle and dangerous.

🔐 8. Permission & Role Awareness

Tenants may have different roles.

Example:

if tenant.role == .admin {
    showAdminPanel()
}

Never assume capabilities across tenants.

⚠️ 9. Common Multi-Tenant Anti-Patterns

Avoid:

global singletons for user data
shared caches across tenants
not clearing state on switch
hardcoded user assumptions
mixing personal and workspace data

These cause the worst production bugs.

🧠 Mental Model

Think:

Tenant
 → Tenant Store
   → Tenant Services
     → Tenant Storage
       → Tenant UI

Not:

“There’s just one user”

🚀 Final Thoughts

A proper multi-tenant architecture gives you:

safe account switching
clean workspace logic
better permission handling
fewer data leaks
scalable product design

If your app ever needs teams or organizations,
multi-tenant architecture is not optional.

SwiftUI Tech Debt Management System (Refactor Without Fear)

Sebastien Lato — Sat, 07 Feb 2026 17:36:23 +0000

Every successful app accumulates tech debt.

Not because developers are bad —
but because software changes faster than plans.

The problem isn’t debt.
The problem is unmanaged debt:

fear of refactoring
fragile systems
frozen code paths
endless “we’ll fix it later”
slow velocity over time

This post shows how to design a tech debt management system for SwiftUI that lets you:

move fast without fear
refactor safely
make debt visible
keep architecture healthy for years

🧠 The Core Principle

Tech debt is inevitable — unmanaged debt is optional.

You don’t eliminate debt.
You control it.

🧱 1. Make Debt Explicit

Debt that isn’t visible doesn’t exist.

Define a model:

struct TechDebtItem {
    let area: String
    let description: String
    let impact: Impact
    let urgency: Urgency
}

Debt must be:

documented
categorized
prioritized

Comments are not enough.

🧬 2. Classify Debt Types

Not all debt is equal.

Examples:

architectural debt
performance debt
test debt
dependency debt
UX debt

Treating all debt the same guarantees bad decisions.

🧭 3. Debt Budgets Per Feature

Every feature gets a debt budget.

Rules:

new debt must be declared
budget must be repaid
debt does not roll forever

This turns debt into a conscious tradeoff, not an accident.

🧪 4. Protect Refactors with Tests

Refactors require:

strong unit coverage
stable integration tests
clear invariants

If you’re afraid to refactor, tests are missing.

Refactoring fear is a signal, not a failure.

🧠 5. Incremental Refactoring Strategy

Never “big bang” refactors.

Instead:

isolate old code
introduce seams
migrate gradually
remove dead paths
ship continuously

Flags and adapters are your friends.

🔁 6. Track Debt Over Time

Debt should:

trend downward
spike intentionally
be reviewed regularly

If debt only grows, architecture is decaying.

⚠️ 7. Avoid These Debt Traps

Avoid:

TODO without owner
“temporary” hacks
shared dumping grounds
skipped tests “just this once”
ignoring architectural violations

Small shortcuts compound quickly.

🧠 Mental Model

Think:

Debt Identified
 → Tracked
   → Budgeted
     → Repaid
       → System Health

Not:

“We’ll clean it up later”

🚀 Final Thoughts

A real tech debt system gives you:

confidence to change code
sustainable velocity
happier teams
fewer rewrites
long-lived products

Tech debt isn’t a failure.
Ignoring it is.

SwiftUI Build & CI/CD Architecture (Ship Fast Without Breaking Things)

Sebastien Lato — Thu, 05 Feb 2026 23:45:46 +0000

Most iOS teams think CI/CD is “running tests”.

In reality, it’s the last line of architectural defense:

bad dependencies should fail builds
performance regressions should block merges
broken localization should never ship
flaky tests should be visible, not ignored

This post shows how to design a production-grade CI/CD architecture for SwiftUI that:

enforces quality automatically
scales with team size
prevents regressions
keeps release velocity high

🧠 The Core Principle

If quality is optional, it will be skipped.

CI/CD exists to make quality non-optional.

🧱 1. CI Is an Architectural Boundary

CI is not tooling glue.
It is an extension of your architecture.

Anything you care about must be enforced here:

dependency rules
test coverage
performance budgets
linting
build reproducibility

If CI doesn’t fail, the system allowed it.

🧬 2. Deterministic Builds

Your build must be:

reproducible
deterministic
environment-independent

Rules:

lock dependency versions
avoid implicit build settings
avoid local-only scripts
no manual build steps

A build that only works on one machine is already broken.

🧪 3. Test Pyramid Enforcement

Automate the pyramid:

Unit tests → fast, numerous
Integration tests → focused
UI tests → minimal, critical paths only

Fail the build if:

unit tests fail
critical UI flows break
flaky tests exceed threshold

CI should surface instability early.

⚡ 4. Performance Regression Gates

Performance is a feature.

Track:

app launch time
critical screen render times
memory peaks
scroll performance

Block merges when:

metrics exceed baseline
regressions cross tolerance

Performance regressions are bugs, not suggestions.

🌍 5. Localization & Accessibility Checks

CI should validate:

missing localization keys
broken RTL layouts (snapshot tests)
dynamic type scaling
accessibility labels presence

If CI doesn’t test this, production users will.

🔐 6. Security & Configuration Validation

Validate in CI:

secrets not committed
debug flags not enabled
logging levels correct
environment config sanity

Never rely on manual review for this.

🧭 7. CI Stages (Recommended)

Example pipeline:

Static analysis (lint, format, dependency audit)
Unit tests
Integration tests
Snapshot tests
Performance checks
Build artifact validation
Archive & distribute

Each stage narrows risk.

🧠 8. Artifact-Centered Releases

CI should produce:

signed build artifacts
versioned archives
reproducible outputs

Release pipelines consume artifacts, not source.

This guarantees what you tested is what you ship.

⚠️ 9. Common CI/CD Anti-Patterns

Avoid:

skipping CI for “small changes”
flaky tests ignored
manual release steps
performance checks removed “temporarily”
CI that only runs on main

These create silent regressions.

🧠 Mental Model

Think:
Code Change
→ CI Enforcement
→ Artifact
→ Release

Not:

“It passed locally”

🚀 Final Thoughts

A strong CI/CD architecture gives you:

faster releases
safer refactors
fewer production incidents
calmer teams
real confidence

CI/CD is not overhead.
It is operational architecture.

SwiftUI Dependency Graph Visualization & Auditing (Enforce Architecture, Don’t Trust It)

Sebastien Lato — Wed, 04 Feb 2026 18:09:42 +0000

Every large SwiftUI codebase eventually says:

“We follow clean architecture.”

Then six months later:

features import each other
ViewModels talk to services directly
infrastructure leaks upward
cycles appear
nobody knows what depends on what

Architecture without enforcement always decays.

This post shows how to design dependency graph visualization & auditing for SwiftUI apps so your architecture is:

visible
enforceable
reviewable
resilient over time

🧠 The Core Principle

Architecture is a graph — not a guideline.

If you can’t see your dependency graph, you can’t control it.

🧱 1. Define Allowed Dependency Directions

Before tooling, define rules.

Example:

Views
→ ViewModels
→ Domain
→ Infrastructure

Rules:

no upward dependencies
no cross-feature imports
infrastructure never imports features
features never import each other directly

Write this down. This is your contract.

🧬 2. Treat Modules as Graph Nodes

Each logical module is a node:

Feature modules
Domain modules
Infrastructure modules
Shared utilities

The graph edges are imports.

This means:

imports = architectural dependencies
build errors = enforcement points

🔍 3. Generate the Dependency Graph

Use static analysis to extract imports.

Example approaches:

Swift Package Manager manifests
Xcode build logs
custom SourceKit parsing
scripts that scan import statements

Output a graph format (DOT / JSON):

FeatureA → Domain
FeatureA → FeatureB ❌

Visualization exposes reality instantly.

🧭 4. Visualize the Graph

Render the graph using:

Graphviz
Mermaid
custom dashboards

You should be able to:

see cycles
spot illegal edges
identify hotspots
track growth over time

If architecture can’t be visualized, it can’t be trusted.

🧪 5. Automated Dependency Audits

Turn architecture rules into tests.

Example:

fail if Feature imports Infrastructure
fail if Feature imports Feature
fail if cycle detected

Run audits:

locally
in CI
on every PR

Architecture violations should fail builds — not code reviews.

🧠 6. Ownership & Boundaries

Every node should have:

an owner
a purpose
allowed dependencies

When a dependency is added:

ask why
document it
review the boundary

Undefined ownership accelerates decay.

🔁 7. Detect Cycles Early

Cycles kill:

testability
refactors
parallel work

Graph tooling should detect:

direct cycles
transitive cycles
hidden cycles via shared utilities

Break cycles immediately — they only get worse.

⚠️ 8. Common Dependency Anti-Patterns

Avoid:

shared “Utils” modules that import everything
feature-to-feature imports
infrastructure leaking into ViewModels
global singletons as dependency shortcuts
“temporary” imports that stay forever

If it’s convenient, it’s probably wrong.

🧠 Mental Model

Think:

Architecture Rules
 → Dependency Graph
   → Automated Audits
     → Build Enforcement

Not:

“Let’s try to remember the rules”

🚀 Final Thoughts

Dependency graph auditing gives you:

enforceable architecture
fearless refactoring
faster onboarding
safer scaling
long-lived codebases

Architecture is not documentation.
It is constraint + visibility.