ICIDO can keep a backup of a scan while it is still being made. If the scan is interrupted before it is saved, the app is meant to offer it back the next time a scan starts. Build 263 found that this offer had never once been shown. This post covers how that happened and what changed.
Build 263 was uploaded to TestFlight as part of the work on version 1.4. The version on the App Store is 1.3.
What auto-save is supposed to do
Auto-save is on by default, under Settings → Scanning → "Auto-save scans". While a scan runs, ICIDO quietly keeps a backup of the map so far, every half minute once the scan is solid. If the scan is interrupted before it is saved — a crash, or a dead battery — the next scan offers to resume it. Stand where the scanning was happening, tap Resume, and the earlier geometry is picked up once the app recognises the area. The help text advises pointing the phone at something already scanned.
Only the latest scan's backup is kept. It is cleared when the scan is saved or discarded.
The question that could not appear
The release note for build 263 is direct about it. The question "Resume your unfinished scan?" never appeared, not once since auto-save arrived in July. The backups were being written. Nothing could offer them back.
The cause was an ordering problem inside the scan screen. When the screen was created, it immediately settled what kind of scan it was: a new place, or an update to an existing one. The part of the screen that shows the resume question checked first whether that had been settled. It always had, so the question was skipped every time.
Now nothing is settled when the screen is created. The screen holds an empty frame until it appears, checks for a waiting backup, and only then decides. That check runs for every kind of scan. "Start fresh" throws the backup away and carries on with whatever was originally opened.
Two buttons that did the wrong thing
The same audit found a related fault in how scans were started. Both the Home screen and the Places list handed the scanner its instructions in a way that only arrived if the screen happened to refresh in the moment before the scanner opened. On the Simulator, New Scan arrived as a plain new scan every time, and so did Update Map.
In practice, New Scan could skip checking whether the phone was already somewhere it had mapped, and go straight to a new place. Update Map from the Places list could start a brand-new place instead of updating the one chosen. Both screens now pass a single request into the scanner. Measured after the change, New Scan opened in its detect-where-you-are mode, and Update Map opened as an extension of the chosen place.
An interrupted update comes back as an update
The backup already recorded which place an update was extending. Nothing ever read it. An interrupted Update Map would have come back as a separate new place, holding only the part re-scanned before the interruption.
Now a resumed update continues as that update and saves into the same place. Starting Update Map on a place with a waiting backup asks "Finish updating" followed by the place's name. An interrupted new scan is still saved as a new place.
Smaller fixes from the same pass
A saved scan returning as unfinished. Backup writes ran on one queue and clearing ran on another. A slow write could land after a save had already cleared the backup, and bring it back. Both now run in order on a single queue.
A rare crash on save. The path walked during the scan was read while the camera was still adding to it. It is now copied first, on the same thread that adds to it.
"How much is left?" Asked mid-scan, ICIDO's voice answered "The scan looks complete" a few seconds in, while the room was still filling in. The comment on the fix in the code names the problem plainly: that answer was going "to someone who can't see the screen". It now says the scan looks complete only once nothing new has been added for a while. Until then, it says it is still picking up new parts of the room.
Testing the thing that was never tested
Build 262 had shipped with a test step for resuming a scan. That step could not work, because the question it relied on never appeared. Build 263's test plan replaces it with steps that interrupt the app on purpose.
For an update: run Update Map on a place, scan a new corner for a minute, then force-quit ICIDO. Open it, choose Update Map on the same place, and it should ask to finish updating. Resume, let it recognise where it is, scan a little more and save. The place should have the new corner, and no extra place should appear.
For a new scan: scan a new room for a minute, force-quit, then tap New Scan. The resume question should come first, and once the app finds its place, the mini-map should show what was scanned before.
What this one is about
Since July, ICIDO kept a backup of every scan every half minute, and had no way to hand it back. The core of the fix is an order of operations: check for a waiting backup first, then decide what kind of scan this is. The more useful change is the test plan. A recovery feature is now checked by causing the failure it exists for, not by trusting that the path is there.
Scanning needs the LiDAR sensor, available on iPhone 12 Pro and later Pro models.