Sample CodemacOSReviewed 2026-07-21View on Apple Developer

Selecting device objects for compute processing

At a glance

Item Summary
Purpose Switch dynamically between multiple GPUs to efficiently execute a compute-intensive simulation.
App architecture Objective-C host code with Metal shaders; AAPLViewController hands work to AAPLRenderer, which owns device-selection controller and simulation before compute renderer on the selected device.
Main patterns Device-selection strategy, Simulation/renderer separation, Fallback policy
Scope High-level review of 13 scanned source files and 7 detected declarations; build assets are omitted.

Project structure

Source bundle/
├── Application/
│   ├── AAPLViewController.m
│   ├── main.m
│   └── AAPLViewController.h
├── Renderer/
│   ├── AAPLShaders.metal
│   ├── AAPLRenderer.m
│   ├── AAPLShaderTypes.h
│   └── AAPLRenderer.h
└── Simulation/
    ├── AAPLSimulation.m
    └── AAPLSimulation.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

Reference code

Application/AAPLViewController.m:138 — feature handoff or setup anchor

@implementation AAPLViewController
// ...
        availableDevices = MTLCopyAllDevicesWithObserver(&metalDeviceObserver,
                                                         notificationHandler);
// ...
@end

Interpretation

This is the dominant control/data path: platform code composes AAPLRenderer; that object controls device-selection controller and simulation; GPU-visible work ends in compute renderer on the selected device. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

Ownership evidence

Application/AAPLViewController.m:191AAPLViewController creates and stores _renderer

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

            if(!_renderer)
            {
                NSLog(@"Renderer failed initialization");
                return;
            }
Owner Object or state Relationship Mutation authority
AAPLViewController _renderer / AAPLRenderer Creates and stores; the diagram uses composition because construction is source-visible. The declaring scope performs setup and replacement.
AAPLRenderer Feature-specific framework and Metal resources Operation-local calls or stored state; exclusive lifetime is not assumed beyond cited evidence. Feature setup/encoding code controls mutation and command submission.

Class and protocol design

Type Responsibility Depends on or conforms to Source
AAPLViewController selects/configures the view and composes the feature objects. NSViewController, MTKViewDelegate Application/AAPLViewController.h:14
AAPLRenderer owns pipeline/resource setup and per-frame command encoding. NSObject Renderer/AAPLRenderer.h:11
AAPLSimulation owns the selected compute device, queue, pipeline, and rotating update buffers for the particle simulation. NSObject, Metal compute resources Simulation/AAPLSimulation.m:30

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

Access control

Symbol Access Verified effect Design reason
AAPLViewController header-visible available to translation units that import the header; this is not Swift public. Keep the usable surface no wider than the collaboration requires. (Application/AAPLViewController.h:14)
AAPLRenderer implementation details implementation-only native helpers, stored state, or registration code stays out of the imported header contract. Hide native implementation details from importing translation units. (Renderer/AAPLRenderer.m:1)
AAPLShaders entry points Metal library boundary host code resolves named shader entry points; Swift access modifiers do not apply. Expose only named shader entry points needed by pipeline creation. (Renderer/AAPLShaders.metal:23)

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

Logic Owning type or file Why it lives there
Selects/configures the view and composes the feature objects AAPLViewControllerApplication/AAPLViewController.h:14 The type’s callbacks and stored state align with this responsibility.
Owns pipeline/resource setup and per-frame command encoding AAPLRendererRenderer/AAPLRenderer.h:11 The type’s callbacks and stored state align with this responsibility.
Device-selection controller and simulation AAPLRenderer / Application/AAPLViewController.m:138 Keeps Metal/framework setup and encoding out of entry or lifecycle code.
Compute renderer on the selected device Renderer/AAPLShaders.metal:23 GPU-parallel code remains in the Metal compilation boundary.

Shader boundary reference

Renderer/AAPLShaders.metal:23 — representative GPU entry/helper

vertex ColorInOut vertexShader(uint                    vertexID  [[ vertex_id ]],
                               const device float4*    position  [[ buffer(AAPLRenderBufferIndexPositions) ]],
                               const device uchar4*    color     [[ buffer(AAPLRenderBufferIndexColors)    ]],
                               constant AAPLUniforms & uniforms  [[ buffer(AAPLRenderBufferIndexUniforms)  ]])
{
    // ...
}

Design patterns

Pattern Source evidence Purpose or tradeoff
Device-selection strategy Application/AAPLViewController.m:138 Makes the sample’s device-selection controller and simulation an explicit, reviewable boundary.
Simulation/renderer separation Application/AAPLViewController.m:191 Makes the sample’s device-selection controller and simulation an explicit, reviewable boundary.
Fallback policy Renderer/AAPLShaders.metal:23 Makes the sample’s device-selection controller and simulation an explicit, reviewable boundary.

Naming conventions

  • Role suffixes make ownership visible: AAPLViewController, AAPLRenderer.
  • Method names describe setup or encoding actions: initWithMetalKitView, generateGaussianMap, loadMetal, setNumRenderBodies, updateProjectionMatrixWithSize, setRenderScale, drawableSizeWillChange.
  • Shader entry points use stage/operation names: vertexShader, fragmentShader, NBodySimulation.
  • 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 AAPLViewController focused on composition; AAPLRenderer is the owner of device-selection controller and simulation.
  • Treat compute renderer on the selected device as a separate execution/compilation boundary with explicit resource and data-layout contracts.
  • The verified ownership edge is AAPLViewController_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

Source file Architectural role
Application/AAPLViewController.m AAPLViewController
Renderer/AAPLShaders.metal ColorInOut
Application/main.m entry point or feature implementation
Renderer/AAPLRenderer.m AAPLRenderer
Simulation/AAPLSimulation.m AAPLSimulation
Renderer/AAPLShaderTypes.h entry point or feature implementation
Application/AAPLViewController.h AAPLViewController
Renderer/AAPLRenderer.h AAPLRenderer
Simulation/AAPLSimulation.h AAPLSimulation