Supporting Simulator in a Metal app

At a glance

Project structure

Source bundle/
├── Swift/
│   ├── Renderer/
│   │   └── Renderer.swift
│   └── Application/
│       └── AppDelegate.swift
└── Objective-C/
    ├── Application/
    │   ├── ViewController.m
    │   ├── main.m
    │   ├── WindowSceneDelegate.m
    │   ├── AppDelegate.h
    │   └── AppDelegate.m
    └── Renderer/
        ├── Shaders.metal
        └── ShaderTypes.h

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["Swift / Objective-C app"]
    N2["Renderer"]
    N3["parallel Swift and Objective-C app variants"]
    N4["shared Metal feature with simulator guards"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Swift/Renderer/Renderer.swift:84 — target-specific pipeline and framebuffer policy

        #if os(macOS) || targetEnvironment(simulator)
        blendPipelineState = pipelines[1]
        metalKitView.framebufferOnly = false
        #endif

Interpretation

This is the dominant control/data path: platform code composes Renderer; that object controls parallel Swift and Objective-C app variants; GPU-visible work ends in shared Metal feature with simulator guards. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    ViewController *-- Renderer : _renderer

Ownership evidence

Objective-C/Application/ViewController.m:32 — ViewController creates and stores _renderer

    _renderer = [[Renderer alloc] initWithMetalKitView:_view];

    NSAssert(_renderer, @"Could not initialize renderer");

#ifdef TARGET_IOS
    [_renderer setBlendMode:BlendModeTransparency];
    [_renderer setTransparency:_transparencySlider.value];
#endif

Class and protocol design

Framework delegate conformance is a callback seam; the source does not justify calling the whole app protocol-oriented.

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

Objective-C/Renderer/Shaders.metal:29 — representative GPU entry/helper

vertex ColorInOut vertexShader(Vertex in [[stage_in]],
                               constant Uniforms & uniforms [[ buffer(BufferIndexUniforms) ]])
{
    // ...
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: ViewController, Renderer, AppDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: applicationShouldTerminateAfterLastWindowClosed, application, buildMetalVertexDescriptor, loadTexture, updateDynamicBufferState, uniformsForObject, updateGameState.
• Shader entry points use stage/operation names: vertexShader, fragmentShader, blendFragmentShader.
• Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

• Keep Swift / Objective-C app focused on composition; Renderer is the owner of parallel Swift and Objective-C app variants.
• Treat shared Metal feature with simulator guards 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