Origami: Crafting a dynamic tutorial for Apple Intelligence

At a glance

Project structure

Source bundle/
└── Origami/
    ├── OrigamiApp.swift
    ├── Models/
    │   ├── Orchestrator.swift
    │   └── OrchestratorState.swift
    ├── Brainstorm/
    │   ├── BrainstormView.swift
    │   └── BrainstormModel.swift
    ├── Terms/
    │   ├── TermView.swift
    │   └── TermModel.swift
    ├── Tutorial/
    │   ├── Views/
    │   │   └── TutorialStepTextView.swift
    │   ├── Models/
    │   │   └── TutorialGenerationModel.swift
    │   └── Intelligence/
    │       └── CraftTools.swift
    ├── Projects/
    │   └── LibraryView.swift
    ├── UI/
    │   └── Photos/
    │       └── PhotoView.swift
    └── Coach/
        ├── CoachModel.swift
        └── CoachView.swift

Structure observations

• Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
• Primary languages: Swift.
• The verified tree contains 4 project/configuration file(s) and 134 source declaration(s).

Overall architecture

flowchart LR
    N1["OrigamiApp"]
    N2["ContentView"]
    N3["Orchestrator"]
    N4["Feature models"]
    N5["LanguageModelSession"]
    N6["Foundation Models APIs"]
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N3 --> N5
    N5 --> N6
    N2 -.->|"Event"| N3
    N3 -.->|"Observable state"| N2

Reference code

Origami/Models/Orchestrator.swift:16 — architecture anchor

@Observable
final class Orchestrator {
    let brainstorm: BrainstormModel
    let tutorial: TutorialGenerationModel
    let coach: CoachModel
    let term: TermModel

    var state: OrchestratorState {
        // ...
    }
    // ...
}

Interpretation

The diagram shows the dominant event and state path, not every model or tool. Views send typed events to one observable owner. That owner mutates its state and child models, returns effect values, and executes those effects against its shared language-model session.

Ownership and state

classDiagram
    Orchestrator o-- Project : project
    Orchestrator *-- OrchestratorState : state
    Orchestrator *-- BrainstormModel : brainstorm
    Orchestrator *-- TutorialGenerationModel : tutorial
    Orchestrator *-- CoachModel : coach
    Orchestrator *-- TermModel : term

Ownership evidence

Origami/Models/Orchestrator.swift:69 — stored dependency or nearest verified ownership anchor

init(project: Project, modelContext: ModelContext) {
    self.project = project
    self.state = OrchestratorState(
        mode: project.tutorialJSON != nil ? .tutorial : .brainstorm
    )
    self.brainstorm = BrainstormModel(
        project: project,
        modelContext: modelContext
    )
    // ...
}

Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.

Class and protocol design

Origami/OrigamiApp.swift:13 — representative type boundary

struct OrigamiApp: App {
    // ...
}

No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.

Access control

Reference code

Origami/Brainstorm/BrainstormModel.swift:47 — representative boundary

    private static func decodeIdeas(from data: Data?) -> [BrainstormIdea] {
        // ...
    }

Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.

Logic ownership and placement

Design patterns

Reducer-loop reference code

Origami/Models/Orchestrator.swift:165 — event dispatch remains the only public orchestration entry

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

TutorialTemplateStore is separate from the event/effect loop: it is an enum namespace around a private static template cache.

Naming conventions

• Types: App: OrigamiApp; Orchestrator: Orchestrator; Event/State/Effect: OrchestratorEvent, OrchestratorState, OrchestratorEffect; Model: BrainstormModel, CoachModel, DataModel, ProjectModel, SettingsModel; Recorder: TranscriptRecorder; Renderer: GlyphRevealTextRenderer; Store: TutorialTemplateStore; View: BrainstormView, ButtonBackgroundView, CheckMarkView, CoachView, ContentView.
• Protocols: no local protocol declaration in the scanned source.
• Methods: reduce, playReveal, draw, applyReorder, instantImage, photoImage, instantCaption, setCraftDomain.
• Files: Origami/OrigamiApp.swift, Origami/Brainstorm/BrainstormView.swift, Origami/Terms/TermView.swift, Origami/Tutorial/Views/TutorialStepTextView.swift, Origami/Projects/LibraryView.swift, Origami/UI/Photos/PhotoView.swift.

Architecture takeaways

• OrigamiApp is the main source-visible entry or composition anchor for this sample.
• Orchestrator is the cross-feature owner: it receives typed events, mutates state, creates effects, and executes Foundation Models work.
• The event/effect flow is deliberately centralized: the same owner mutates owner and child-model state, then executes the effects it returns.
• TutorialTemplateStore is a cache namespace, while Orchestrator owns the feature event, state, and effect flow.
• Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
• Access-control conclusions separate verified language visibility from the likely design rationale.
• The source does not justify labeling the design protocol-oriented.

Source map

• Official Apple documentation