Customizing shaders using function pointers and stitching

At a glance

Project structure

Source bundle/
├── Renderer/
│   ├── AAPLRenderer.m
│   ├── AAPLShaders.metal
│   └── AAPLShaderTypes.h
└── Application/
    ├── AAPLRenderViewController.m
    ├── main.m
    ├── iOS/
    │   └── AAPLSplitViewController.m
    ├── WindowSceneDelegate.m
    ├── AAPLAppDelegate.m
    └── AAPLAppDelegate.h

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["AAPLConfigurationViewController"]
    N2["AAPLRenderer"]
    N3["function-table and stitched-function construction"]
    N4["indirectly selected shader functions"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Renderer/AAPLRenderer.m:116 — feature handoff or setup anchor

@implementation AAPLRenderer
// ...
    MTLFunctionStitchingInputNode *zInput = [[MTLFunctionStitchingInputNode alloc] initWithArgumentIndex:0];
// ...
@end

Interpretation

This is the dominant control/data path: platform code composes AAPLRenderer; that object controls function-table and stitched-function construction; GPU-visible work ends in indirectly selected shader functions. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLRenderViewController *-- AAPLRenderer : _renderer

Ownership evidence

Application/AAPLRenderViewController.m:53 — AAPLRenderViewController creates and stores _renderer

@implementation AAPLRenderViewController
// ...
    _renderer = [[AAPLRenderer alloc] initWithMetalKitView:_view];
// ...
@end

Class and protocol design

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

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/AAPLShaders.metal:29 — stitchable arithmetic functions

[[stitchable]] float2 add(float2 a, float2 b)
{
    return a + b;
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLConfigurationViewController, AAPLRenderViewController, AAPLSplitViewController, AAPLRenderer, AAPLAppDelegate, AAPLWindowSceneDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: scene, sceneDidDisconnect, application, applicationShouldTerminateAfterLastWindowClosed, viewDidLoad, selectVisualizationType, selectOperation.
• Shader and callable-function names state their role: mandlebrotFragment, colorEscaped, add, subtract, multiply, and negate.
• 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 AAPLConfigurationViewController focused on composition; AAPLRenderer is the owner of function-table and stitched-function construction.
• Treat indirectly selected shader functions as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLRenderViewController → _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