Modern rendering with Metal

At a glance

Project structure

Source bundle/
├── Renderer/
│   ├── AAPLRenderer.mm
│   ├── Shaders/
│   │   ├── AAPLMeshRenderer.metal
│   │   └── AAPLShaderCommon.h
│   └── AAPLMesh.h
├── Application/
│   ├── main.m
│   ├── AAPLSettingsTableViewController.mm
│   ├── AAPLAppDelegate.h
│   └── AAPLViewController.h
└── Asset/
    └── AAPLTextureManager.mm

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLRenderer 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["AAPLViewController"]
    N2["AAPLRenderer"]
    N3["scene/mesh/texture subsystems"]
    N4["multi-pass shaders"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Renderer/AAPLRenderer.mm:533 — renderer composes its texture-management subsystem

    _textureManager = [[AAPLTextureManager alloc] initWithDevice:_device
                                                    commandQueue:_commandQueue
                                                        heapSize:TEXTURE_HEAP_SIZE
                                            permanentTextureSize:64
                                                  maxTextureSize:4096
                                               useSparseTextures:_config.useSparseTextures];

Interpretation

This is the dominant control/data path: platform code composes AAPLRenderer; that object controls scene, mesh, and texture-management subsystems; GPU-visible work ends in multi-pass modern renderer shaders. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLRenderer *-- AAPLTextureManager : _textureManager

Ownership evidence

Renderer/AAPLRenderer.mm:533 — AAPLRenderer creates and stores _textureManager

@implementation AAPLRenderer
// ...
@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

Renderer/Shaders/AAPLMeshRenderer.metal:230 — representative GPU entry/helper

vertex AAPLDepthOnlyVertexOutput vertexShaderDepthOnly(AAPLDepthOnlyVertex in                   [[ stage_in ]],
                                                       constant AAPLCameraParams & cameraParams [[ buffer(AAPLBufferIndexCameraParams) ]])
{
    AAPLDepthOnlyVertexOutput out;
    out.position = cameraParams.viewProjectionMatrix * float4(in.position, 1.0);

    return out;
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLCameraController, AAPLSettingsTableViewController, AAPLViewController, AAPLMeshRenderer, AAPLRenderer, AAPLTextureManager, AAPLScene.
• Method names describe setup or encoding actions: initWithDevice, update, getTexture, addTextures, request, setRequiredMip, loadMipsToTexture.
• Shader entry points use stage/operation names: vertexShaderDepthOnly, vertexShaderDepthOnlyAlphaMask, vertexShaderDepthOnlyAmplified, vertexShaderDepthOnlyAlphaMaskAmplified, vertexShader, fragmentGBufferShader.
• AAPL is a sample namespace prefix, not a recommendation for production module naming; retain semantic suffixes such as Renderer, Manager, Scene, or Adapter.

Architecture takeaways

• Keep AAPLCameraController focused on composition; AAPLRenderer is the owner of scene, mesh, and texture-management subsystems.
• Treat multi-pass modern renderer shaders as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLRenderer → _textureManager; 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