MetalSplatter renders Gaussian Splats with Metal on Apple hardware

Splat files are the input, not meshes

MetalSplatter renders scenes produced by the 3D Gaussian Splatting technique described in the original radiance field paper, which the README links to the Inria project page. That means the input is not a mesh, a texture atlas, or a USDZ file. It is a set of splats stored as PLY, SPZ, or .splat, and the library's job is to draw millions of anisotropic primitives efficiently on a Metal backend.

The audience is Apple platform developers. The README names iOS on iPhone and iPad, macOS, and visionOS for Vision Pro, and the visionOS path relies on amplification to render the scene in stereo. The sample app carries Apple's template code underneath, so the intended reader is someone comfortable dropping a package into an Xcode project rather than someone who wants a command line tool.

The project also positions itself as a rendering layer only. It does not train anything. The README points at Nerfstudio for training splats from camera or drone captures, and at scene data from the original paper and at SplatMart for ready-made PLY and SPZ scenes. Training, capture, and evaluation all live elsewhere.

Four modules with a converter directory the README never lists

The repository layout splits the work into modules with narrow jobs. MetalSplatter is the core library that renders a frame. PLYIO reads and writes binary and ASCII PLY files, and the README explicitly invites reuse of it standalone for anyone who just wants to load PLY files. SplatIO sits on top of PLYIO and interprets PLY and .splat payloads as sets of splats. SampleApp is a deliberately minimal demonstration built on Apple's template code. SampleBoxRenderer is described as a drop-in replacement for MetalSplatter that draws the cube from Apple's Metal template instead, which makes it a debugging aid rather than a feature.

The top-level tree also contains a SplatConverter directory that the module list in the README does not mention. The README lists MetalSplatter, PLYIO, SplatIO, SampleApp, and SampleBoxRenderer, and the repository entries add SplatConverter alongside them, along with Package.swift and LICENSE. Whether the converter is a supported command line entry point or an internal tool is not documented, so anyone planning to batch-convert assets should open that directory and read Package.swift rather than assume a tool exists.

The dependency direction is the interesting part. SplatIO depends on PLYIO, and the rendering core depends on SplatIO. That means file parsing can be tested without a GPU context, and the parsing layer is the part most likely to be reused outside rendering.

The sample app is the entire onboarding flow

There is no install script to copy and no package snippet in the README. The setup path is entirely manual: get a splat file from the listed sources, clone the repository, open the Xcode project that lives with the sample app, and run. The README states the steps plainly and points at SampleApp/MetalSplatter_SampleApp.xcodeproj:

2. Clone the repo and open SampleApp/MetalSplatter_SampleApp.xcodeproj

If the target is iOS or visionOS, the reader has to set the development team and bundle identifier under Signing & Capabilities, because the project ships without personal signing configuration. On macOS the README says there is nothing to configure.

The one instruction that has a large performance consequence is the scheme setting. The README says the scheme must be set to Release mode, and explains that loading large files in Debug is more than an order of magnitude slower. That is a concrete instruction rather than a general tuning note, and it is the first thing that will make or break a first run. There is also a note that framerate improves when the debugger is detached, which means profiling from Xcode under the debugger gives numbers you cannot reproduce from the Home screen.

Missing documentation is the project's own stated limitation

The README does not pretend otherwise. It says outright that the documentation is entirely missing and calls it a major TODO list item, and it qualifies the sample app with the expectation that it will not teach you much. It is a rare case where the project states its own gap in the same sentence as the feature list.

What that means in practice is that the public API surface has to be read from source. The README never names a view type, a renderer class, a delegate, or a configuration property. It never describes how the scene's transform is applied, whether lighting is baked into the splats or computed, how stereo amplification is configured, or whether splat opacity, sorting, or depth compositing can be adjusted. It also does not document a rollback path or a version compatibility policy for the .splat format.

For a library at version 1.0.1, that gap matters more than it would for a tool with a conventional CLI. A researcher who only needs to view a splat can live with the sample app. A product team that needs a custom camera rig, a capture button, a share sheet, or a save to Photos has to read the MetalSplatter module source to learn the entry points.

PLYIO alone can replace a hand-rolled PLY parser

The README highlights PLYIO as standalone and standalone-useful, which makes it the most portable piece of the project. It handles binary and ASCII PLY files, and it is the layer that SplatIO then interprets as splat sets. Any team currently maintaining its own PLY reader for a 3D pipeline has a candidate here, and the fact that it carries an independent module boundary rather than being buried inside the renderer suggests it was kept separable on purpose.

The alternative to using it is writing and testing a binary PLY parser with a mixed property layout and handling both ASCII and binary encodings. That is a well-known source of subtle bugs in 3D asset tooling, particularly when property order and element counts vary between exporters. The trade-off is that PLYIO comes as part of this package set rather than as a separate dependency, so adopting it means taking a dependency on the repository rather than on a narrowly scoped package.

If the real goal is only to turn PLY into .splat or to inspect files, the SplatConverter directory is the place to look, though the README does not document its command line interface, arguments, or output formats.

SampleBoxRenderer separates integration bugs from rendering bugs

SampleBoxRenderer is described as a drop-in replacement for MetalSplatter that renders the cube from Apple's own Metal template. That sounds trivial until you consider what it isolates. If a scene fails to appear, the fault lies in one of three places: the file did not load, the integration with MetalSplatter is wrong, or the renderer itself cannot draw the scene. Swapping in the box renderer removes the middle and third possibilities.

This is a pattern worth copying even when the project itself is not adopted. A stub renderer that implements the same interface as the real one turns a vague black screen into a binary question. The cost is that MetalSplatter's public protocol and type names have to be known precisely for the substitution to work, and the README does not publish them. Finding them means reading the module source, which circles back to the documentation gap.

The README also points to a showcase of downstream work, including an official Vision Pro viewer app that adds camera controls and a splat gallery, and a demo app for dynamic 3DGS with instance aware region selection based on clicking and text prompting through MobileCLIP. Those projects are separate codebases and are not part of this package.

Release cadence and what it costs to keep up

The repository is not archived, and the last push was on 2026-09-02. Recent tags show 1.0.0 on 2026-02-02 and 1.0.1 on 2026-02-20, with an earlier 0.1.1 tagged Smaller, faster in February 2024. The version history suggests the API surface reached 1.0 early in 2026 and has seen small releases since, with a gap of several months between the two 1.0 tags that the repository history does not explain.

The licence is MIT, which is the permissive end of the scale. It allows use in closed-source apps, and the README's own showcase lists a non-open-source Vision Pro app built on the library, which confirms that pattern in practice. No licence compatibility analysis is needed for internal use, though redistribution terms still apply.

Upgrading cost is tied to the missing documentation rather than to the licence. Because there is no written API reference, a version bump is reviewed by diffing the module source, and downstream teams are the ones paying that cost. Anyone considering this library for a shipping product should budget for reading MetalSplatter, SplatIO, and PLYIO directly rather than waiting for documentation that the README calls a major TODO.

Editorial conclusion

MetalSplatter fits teams that already have trained splat files and need them on Apple hardware, especially on Vision Pro where stereo rendering is built in; it does not fit anyone who needs training, a desktop renderer, or a documented API surface. Before adopting, open the five package targets in Package.swift, confirm your scene files load in the sample app in Release mode, and budget time to read the sources yourself, because the README states the documentation is entirely missing.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. scier/MetalSplatter on GitHub