Sebastian Beyer only wanted to train his first Gaussian Splat on a MacBook Air; the run took 3.5 hours, and that wait started an experiment which, four weeks later, had become Scantic, with capture, reconstruction and viewing all living inside an iPhone.12
The easy story says that a pipeline became “1,000 times faster” before being shrunk into a phone, although the published figures tell a more restrained story. Relative to the 3.5-hour baseline, the sub-minute result gives a greater than 210× improvement in the original test; another run took 76.2 seconds on an iPhone 17 for 5,000 iterations, 416,282 splats and 202 images.2
The more interesting jump comes from the workflow itself, which began on a Mac with COLMAP and Brush and ended as a complete loop in a pocket, from capture through reconstruction and training to inspection.2
Three hours
The starting workflow resembled many 3DGS experiments, in which photographs first need camera poses and sparse reconstruction before a collection of Gaussians can be optimised against the source views.5
In the 2023 reference implementation from Kerbl, Kopanas, Leimkühler and Drettakis, training begins from sparse points produced during camera calibration; position, scale, orientation, opacity and colour describe each Gaussian, and optimisation changes that collection until rendered views converge toward the input imagery.5
Beyer says the MacBook workflow used COLMAP for reconstruction and Brush for splatting, with an intentionally unreasonable target attached to the experiment from the beginning: make training 1,000× faster.2
Four weeks later, according to Beyer, the generic desktop chain had given way to a custom pipeline running directly in the iPhone, without LiDAR or cloud processing.2 The App Store describes the same boundary around the product, keeping camera capture, splat generation, processing and 3D inspection inside the device, with no account or remote compute required.1
Those figures belong to a development story, not to a controlled benchmark covering multiple phones, scenes and settings.
Not the first
Scantic entered a field where mobile Gaussian Splatting, including local training, already existed.
Scaniverse 3.0 was already doing all processing on-device in March 2024, starting with the iPhone 11.3 Niantic later described a path from an early workflow needing about 20GB of memory to full processing on a smartphone in roughly a minute.4
That precedent changes the angle. Over the last two years, the absence of cloud processing has already become part of mobile 3DGS through Scaniverse.36
By contrast, Scantic shows how an optimisation problem once tackled by a research and product team can now be rebuilt, at a different scale, by an independent developer until it fits inside a free 18.4MB App Store application.1
Niantic has documented its own reduction work in more detail: the Scaniverse team targeted about 1GB of RAM, repurposed feature detection and multi-view stereo depth mapping to seed the Gaussians, and built the open SPZ format in order to shrink the resulting scan files.4
Scantic's public technical breakdown is much thinner: Beyer describes the starting point, the output and several test parameters, yet leaves too little information about the intermediate algorithms to attribute each speed gain honestly. Filling the gaps would amount to inventing an engineering postmortem that the developer has not published.
Capture first
One visible Scantic decision narrows the problem: the current version begins with capture performed inside the app, and in exchange for that tighter input path the software can organise the acquisition around the rest of its own pipeline.
In the launch discussion, Beyer says that importing an existing photo set is currently unavailable; he considers the feature technically possible, expects it to run more slowly than integrated capture, and may add it later.2
A general pipeline may have to recover relationships among images whose capture path it never controlled, while an app that owns capture can organise information for later stages in advance. The available sources do not identify Scantic's exact algorithm. What they do show is that training an arbitrary dataset and designing an end-to-end mobile scanner involve different engineering problems.
The lack of a LiDAR requirement also matters in this design: Scantic relies on camera imagery, so the workflow is not limited to Pro iPhones equipped with Apple's depth sensor.12
A minute, sometimes
“Under one minute” becomes less tidy once the variation in devices, scenes and settings enters the picture.
Beyer shared a church-statue dataset containing 202 images, for which the fast preset on an iPhone 17 took 76.2 seconds, ran 5,000 iterations and produced 416,282 splats.2 In the same discussion, one iPhone 13 Pro user reports successful operation, while an iPhone 12 Pro user describes training racing to completion without producing a usable reconstruction.2
The developer attributes the latter case to memory pressure, describing the iPhone 12 Pro as being at the edge of what version 1.0 can handle reliably and saying that lower memory use for older devices is already on his list.2
That limit says more than the 1,000× headline. The mobile bottleneck moved instead of vanishing; without cloud compute, the amount of phone memory, the size of the scene, the number of images and the iteration budget all become visible product decisions.
The phone as limit
The original 3DGS work attracted attention by combining an explicit, optimisable representation of the scene with high-quality real-time rendering.5 Less than three years later, attention has also shifted to the rest of the pipeline: how much of the reconstruction workflow can fit in the limits of a mobile device?
Scaniverse had already provided an industrial answer by cutting memory, initialisation work and storage until the process fit on a phone.4 Scantic follows a more individual route, beginning with a hot MacBook and ending, after progressive changes to the generic desktop pipeline, in an App Store tool.12
That trajectory may be the most reusable part of the project. Nothing here demonstrates an iPhone mysteriously running 1,000 times faster than a MacBook. In the long term, the more useful lesson is how changing the entire pipeline can leave the final system solving a different version of the original problem.
Large speed-ups often come from that shift, when several stages change their form and the architecture of the workflow matters more than the acceleration of any single instruction.