Drawing a triangle with Metal 4

At a glance

Project structure

Source bundle/
├── View controller/
│   ├── MetalKitViewDelegate.m
│   └── ViewController.m
├── Shaders/
│   ├── Shaders.metal
│   └── ShaderTypes.h
├── Application/
│   ├── main.m
│   ├── WindowSceneDelegate.m
│   ├── AppDelegate.h
│   └── AppDelegate.m
└── Metal 4 renderer/
    └── Metal4Renderer.m

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; MetalKitViewDelegate 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["MetalKitViewDelegate"]
    N3["Renderer protocol"]
    N4["Metal4Renderer / MetalRenderer"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

View controller/MetalKitViewDelegate.m:37 — feature handoff or setup anchor

@implementation MetalKitViewDelegate
// ...
@end

Interpretation

This is the dominant control/data path: platform code composes MetalKitViewDelegate; that object controls renderer selection behind a shared delegate; GPU-visible work ends in Metal 4 or legacy triangle path. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    MetalKitViewDelegate *-- Metal4Renderer : renderer

Ownership evidence

View controller/MetalKitViewDelegate.m:39 — MetalKitViewDelegate creates and stores renderer

@implementation MetalKitViewDelegate
// ...
            renderer = [[Metal4Renderer alloc] initWithMetalKitView:view];
// ...
@end

Class and protocol design

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

Access control

This sample does not use Swift private, fileprivate, or public for its native boundary. Objective-C/Objective-C++ use header versus implementation placement, C++ uses access specifiers/linkage, Python uses module conventions, and Metal entry points cross a compiled-library boundary; these are not Swift access levels.

Logic ownership and placement

Shader boundary reference

Shaders/Shaders.metal:39 — representative GPU entry/helper

vertex RasterizerData

Design patterns

Naming conventions

• Role suffixes make ownership visible: ViewController, Metal4Renderer, MetalRenderer, Renderer, AppDelegate, MetalKitViewDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: application, scene, sceneDidDisconnect, initWithMetalKitView, updateViewportSize, renderFrameToView, isMissingRequirementsFromView.
• Shader entry points use stage/operation names: fragmentShader.
• Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

• Keep ViewController focused on composition; MetalKitViewDelegate is the owner of renderer selection behind a shared delegate.
• Treat Metal 4 or legacy triangle path as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is MetalKitViewDelegate → 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