SwiftUI Architecture Best Practices:
Production iOS App Design

1. Executive Summary

SwiftUI’s declarative model makes simple apps straightforward and complex apps treacherous. The patterns that work for a tutorial — @State in views, ObservableObject with @Published — do not scale to production apps with async data pipelines, on-device ML inference, and persistent storage.

The iOS 17 observation system (@Observable macro) eliminates the boilerplate and over-notification problems of ObservableObject. Combined with .task-based async data loading, actor-backed services, and SwiftData for structured persistence, these form a complete layered architecture that handles AI inference results, local-first data, and complex view hierarchies without coupling.

2. Key Statistics

3. @Observable vs ObservableObject

ObservableObject fires objectWillChange for any @Published property change, invalidating all views that observe the object even if they only read a different property. The @Observable macro introduced in iOS 17 tracks property access per-view, so only views that read a changed property are re-rendered.

// Pre-iOS 17: every @Published change notifies ALL observers
class InferenceViewModel: ObservableObject {
    @Published var isLoading: Bool = false
    @Published var result: String = ""
    @Published var error: String? = nil
    // Any update to isLoading re-renders views reading result too
}

// iOS 17+: only views accessing changed properties re-render
// No @Published, no objectWillChange, no ObservableObject conformance
@Observable
class InferenceViewModel {
    var isLoading: Bool = false
    var result: String = ""
    var error: String? = nil

    // Access to the actor service is fine — stored as a reference
    private let service: ClassifierService

    init(service: ClassifierService) {
        self.service = service
    }

    func classify(text: String) async {
        isLoading = true
        do {
            result = try await service.classify(text: text)
        } catch {
            self.error = error.localizedDescription
        }
        isLoading = false
    }
}

// In SwiftUI — no @StateObject/@ObservedObject needed
// Just use @State for the view model
struct ContentView: View {
    @State private var vm = InferenceViewModel(service: .shared)
    // ...
}

4. Layered Architecture for Production Apps

Production SwiftUI apps benefit from clear separation into three layers: a data layer (actors + SwiftData), a domain layer (business logic, independent of UI), and a presentation layer (SwiftUI views + @Observable view models). Each layer has one direction of dependency — presentation depends on domain, domain depends on data, never the reverse.

5. Async Data Loading with .task

The .task modifier (iOS 15+) starts an async task tied to a view’s lifetime and automatically cancels on view disappearance. It is the correct replacement for onAppear + Task for data loading.

struct ResultsView: View {
    @State private var vm = ResultsViewModel()
    let itemID: UUID  // drives re-fetch when item changes

    var body: some View {
        Group {
            if vm.isLoading {
                ProgressView()
            } else if let error = vm.error {
                ErrorView(message: error)
            } else {
                ResultContent(result: vm.result)
            }
        }
        // Cancels automatically when view disappears
        // Re-runs when itemID changes (identity-based)
        .task(id: itemID) {
            await vm.load(id: itemID)
        }
    }
}

@Observable
class ResultsViewModel {
    var result: AnalysisResult? = nil
    var isLoading: Bool = false
    var error: String? = nil

    func load(id: UUID) async {
        isLoading = true
        error = nil
        do {
            result = try await AnalysisPipeline.shared.analyze(id: id)
        } catch is CancellationError {
            // Task was cancelled — do not update state
        } catch {
            self.error = error.localizedDescription
        }
        isLoading = false
    }
}

6. AI Result Binding Patterns

On-device AI results typically arrive asynchronously and should drive UI updates without blocking the main thread. The recommended pattern uses an @Observable view model that holds the result state, updated from within a .task. For streaming inference, AsyncStream allows token-by-token UI updates.

// Streaming inference bound directly to SwiftUI Text
struct StreamingView: View {
    @State private var tokens: String = ""
    @State private var isStreaming: Bool = false
    let llm = LLMService()
    let prompt: String

    var body: some View {
        ScrollView {
            Text(tokens)
                .frame(maxWidth: .infinity, alignment: .leading)
        }
        .overlay(alignment: .bottomTrailing) {
            if isStreaming {
                ProgressView().padding()
            }
        }
        .task(id: prompt) {
            tokens = ""
            isStreaming = true
            for await token in await llm.generate(prompt: prompt) {
                tokens += token
            }
            isStreaming = false
        }
    }
}

7. SwiftData Integration

SwiftData (iOS 17+) stores AI inference results as first-class entities — predicted categories, confidence scores, embeddings — alongside source data. The @Query macro integrates with SwiftUI declaratively, automatically sorting and filtering AI-scored entities.

import SwiftData

// AI-enriched model: source data + inference results together
@Model
class Note {
    var body: String
    var createdAt: Date

    // AI inference results stored alongside source
    var sentimentLabel: String?      // "positive" | "negative" | "neutral"
    var sentimentScore: Float?       // 0.0–1.0 confidence
    var embedding: [Float]?          // for semantic search
    var categoryTags: [String]       // predicted topic tags
    var aiProcessedAt: Date?

    init(body: String) {
        self.body = body
        self.createdAt = .now
        self.categoryTags = []
    }
}

// SwiftUI view: query auto-updates when any Note changes
struct NotesView: View {
    // Sort by AI confidence — most actionable items first
    @Query(sort: \Note.sentimentScore, order: .reverse)
    private var notes: [Note]

    var body: some View {
        List(notes) { note in
            NoteRow(note: note)
        }
    }
}

8. Benchmarks & Results

Measured with Xcode TimeProfiler. 500-item list with AI-annotated rows. iPhone 15 Pro, iOS 17.4.

9. Conclusion & Recommendations

For iOS 17+ targets, the recommended architecture is: (1) @Observable view models for presentation state, (2) actors for all ML and async data services, (3) .task(id:) for async data loading tied to view lifecycle, (4) SwiftData @Model types for AI-enriched persistence, and (5) AsyncStream for streaming inference output.

10. About 3NSOFTS

3NSOFTS designs and builds production iOS apps with on-device AI at their core. The SwiftUI architecture patterns in this whitepaper are extracted from shipping apps including offgrid:AI (on-device LLM), CalmLedger (privacy-first finance), and DevScope (Swift 6 performance tooling).

info@3nsofts.com · 3nsofts.com