Enhancing the accessibility of your SwiftUI app

At a glance

Project structure

Sources/
├── App.swift
├── Model/                 # SwiftData models and TripRouter
├── Views/                 # Trips, beaches, comments, alerts
├── Styles/                # Focused SwiftUI modifiers/styles
└── Widget/                # Widget entry, provider, intents, widget views

The Widget folder is a target boundary; Model and selected view/model code support both processes.

Overall architecture

flowchart LR
    App["SwiftUI app target"] --> Content["ContentView / tabs"]
    Content --> Trips["TripsView"]
    Content --> Beaches["BeachesView"]
    App --> Data["SwiftData ModelContainer"]
    Widget["Widget extension"] --> Provider["TimelineProvider"]
    Widget --> Data
    Intent["ComposeIntent / ToggleRatingIntent"] --> Router["TripRouter or SwiftData"]
    Trips --> Router

Reference code

Sources/App.swift:11 and Sources/Widget/WidgetBundle.swift:11 — the archive has two entry points (abridged).

@main
struct SwiftUIAccessibilitySampleApp: App {
    var body: some Scene {
        WindowGroup { ContentView() }
            .modelContainer(for: [Trip.self, Beach.self, Contact.self])
    }
}

@main
struct SwiftUIAccessibilitySampleWidgetBundle: WidgetBundle {
    var body: some Widget { SwiftUIAccessibilitySampleWidget() }
}

Ownership and state

classDiagram
    SwiftUIAccessibilitySampleApp *-- ModelContainer
    TripsView o-- TripRouter : shared bindable
    TripRouter o-- Trip : selectedTrip
    ComposeIntent --> TripRouter : requestComposition
    WidgetView o-- Beach : SwiftData query
    ToggleRatingIntent --> ModelContainer : opens process-local context

Ownership evidence

Sources/Model/TripRouter.swift:12 — the main-actor router owns only navigation/composition state.

@Observable @MainActor
final class TripRouter {
    static let shared = TripRouter()
    var selectedTrip: Trip?
    private(set) var compositionRequested: ComposeType?

    func requestComposition(for type: ComposeType) {
        compositionRequested = type
    }
}

SwiftData is the durable mutation authority. TripsView observes the router and inserts the requested trip; the widget intent creates its own model container because it may execute outside the app process.

Class and protocol design

Most UI types are small View structs composed by feature. Models adopt framework protocols (Identifiable, Codable, AppEnum, AppIntent, TimelineProvider). The only central reference type is TripRouter, which is final, observable, and main-actor isolated. The private widget Provider adopts TimelineProvider at Sources/Widget/Widget.swift:82.

Access control

Logic ownership and placement

Design patterns

Naming conventions

• Screen roots use feature nouns plus View (TripsView, BeachesView).
• Framework roles use exact suffixes (WidgetBundle, Provider, Intent, Entry).
• Internal presentation components use descriptive role names such as AttachmentOverlayView.

Architecture takeaways

• Treat app and widget as separate processes even when they share source and storage.
• Let App Intents translate requests; keep mutation in the router or data context that owns the state.
• Use narrow private SwiftUI components to keep accessibility modifiers close to their content.
• This archive shares source by target membership; it does not demonstrate a public modular package.

Source map

• Official Apple documentation