← All posts

Product update5 min read

Deciding where to go on the map, not before it

Three ICIDO builds turned the mini-map into the thing you act on: open it full screen, name a spot from across the room, pick a destination on it.

A map too small to answer the question you open it for

While a scan is running, ICIDO draws a live coverage map in the corner of the screen. The commit that changed it puts the problem plainly: at 118 points, that map cannot answer the question you check it to answer — is that far corner actually covered (dfdcd92). Tapping it now opens the full-size version, matching an affordance the navigation screen's mini-map already had.

The full-screen scan map is read-only. There is nothing to route to mid-scan, and follow mode is off, so you can look at a part of the map you are not standing in.

The scan keeps running underneath, which the commit verifies rather than assumes. No frozen camera: an earlier bug of that kind needed two AR views competing for the same camera background, and the new screen contains none. The mesh keeps accumulating: mesh anchors are ingested with no tracking check, and the preview rebuild runs on its own cadence, so the map stays live rather than frozen at the moment it was opened.

Naming a spot from across the room

Tagging a spot used to require standing on it. The method that added a named waypoint read the current device pose, so naming the far corner meant walking to the far corner (53811bf). That commit split out a version taking an explicit world position, and the pose version now calls it. Because it needs no pose, it also works before the device has relocalized.

That made a third entry point possible — a screen with no AR session at all. Places → ⋯ → Map opens a saved place's map on its own, so a building can be labelled without going there. With no pose there is no "you are here" marker, and the height of a new pin is borrowed from an existing tag.

A tag is stored on the place as a name plus a world position, and travels inside exported .spacemap files — so a spot named from a chair is the same object navigation later routes to.

A question added, then deleted a build later

The same build made tapping the mini-map during navigation ask what you meant: route to a tagged spot, route to a point, or name a point. The next build deleted that dialog (a0e4737). The reasoning is in the commit: it asked where you want to go before showing the map — a question about a thing you cannot see yet.

Tapping a mini-map now opens the map, and the choice happens on the map. A tap hit-tests the tags first, with a 26-point radius, because the dots are about 7 points across and hitting one was luck; a tap that misses every tag falls through to bare floor. Picking a tag routes by name, so guidance says "Printer" rather than "That spot". One Tag/Go button flips the same map between going and naming.

Two screens had no map at all. Opening a place from the library showed a spinner over a dimmed camera while relocalization ran, even though the map geometry is loaded long before the position lock. It is drawn now, north-up and without a marker, because there is no position yet and drawing one would be a lie. Find Me, which works out which saved place you are standing in, showed only a name to confirm the match against; it now shows that place's map, which doubles as somewhere to pick a destination before navigation starts. That destination outlives the screen: it is handed back as a place plus an optional tag or world point, and routed on the same located transition that already handled an initial waypoint.

Labels that stay upright while the map turns

Tags carry their names on the map now. In follow mode the map rotates to your heading, so text drawn inside that transform comes out tilted. Labels are therefore drawn in the untransformed context and placed using the forward transform, factored into a single function shared with hit-testing so the two cannot drift apart (53811bf).

Rendering it first caught two defects. At 118 points, three names overlapped each other and the marker, and one clipped off the edge — so labels are now placed nearest-first, nudged inside the bounds, and skipped when they would collide. Three readable names beat six overlapping ones. And seeding the keep-out region at the centre of the view blanked labels in the middle of the map whenever there was no marker there, which is always the case on the session-less map screen. It now seeds at the marker's real screen position, and not at all when there is no pose.

One hue doing four jobs

The map used to be drawn almost entirely in the accent colour: walls, route and tag dots were all the same blue, and furniture sat in a dimmed accent over a grey floor, sinking into it. That read as a flat silhouette rather than a place with things in it.

Each role now has its own colour — turquoise walls, violet furniture, magenta spots, green route, amber for barely-seen cells — with the user marker keeping the accent and becoming the only blue on the map (dfdcd92). It was rendered against the old palette on a simulator first, the commit's reason being that colour is not something to pick from hex values. The next build brightened the floor and gave it an outline, so how much you have scanned reads as a hard edge rather than a fill quietly running out (53811bf).

Where this is

None of this changes what leaves the device, which is nothing. ICIDO has no accounts, no sign-in, no analytics and no network connections; scans, tagged spots and settings stay on the iPhone.

The work described here is in TestFlight builds. ICIDO is coming to the App Store, and scanning requires the LiDAR sensor — iPhone 12 Pro and later Pro models.

Related reading