SwiftUI Architecture and UIKit Interoperability

Introduction

A SwiftUI application can begin as a small collection of views, but production software requires more than visually correct screens. It must be understandable, testable, adaptable, and safe to change. Architecture provides the structure that separates responsibilities and controls dependencies. In SwiftUI, this commonly involves modular views, observable state, presentation logic, domain models, services, and reusable components. UIKit interoperability is equally important because many iOS applications contain existing UIKit code, rely on UIKit-only frameworks, or must support gradual migration.

This chapter presents a practical architecture for certificate-level iOS development. It does not prescribe one universal pattern. Instead, it explains how to make deliberate decisions about state ownership, data flow, view responsibilities, modules, and integration boundaries.

Learning Objectives

By the end of this chapter, you should be able to:

• Explain the responsibilities of view, presentation, domain, and data layers.
• Apply MVVM-informed design without creating unnecessary abstractions.
• Select appropriate SwiftUI property wrappers for state and dependencies.
• Build reusable and composable SwiftUI components.
• Integrate UIKit view controllers and views with SwiftUI.
• Embed SwiftUI screens inside UIKit applications.
• Identify architectural risks involving state, navigation, testing, and legacy code.

1. Architecture as Responsibility Management

Architecture is the arrangement of software responsibilities and dependencies. It is not merely a folder structure. A maintainable application makes it clear:

1. Where data originates.
2. Which object is allowed to change it.
3. Which code decides what should happen.
4. Which code displays the result.
5. Which parts can be tested independently.

A SwiftUI View is a value describing a user interface. It should generally render state and send user intentions to another object rather than contain networking, persistence, and business rules in one body property.

A useful conceptual division is:

The layers are conceptual rather than mandatory directories. A small application may combine some layers; a large application may divide them into separate Swift packages or modules.

2. SwiftUI’s Declarative Model and Data Flow

In imperative UI programming, code commonly instructs a view to change: set a label, reload a table, or present a controller. SwiftUI uses a declarative model. The developer describes the interface for a given state, and SwiftUI determines the necessary updates.

Conceptually:

State change → body recomputation → updated view description → rendered interface

This does not mean that every part of the screen is recreated inefficiently. SwiftUI compares view descriptions and updates the underlying rendering system as needed.

2.1 Ownership of state

State should have one clear owner whenever practical. A view that creates and owns a reference-type model may use @StateObject when using the Observation model common to older SwiftUI versions, or @State with an observable model in newer systems. A child receiving an externally owned observable object should not create a second owner.

Common wrappers include:

The central question is not “Which wrapper is fashionable?” but “Who owns this state, and who merely observes or edits it?”

2.2 Single source of truth

Suppose a parent stores a selected task and a child separately stores another copy. The two values can diverge. A better design stores the authoritative value once and passes a binding or immutable value as appropriate.

struct TaskEditor: View {
    @Binding var title: String

    var body: some View {
        TextField("Task title", text: $title)
            .textFieldStyle(.roundedBorder)
    }
}

The editor does not decide where the title is persisted. It edits a binding supplied by its owner.

3. MVVM-Informed SwiftUI Design

Model–View–ViewModel (MVVM) separates domain data, interface description, and presentation behavior.

• Model: Domain entities and rules.
• View: SwiftUI declarations and user interaction controls.
• ViewModel: Screen-specific state, formatting, commands, and coordination.

MVVM is best treated as an informed design pattern rather than a requirement that every view has a large class called ViewModel. A tiny static view may need no view model. A screen that loads data, validates input, handles errors, and coordinates navigation probably benefits from one.

3.1 Domain model

A domain model should express meaningful application concepts and remain independent of SwiftUI where possible.

struct Task: Identifiable, Equatable {
    let id: UUID
    var title: String
    var isComplete: Bool
}

The model does not need to know whether it will be shown in a List, stored in Core Data, or returned by a web service.

3.2 Service abstraction

A service performs an external operation. An abstraction makes the view model testable.

protocol TaskRepository {
    func fetchTasks() async throws -> [Task]
    func save(_ task: Task) async throws
}

A production repository may call a server. A test repository may return fixed data or controlled errors.

3.3 View model

A view model exposes state that is useful to the view. It should not merely duplicate every property in the model.

@MainActor
final class TaskListViewModel: ObservableObject {
    @Published private(set) var tasks: [Task] = []
    @Published private(set) var isLoading = false
    @Published var errorMessage: String?

    private let repository: TaskRepository

    init(repository: TaskRepository) {
        self.repository = repository
    }

    func load() async {
        isLoading = true
        defer { isLoading = false }

        do {
            tasks = try await repository.fetchTasks()
        } catch {
            errorMessage = "Tasks could not be loaded."
        }
    }
}

@MainActor communicates that published UI-facing state is accessed on the main actor. The repository may perform asynchronous work elsewhere, but updates observed by the interface are coordinated safely.

3.4 View

struct TaskListView: View {
    @StateObject private var model: TaskListViewModel

    init(repository: TaskRepository) {
        _model = StateObject(
            wrappedValue: TaskListViewModel(repository: repository)
        )
    }

    var body: some View {
        Group {
            if model.isLoading {
                ProgressView()
            } else {
                List(model.tasks) { task in
                    Label(task.title,
                          systemImage: task.isComplete ? "checkmark.circle" : "circle")
                }
            }
        }
        .task { await model.load() }
        .alert("Error", isPresented: Binding(
            get: { model.errorMessage != nil },
            set: { if !$0 { model.errorMessage = nil } }
        )) {
            Button("OK", role: .cancel) { }
        } message: {
            Text(model.errorMessage ?? "Unknown error")
        }
    }
}

This example separates rendering from data acquisition. The view still coordinates lifecycle events, but the repository and loading rules are not embedded in the layout.

4. Presentation and Domain Separation

Presentation concerns include loading indicators, alert text, sorting choices, formatting, and navigation state. Domain concerns include what a task is, whether a task may be completed, and which rules determine validity.

For example, a date such as 2026-04-10T09:00:00Z belongs to a domain or data representation. The string “Friday, 10 April” is presentation formatting. Keeping these concerns separate permits the same domain object to support different interfaces and locales.

A practical rule is:

Domain code should not require SwiftUI merely to exist; presentation code may depend on domain code to display useful information.

This separation also reduces the impact of changing a server API. A repository can translate a network response into a domain model, while the view remains unaware of JSON keys and HTTP status codes.

5. Reusable Components and Modularity

A reusable component has a clear purpose, a small interface, and minimal assumptions about its parent. Reuse should reduce duplication without hiding important behavior.

5.1 Component boundaries

A component is a strong candidate for extraction when it:

• Has a recognizable semantic role.
• Is repeated in several places.
• Has independently meaningful layout or behavior.
• Can be configured through a small number of properties.
• Can be previewed or tested independently.

struct StatusBadge: View {
    let text: String
    let color: Color

    var body: some View {
        Text(text)
            .font(.caption.weight(.semibold))
            .padding(.horizontal, 8)
            .padding(.vertical, 4)
            .background(color.opacity(0.15), in: Capsule())
            .foregroundStyle(color)
    }
}

The component does not know whether it appears in a task list, profile, or dashboard.

5.2 Feature modules

A feature module may contain its views, view models, domain-specific services, and tests. Examples include Tasks, Authentication, and Settings. Shared design-system components can reside in a separate module.

Benefits include:

• Lower cognitive load for developers.
• Clear ownership of feature behavior.
• Reduced accidental coupling.
• Faster testing and compilation when using package boundaries.

However, excessive modularization creates indirection. A certificate-level project should begin with logical feature folders and introduce separate frameworks or Swift packages when boundaries provide a clear benefit.

6. Navigation and Presentation Architecture

Navigation is application state. It should not be scattered across unrelated leaf views. A feature coordinator, navigation model, or parent view can own the route state.

For value-based navigation, a route enum can provide a finite vocabulary:

enum TaskRoute: Hashable {
    case detail(UUID)
    case create
}

A parent can use a NavigationStack and a path containing routes. The detail view receives an identifier or domain object and obtains the required data through an appropriate dependency.

Sheets and alerts should also have identifiable state where practical. A single optional presentation state is often clearer than several unrelated Boolean flags, because it prevents contradictory presentations.

7. UIKit Interoperability

SwiftUI and UIKit can coexist in either direction:

1. SwiftUI can host UIKit views and view controllers.
2. UIKit can host SwiftUI views and view controllers.

This enables incremental migration rather than a risky rewrite.

7.1 Wrapping a UIKit view with UIViewRepresentable

Use UIViewRepresentable for a UIKit UIView.

struct LegacyProgressView: UIViewRepresentable {
    @Binding var progress: Float

    func makeUIView(context: Context) -> UIProgressView {
        UIProgressView(progressViewStyle: .default)
    }

    func updateUIView(_ view: UIProgressView, context: Context) {
        view.progress = progress
    }
}

makeUIView creates the underlying object once for the representable’s lifetime. updateUIView applies current SwiftUI state whenever the representation is updated. It should be safe to call repeatedly and should not perform unnecessary one-time setup.

7.2 Wrapping a UIKit view controller

Use UIViewControllerRepresentable when the UIKit object is a controller, such as an image picker or a legacy editing workflow.

struct LegacyEditor: UIViewControllerRepresentable {
    @Binding var text: String

    func makeUIViewController(context: Context) -> EditorViewController {
        let controller = EditorViewController()
        controller.delegate = context.coordinator
        return controller
    }

    func updateUIViewController(
        _ controller: EditorViewController,
        context: Context
    ) {
        controller.text = text
    }

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

    final class Coordinator: NSObject, EditorViewControllerDelegate {
        private let text: Binding<String>

        init(text: Binding<String>) {
            self.text = text
        }

        func editor(_ editor: EditorViewController,
                    didChangeText value: String) {
            text.wrappedValue = value
        }
    }
}

The coordinator is an adapter for delegate-based UIKit callbacks. It should translate UIKit events into SwiftUI state changes rather than become a second, hidden view model.

7.3 Hosting SwiftUI in UIKit

UIKit can display a SwiftUI view through UIHostingController.

let view = TaskListView(repository: repository)
let controller = UIHostingController(rootView: view)
navigationController?.pushViewController(controller, animated: true)

A UIKit application can therefore migrate one screen at a time. The hosting controller boundary should receive explicit dependencies and communicate results through a defined mechanism, such as a closure, shared model, delegate adapter, or navigation coordinator.

7.4 Lifecycle and memory considerations

Interoperability introduces risks:

• A delegate must usually be weak when UIKit defines it as weak.
• Closures capturing controllers can create retain cycles.
• UIKit callbacks may occur on threads unsuitable for UI updates.
• Repeated updateUIView calls must not repeatedly register observers or recreate expensive resources.
• Presentation and dismissal should have one clear owner.

The bridge is a boundary. Keep conversions, event translation, and lifecycle handling there rather than spreading UIKit details throughout SwiftUI views.

8. Illustrative Case: Migrating a Legacy Task Editor

Background

A fictional productivity application has a UIKit task editor used by thousands of users. The team is introducing a SwiftUI task list but cannot replace the editor immediately.

Problem

The new SwiftUI list must open the existing editor, receive saved changes, and update its displayed task without duplicating persistence logic.

Analysis

The editor already owns complex UIKit controls and validation. Rewriting it would create regression risk. The list, however, benefits from SwiftUI’s declarative rendering and modern navigation.

Approach

The team defines a domain Task, a repository protocol, and a SwiftUI view model. A UIViewControllerRepresentable wraps the editor. The coordinator translates the editor’s delegate callback into a completion closure or binding. The repository remains the authoritative persistence boundary.

The flow is:

SwiftUI list → route with task ID → UIKit editor bridge
UIKit save callback → repository → view-model reload → SwiftUI list updates

The bridge does not directly mutate list rows. It reports an outcome to the feature layer, which decides whether and how to refresh data.

Outcome

The application gains a SwiftUI list without rewriting the editor. Tests can exercise the view model using a fake repository, while focused integration tests verify the bridge and delegate translation.

Learning points

• Incremental migration is often safer than wholesale replacement.
• A bridge should translate interfaces, not own the entire application workflow.
• Persistence should have one authoritative boundary.
• Explicit dependencies make mixed-framework features easier to test.

9. Testing and Quality Practices

Architecture supports several levels of testing:

• Domain tests: Verify rules and transformations without UI frameworks.
• View-model tests: Use fake repositories to test loading, success, and failure states.
• Component previews: Explore visual states quickly.
• UI tests: Verify critical user journeys.
• Integration tests: Confirm UIKit bridges, delegates, and presentation behavior.

A useful test double is deterministic. It should permit the test to control whether a request succeeds, fails, or returns specific data. Avoid tests that depend on a real network service or timing assumptions.

Accessibility is also architectural. Reusable components should expose meaningful labels, support Dynamic Type where appropriate, and preserve sufficient contrast. A component that looks correct but cannot be operated with VoiceOver is not complete.

10. Challenges, Limitations, and Best Practices

Common challenges

Massive views: A single view containing networking, validation, navigation, and layout becomes difficult to reason about.

Over-engineering: Protocols, coordinators, and generic wrappers added without a real variation increase complexity.

Duplicated state: Separate copies of the same value produce inconsistent interfaces.

Unclear ownership: Multiple objects attempt to dismiss, save, or navigate at once.

UIKit leakage: Platform-specific types spread into domain code, reducing portability and testability.

Best practices

1. Give each piece of state one clear owner.
2. Keep domain models independent of SwiftUI when practical.
3. Inject repositories and services rather than constructing them deep inside views.
4. Use view models for meaningful presentation coordination, not as storage for every value.
5. Make reusable components small and configuration-oriented.
6. Keep UIKit adapters thin and idempotent during updates.
7. Treat navigation and presentation as explicit state.
8. Test behavior at the lowest practical layer.
9. Introduce modules when they clarify ownership, not merely because folders seem untidy.
10. Document migration boundaries and expected ownership of callbacks.

Contemporary Considerations

SwiftUI continues to evolve, including newer observation mechanisms and improved navigation APIs. Projects should follow the deployment targets and toolchain they support rather than mixing patterns without a reason. The architectural principles remain stable: explicit ownership, unidirectional intent flow, isolated side effects, and clear boundaries.

AI-assisted coding can generate SwiftUI and UIKit bridge code quickly, but generated code must be reviewed for actor isolation, retain cycles, accessibility, lifecycle correctness, and privacy. AI tools should not receive confidential source code, credentials, user data, or proprietary API specifications without authorization.

Chapter Summary

Maintainable SwiftUI applications separate interface rendering from presentation coordination, domain rules, and data access. MVVM-informed design is useful when a screen has meaningful state and behavior, but it should not become an automatic layer for every small view. State ownership and one authoritative source of truth are central to predictable SwiftUI behavior.

Reusable components should have focused responsibilities and explicit inputs. Feature-oriented organization can improve maintainability, while excessive abstraction can do the opposite. UIKit interoperability enables gradual migration: UIViewRepresentable wraps UIKit views, UIViewControllerRepresentable wraps controllers, and UIHostingController embeds SwiftUI in UIKit. Coordinators translate delegate callbacks at the boundary. Careful lifecycle management, dependency injection, accessibility, and testing make mixed-framework applications safer to evolve.

Key Terms

State ownership: The responsibility for creating, retaining, and changing a piece of state.

Binding: A two-way connection to state owned elsewhere.

Declarative UI: An approach in which the interface is described as a function of current state.

MVVM: A pattern separating model, view, and view-model responsibilities.

Domain model: A representation of business concepts and rules.

Presentation layer: Code that prepares domain information for a particular interface.

Repository: An abstraction that obtains or stores domain data.

Dependency injection: Supplying dependencies from outside rather than constructing them internally.

Observable object: A reference type that publishes changes for observers.

Single source of truth: One authoritative location for a value.

Reusable component: A focused interface element configurable through explicit inputs.

Feature module: A group of code organized around a coherent application capability.

Navigation state: Data representing the current route or destination.

UIKit interoperability: The use of SwiftUI and UIKit within the same application.

UIViewRepresentable: A protocol for presenting a UIKit view in SwiftUI.

UIViewControllerRepresentable: A protocol for presenting a UIKit view controller in SwiftUI.

UIHostingController: A UIKit controller that hosts a SwiftUI view hierarchy.

Coordinator: An adapter object that translates UIKit delegate events for SwiftUI.

Actor isolation: Rules controlling safe access to state across concurrent execution contexts.

Retain cycle: A reference relationship that prevents objects from being released.

Review Questions

5 Short Answer Questions

1. What is the primary responsibility of a SwiftUI view in an architecturally separated application?
2. Distinguish @State from @Binding.
3. Why should domain models generally avoid depending directly on SwiftUI?
4. What is the purpose of a coordinator in a UIKit bridge?
5. Name two risks associated with UIKit interoperability.

5 Long Answer Questions

1. Explain how MVVM-informed architecture can improve the testability of a SwiftUI feature.
2. Discuss the importance of single-source-of-truth state ownership and provide an example of duplicated state causing a defect.
3. Compare UIViewRepresentable, UIViewControllerRepresentable, and UIHostingController.
4. Explain how feature modularity can improve maintainability and identify one danger of excessive modularization.
5. Describe an incremental strategy for migrating a UIKit application to SwiftUI.

3 Analytical / Application Questions

1. Design the architecture for a SwiftUI task screen that loads tasks from a server, supports offline data, and opens a legacy UIKit editor. Identify the responsibilities of each layer.
2. A child view creates its own copy of a parent’s selected item and changes are not reflected in the parent. Diagnose the problem and propose a corrected data-flow design.
3. A UIViewRepresentable registers a notification observer every time updateUIView is called. Analyze the lifecycle problem and propose a safer implementation strategy.

Multiple Choice Questions with Answers

Question 1

Which SwiftUI mechanism is most appropriate when a child view needs to edit state owned by its parent?

A. @Binding

B. @StateObject

C. @EnvironmentObject

D. UIViewControllerRepresentable

Correct Answer: A. @Binding

Question 2

What is the primary responsibility of a view model in an MVVM-informed SwiftUI design?

A. Drawing every pixel of the interface

B. Coordinating presentation state and screen-specific behavior

C. Replacing all domain models

D. Managing UIKit memory automatically

Correct Answer: B. Coordinating presentation state and screen-specific behavior

Question 3

Which protocol wraps a UIKit UIView for use in SwiftUI?

A. UIViewControllerRepresentable

B. ObservableObject

C. UIViewRepresentable

D. Identifiable

Correct Answer: C. UIViewRepresentable

Question 4

What does UIHostingController provide?

A. A way to embed SwiftUI in UIKit

B. A replacement for every repository

C. Automatic database persistence

D. A UIKit delegate for SwiftUI controls

Correct Answer: A. A way to embed SwiftUI in UIKit

Question 5

Why is a repository protocol useful in a view-model test?

A. It forces the test to use a live server

B. It permits a controlled fake data source

C. It removes the need for assertions

D. It converts every view into UIKit

Correct Answer: B. It permits a controlled fake data source

Question 6

Which statement best describes a single source of truth?

A. Every view stores its own copy of application data

B. One authoritative owner controls a particular value

C. Only UIKit may modify state

D. All state is stored globally

Correct Answer: B. One authoritative owner controls a particular value

Question 7

What is the usual purpose of a coordinator in UIViewControllerRepresentable?

A. To translate UIKit delegate callbacks into SwiftUI actions or state changes

B. To compile Swift code at runtime

C. To replace the wrapped view controller’s layout

D. To persist data without a repository

Correct Answer: A. To translate UIKit delegate callbacks into SwiftUI actions or state changes

Question 8

Which is a common danger in a representable’s update method?

A. It is called repeatedly, so one-time setup may be duplicated

B. It can never receive new state

C. It automatically disables accessibility

D. It always runs only during app launch

Correct Answer: A. It is called repeatedly, so one-time setup may be duplicated

Question 9

Which layer should normally contain business rules such as whether a task may be completed?

A. Domain layer

B. Color asset catalog

C. UIKit bridge only

D. Preview provider only

Correct Answer: A. Domain layer

Question 10

What is a major benefit of incremental UIKit-to-SwiftUI migration?

A. It eliminates the need for testing

B. It permits replacement without rewriting the whole application at once

C. It guarantees that no adapters are required

D. It prevents SwiftUI state from changing

Correct Answer: B. It permits replacement without rewriting the whole application at once