Patterns across Apple sample code

These corpus-level findings summarize exact labels and source-visible structures from the reviewed sample analyses. Counts are non-exclusive, and a name or import never establishes an architecture by itself. Follow a linked sample page for the source citations behind each classification.

Explore samples · Frameworks · About

Findings across Apple sample code

The completed 2026-07-21 Apple documentation snapshot contains 657 sample pages backed by 643 distinct verified source bundles. Counts below use sample documents as the unit because one Apple source bundle can support more than one documentation page.

Architecture and pattern counts come from exact labels in the source-reviewed sample analyses. They are non-exclusive and are not names Apple necessarily uses for the projects. The source excerpts and per-sample pages remain the evidence for each classification.

Shared collaboration shape

flowchart LR
    Entry["App, scene, or controller entry"] --> UI["SwiftUI view or view controller"]
    UI -->|"Intent"| Owner["State owner, coordinator, or view model"]
    Owner --> Boundary["Framework adapter, session, or provider"]
    Boundary --> API["Apple framework"]
    API -.->|"Delegate or callback option"| Boundary
    Boundary -->|"Result or state"| Owner
    Owner -.->|"Observable update option"| UI
    Owner -.->|"Direct controller or frame-loop option"| UI

This is a synthesis of recurring relationships, not a universal application pipeline. The dashed routes are independent options. 40 samples (6.1%) carry both reviewed delegate/callback and observable-state labels.

In controller-based samples, the UI and state-owner nodes often collapse into one view controller. Small demonstrations may also combine the owner and framework boundary. Renderer, GPU, and entity-component samples replace the ordinary state feedback path with a frame or update loop.

Representative source evidence

A state owner also serves as the framework callback boundary.

Building a Custom Catalog and Matching Audio — Part 1 - Matching Audio/FoodMath/Matcher.swift:24

class Matcher: NSObject, ObservableObject, SHSessionDelegate {
    // ...
    private var session: SHSession?
    // ...
}

A composition root creates state and passes it into the UI.

AVCam: Building a camera app — AVCam/AVCamApp.swift:13

struct AVCamApp: App {
    @State private var camera = CameraModel()

    var body: some Scene {
        WindowGroup {
            CameraView(camera: camera)
                .task {
                    await camera.start()
                }
        }
    }
}

A StoreKit sample owns an observable Store as app state.

Understanding StoreKit workflows — StoreKitWorkflows/StoreKitWorkflows/StoreKitWorkflowsApp.swift:12

@main
struct StoreKitWorkflowsExampleApp: App {
    @State private var store = Store()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(store)
            // ...
        }
    }
}

A package manifest enforces one-way module dependencies.

Adopting App Intents to support system experiences — AppIntentsTravelTracking/TravelTrackingShared/Package.swift:21

products: [
    .library(name: "TravelTrackingCore", targets: ["TravelTrackingCore"]),
    .library(name: "TravelTrackingIntents", targets: ["TravelTrackingIntents"]),
    .library(name: "TravelTrackingSnippets", targets: ["TravelTrackingSnippets"])
],
targets: [
    .target(name: "TravelTrackingCore"),
    .target(name: "TravelTrackingIntents", dependencies: ["TravelTrackingCore"]),
    .target(name: "TravelTrackingSnippets", dependencies: ["TravelTrackingIntents"])
]

Common ownership, access-control, and naming lens

The first three excerpts establish three concrete ownership paths. AVCamApp creates and stores CameraModel in private SwiftUI state, then passes that owner-managed instance into CameraView. Matcher strongly stores its optional SHSession behind private access and declares SHSessionDelegate callback capability; the sample source separately assigns session?.delegate = self. Conformance alone would not establish callback routing or retention. The StoreKit app owns an observable Store in private SwiftUI state; @State proves storage and lifecycle at the app boundary, while the Store declaration establishes observation. The package excerpt separately proves one-way module dependencies.

In Swift, private limits use to the enclosing declaration and same-file extensions of that declaration; fileprivate widens access to the file. A declaration with no modifier is internal. public exposes a declaration only up to the effective visibility of its enclosing declaration. open applies to externally subclassable classes and overridable class members. Each sample page records the modifiers actually present instead of inferring intent from a folder or treating every public token as an effective cross-module API.

Names such as View, ViewController, Model, ViewModel, Coordinator, Manager, Session, and Provider are responsibility clues only. Classification follows who creates, stores, mutates, observes, and delegates state—not the suffix.

Application architectures found

This table includes only architecture labels that occur in the reviewed Apple sample analyses. It omits architectures with no source-supported sample.

Recurring implementation mechanisms

These non-exclusive counts use exact reviewed labels for mechanisms that shape state ownership, composition, or framework integration.

Execution context and imported dependency signals

The Actor isolation row above is a source-reviewed classification, not a count of every actor, Task, or async token. An actor does not by itself mean background-thread execution, and asynchronous syntax does not establish an executor. Per-sample analyses therefore distinguish isolation, scheduling, synchronization, and UI handoffs using cited source.

The table below shows the 12 most prevalent import tokens in the current evidence index. It covers 657 sample documents and 643 distinct verified source bundles. The scanner records Swift module imports and Clang or shader import targets, so these are source-level compilation signals—not runtime-use, package-directness, or architecture claims. Local C-family header tokens ending in .h or .hpp are excluded; remaining tokens may still name a local Swift module or a toolchain library.

Combine appears in 92 sample documents and 92 source bundles; Observation appears in 32 documents and 32 bundles. These imports identify available state or event APIs only. They do not establish a reactive architecture, scheduler choice, ownership model, or actual API use.

Recurring design-pattern and collaboration families

Architecture names describe a whole-app organization; design patterns describe smaller recurring collaborations inside it. These non-exclusive counts use exact reviewed labels: 223 documents (33.9%) match more than one displayed family.

Rarer exact families: Singleton 4, Responder chain 3, Composite 2, Decorator 1, Iterator 1, Memento 1.

Important limits: observable state is broader than canonical Observer; a framework bridge is not automatically the GoF Bridge pattern; a finite state machine is not automatically polymorphic State; and target-action does not make every button closure a Command object.

Observed dependency, data-boundary, and layering patterns

These positive, non-exclusive counts describe the concrete boundary shape recorded in the reviewed source; they are not promoted into a broader whole-application label.

Adopting App Intents to support system experiences is the clearest package-level example: its SwiftPM manifest enforces Snippets → Intents → Core, and the executable targets act as composition roots.

Two smaller protocol boundaries show different construction choices:

• Accelerating app interactions with App Intents: ActivityTracker uses a private platform-strategy protocol and selects the live implementation inside the sample.
• Integrating your music app with Apple Intelligence: SpotlightIndexer receives a SpotlightWrapping implementation through its initializer, which also gives tests a substitution seam.

Recurring project and folder structures

These non-exclusive counts come directly from the verified source-tree manifests for 657 sample documents and 643 distinct source bundles. They match path components and project files, not inferred Xcode groups.

No single folder convention dominates every sample. The common shape is an Xcode target-oriented shell with pragmatic role or feature folders; multi-product samples add shared, platform, extension, or Swift-package boundaries when needed.

Representative verified source trees:

Role folders plus separate executable targets. AVCam: Building a camera app

AVCam/
├── Capture/
├── Model/
├── Support/
└── Views/
AVCamCaptureExtension/
AVCamControlCenterExtension/

Swift package targets with one-way dependencies. Adopting App Intents to support system experiences

TravelTrackingShared/
├── Package.swift
└── Sources/
    ├── TravelTrackingCore/
    ├── TravelTrackingIntents/
    └── TravelTrackingSnippets/

Feature and technical-role grouping. Creating a spatial drawing app with RealityKit

RealityKitDrawingApp/
├── Brushes/
├── Canvas/
├── Document/
├── UI/
├── Utilities/
└── Packages/RealityKitContent/

Store names and reducer-style flow found

Parsed declarations in 32 sample documents include a type whose name ends in Store. The role is intentionally broad in Apple samples: purchase and entitlement state, persistence, framework-facing ownership, sync, a storefront view, a retail-location model, and a static cache all occur.

Understanding StoreKit workflows keeps an observable Store in private app-owned state and supplies it through the SwiftUI environment. The type itself is internal, so public members inside it cannot be more visible than that enclosing type.

Origami provides a separate positive event/effect example: an observable Orchestrator accepts typed events, privately reduces them into state changes and typed effects, then privately executes those effects.

Origami/Models/Orchestrator.swift:165

func send(_ event: OrchestratorEvent) {
    // ...
    let effects = reduce(event)
    guard !effects.isEmpty else { return }
    currentTask = Task {
        for effect in effects {
            await execute(effect)
            // ...
        }
    }
}

Naming roles found in source

The table scans parsed declaration names from 657 sample evidence records. Suffixes are matched longest-first and are mutually exclusive: CameraViewModel counts as ViewModel, not Model, and each sample counts at most once per role.

Observed naming rules:

1. A suffix is a responsibility clue, so the analysis checks construction, lifetime, mutation authority, inputs, outputs, and collaborators.
2. ViewController normally owns a UIKit/AppKit view lifecycle. ViewModel is used only when source establishes a view-facing state or behavior owner.
3. Coordinator names navigation, presentation, rendering, and framework orchestration; its prefix and collaborators define the actual scope.
4. Manager and Store are broad nouns. Their source-visible responsibilities matter more than the suffix.
5. Access control is reported separately from naming: app implementation types are commonly implicit internal or narrower, while cross-module APIs need an effective public or open boundary.

Counts represent sample documents unless a source-bundle column is shown. Detailed ownership, access control, and source evidence remain in each linked sample analysis.