Rendering a scene with deferred lighting in Swift

At a glance

Project structure

Source bundle/
├── Application/
│   ├── ViewController.swift
│   ├── AppDelegate.swift
│   └── WindowSceneDelegate.swift
└── Renderer/
    ├── Shaders/
    │   ├── AAPLPointLights.metal
    │   └── AAPLShaderCommon.h
    ├── Renderer.swift
    ├── Scene.swift
    ├── SinglePassDeferredRenderer.swift
    └── TraditionalDeferredRenderer.swift

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; Renderer is the principal feature coordinator.
• GPU-specific logic stays in Metal shader files; shared headers bridge host/shader layouts where present.
• The tree above is intentionally pruned to composition, resource, and shader files.

Overall architecture

flowchart LR
    N1["ViewController"]
    N2["Renderer"]
    N3["base renderer with two concrete strategies"]
    N4["single-pass or traditional deferred shaders"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Application/ViewController.swift:48 — feature handoff or setup anchor

class ViewController: PlatformViewController {
    // ...
}

Interpretation

This is the dominant control/data path: platform code composes Renderer; that object controls base renderer with two concrete strategies; GPU-visible work ends in single-pass or traditional deferred shaders. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    ViewController *-- SinglePassDeferredRenderer : renderer

Ownership evidence

Application/ViewController.swift:48 — ViewController creates and stores renderer

class ViewController: PlatformViewController {
    // ...
}

Class and protocol design

A local protocol/conformance boundary is present, so protocol-oriented collaboration is claimed only for that seam.

Access control

Swift’s default is internal; private and fileprivate above use Swift semantics. No public or open app API is inferred when the sample only needs one target. Objective-C/Objective-C++ instead use header versus implementation placement, C++ uses access specifiers/linkage, Python uses module conventions, and Metal entry points cross a compiled-library boundary—none is interchangeable with Swift public.

Logic ownership and placement

Shader boundary reference

Renderer/Shaders/AAPLPointLights.metal:25 — representative GPU entry/helper

vertex LightMaskOut

Design patterns

Naming conventions

• Role suffixes make ownership visible: ViewController, Renderer, SinglePassDeferredRenderer, TraditionalDeferredRenderer, Scene, BufferView, AppDelegate.
• Method names describe setup or encoding actions: application, applicationDidFinishLaunching, applicationWillTerminate, applicationShouldTerminateAfterLastWindowClosed, beginFrame, beginDrawableCommands, endFrame.
• Shader entry points use stage/operation names: skybox_vertex, skybox_fragment, fairy_vertex, fairy_fragment, shadow_vertex, gbuffer_vertex.
• Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

• Keep ViewController focused on composition; Renderer is the owner of base renderer with two concrete strategies.
• Treat single-pass or traditional deferred shaders as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is ViewController → renderer; broader exclusive ownership is not inferred.
• Access-control rationale follows concrete language boundaries rather than translating every header or shader symbol into Swift terms.

Source map

• Official Apple documentation