Update Map is how a saved place grows. It re-enters the same scanning view as a first scan, with the existing map already loaded underneath, and the map extends as new areas are walked rather than starting from a blank sheet. On large places, that flow had a problem: the app was being killed partway through the update. The cause turned out to be a picture drawn to help.
What the preview is for
While a scan is running, ICIDO draws a small top-down sketch of what has been captured so far, so holes are visible before saving rather than after. The sketch is rebuilt about every three seconds. When the scan is an update to an existing place, the saved mesh is shown under the live sketch, so it reads as the whole map growing rather than only the new part.
That rebuild is meant to be cheap. Extraction from ARKit is cached per mesh anchor — the roughly one-metre chunks ARKit hands over — and only the anchors that changed since the last pass are read back out of its buffers. The cost is supposed to track what moved, not the size of the room.
What it was actually doing
The first real evidence came from a log sent in from build 249. The app had been killed during an Update Map on a place whose saved mesh holds 3,906,281 triangles.
The per-anchor caching covered the live scan. It did not cover the base map. Every time the preview rebuilt during an update, the code appended the entire existing map to the list of parts, concatenated everything into a fresh mesh, and rasterised the result into the top-down grid. On that place, that meant an allocation of roughly 100 MB and a 3.9-million-triangle rasterisation, every three seconds, while ARKit was running its own reconstruction of the room alongside it.
That is why the problem appeared only on Update Map, and only on large places. The base mesh exists only when extending — a fresh scan has nothing to append — and it takes a large map to make the repeated work heavy enough to matter.
The preview never needed the full mesh
The preview is a coverage sketch. It shows which parts of the floor have been seen. It does not need every triangle that will end up in the saved file.
So the base map is now decimated once, when it loads, to a budget of 150,000 triangles, and the preview works from that copy. On the 3.9-million-triangle place that is a stride of 27 — roughly one triangle in twenty-seven kept — and the index data drops from 47 MB to 1.7 MB. At the size the sketch is drawn, there is no visible difference. The copy is for the sketch only.
A second leak was found in the same pass. Hiding the ghost of the base map removed only the anchor that displayed it; the mesh behind that anchor stayed resident for the life of the scan controller, long after its session had ended. Pausing the session now releases both copies.
The instrumentation was in the wrong place
The memory logging in builds 237 through 249 explained nothing. The commit says why: memory was being recorded through the update's save step, but the crash happens during scanning. The proof was in the log itself — the only memory line in the whole run was the one written at launch.
The logging now sits where the work actually is: when the base mesh loads, at every preview rebuild, at session start, and on pause.
What is and is not claimed
The commit is explicit about its own standing. In its words, it is "not claiming this as solved"; it is the first hypothesis with evidence behind it rather than reasoning, and the next log would show memory at each rebuild either way. The release note written for version 1.3 five days later states that updating a large map no longer closes the app, and that ICIDO warns if memory runs low during a scan.
Two things about this fix are worth keeping. The first is that a preview should never be built from more data than it can display: a sketch drawn at map scale cannot show the difference between four million triangles and a hundred and fifty thousand, so the four million were cost with no return. The second is that instrumentation placed by reasoning rather than by evidence measures the wrong thing, and the log that finally explained the crash was the one that showed the earlier logs had never been reached.
Scanning needs the LiDAR sensor, which means an iPhone 12 Pro or a later Pro model.