Mixing Metal and OpenGL rendering in a view

At a glance

Project structure

Source bundle/
├── Application/
│   ├── AAPLOpenGLMetalInteropTexture.m
│   ├── AAPLOpenGLViewController.m
│   ├── main.m
│   ├── WindowSceneDelegate.m
│   ├── AAPLAppDelegate.h
│   └── AAPLOpenGLViewController.h
└── Renderer/
    └── Metal/
        ├── AAPLShaders.metal
        ├── AAPLMetalRenderer.m
        └── AAPLShaderTypes.h

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLMetalRenderer 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["AAPLMetalViewController"]
    N2["AAPLMetalRenderer"]
    N3["separate Metal and OpenGL renderers"]
    N4["shared-view interoperability and presentation"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Application/AAPLOpenGLMetalInteropTexture.m:187 — Core Video texture bridge between APIs

    cvret = CVMetalTextureCacheCreate(
                    kCFAllocatorDefault,
                    nil,
                    _metalDevice,
                    nil,
                    &_CVMTLTextureCache);

    NSAssert(cvret == kCVReturnSuccess, @"Failed to create Metal texture cache");

Interpretation

This is the dominant control/data path: platform code composes AAPLMetalRenderer; that object controls separate Metal and OpenGL renderers; GPU-visible work ends in shared-view interoperability and presentation. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLOpenGLViewController *-- AAPLOpenGLRenderer : _openGLRenderer

Ownership evidence

Application/AAPLOpenGLViewController.m:55 — AAPLOpenGLViewController creates and stores _openGLRenderer

    _openGLRenderer = [[AAPLOpenGLRenderer alloc] initWithDefaultFBOName:_defaultFBOName];

    NSAssert(_openGLRenderer, @"OpenGL Renderer failed initialization");

    _metalDevice = MTLCreateSystemDefaultDevice();

    _metalRenderer = [[AAPLMetalRenderer alloc] initWithDevice:_metalDevice
                                              colorPixelFormat:AAPLOpenGLViewInteropPixelFormat];

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/Metal/AAPLShaders.metal:22 — representative GPU entry/helper

vertex ColorInOut vertexShader(              uint           vertexID [[ vertex_id ]],
                               const device  AAPLVertex   * in       [[ buffer(AAPLBufferIndexVertices) ]],
                               constant      AAPLUniforms & uniforms [[ buffer(AAPLBufferIndexUniforms) ]])
{
    // ...
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLMetalViewController, AAPLOpenGLViewController, AAPLMetalRenderer, AAPLOpenGLRenderer, AAPLOpenGLView, AAPLAppDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: initWithDevice, useInteropTextureAsBaseMap, useTextureFromFileAsBaseMap, resize, updateState, drawToTexture, drawToMTKView.
• Shader entry points use stage/operation names: vertexShader, fragmentShader.
• 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 AAPLMetalViewController focused on composition; AAPLMetalRenderer is the owner of separate Metal and OpenGL renderers.
• Treat shared-view interoperability and presentation as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLOpenGLViewController → _openGLRenderer; 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