Grouping is not merging
ICIDO can group scanned places. A property groups peers at one site — the commit that added them names a garage, a parking lot and a house (5f65fa8). What grouping does not do is fuse them into one model. Each place keeps its own ARWorldMap and its own coordinate frame, and a session relocalizes against exactly one map at a time, so a group is grouping plus switching, never a merged model.
That leaves a plain gap. ARKit world space is metric and gravity-aligned, and its origin is wherever the session started. Scan the garage, then scan the house, and you have two coordinate frames whose origins are two arbitrary spots. Nothing inside either map says where one sits relative to the other, or which way either one is turned. Each map is internally correct and mutually silent.
So a picture of the whole site is not something the maps already contain. It has to be created.
Placed by hand first
The first version of the site plan let you arrange a property's areas by hand (83181f7). Drag each one until the layout matches the site. That is the least clever option available and it is the right first one, because it needs no signal that might not exist — a person who has walked the site knows where the garage is.
Drawing the plan is close to free. Because ARKit's world space has +Y up, a top-down view is simply dropping the Y axis: a world point (x, y, z) becomes the map point (x, z). The same geometry the app already renders as a floor plan is what the site plan lays out.
Two follow-ups made it usable rather than merely present. The plan draws the real maps instead of stand-ins, in the same commit that fixed properties being deleted on every launch (b5c94dd), and the canvas gained pinch to zoom, with a drag on bare ground panning the view (20daa18).
Then from what the scan already recorded
Hand arrangement is a fallback, not an answer. The next step used something the app may already hold: areas can now be arranged from their saved coordinates (4dd2117).
Those coordinates are optional. ICIDO's location use is opt-in and coarse — an approximate location, stored locally alongside the place and never transmitted, which the app otherwise uses to narrow down which saved place you are standing in. Some places will not have one, so places with no real-world location are flagged rather than quietly misplaced (505a8e0).
A coordinate settles position and stops there. It says nothing about which way the map is facing, and a plan with every area in the right spot and the wrong rotation is not a plan. That is what the following day's change addressed: scans now record which way is north, and auto-arrange uses it (4a1019e). Position from one signal, orientation from the other.
The same placement, in three dimensions
Once areas have positions on a plan, the plan is reusable as the placement for a solid model: a whole property renders in 3D, placed by the site plan (5ee1c97). Arranging then became possible from the 3D model itself rather than only from the flat plan (b12c03e), placements gained a height, while stopping the drag from stealing the camera gesture (bbc68e5), and an arrangement in 3D can be cancelled (ee88da6).
Tagged spots came along: a property lists them and draws them in 3D (904e008). Some of this was ordinary repair — the eye button in a property's 3D view did nothing until it was fixed (0f39f34).
Routing across the seam
The reason to place areas correctly is not the picture. It is that a single route could not span two places, which is the direct consequence of every place owning its own frame. Cross-area routing has since shipped, planned by re-planning greedily within each area rather than by computing a list of legs in advance (1316b34), with a release note and a Help entry written for it (de8c7fd).
It also produced the sort of bug that only crossings produce: a cross-area leg flag outlived its route and killed all later navigation (8acb00c). A flag left over from a finished journey is worse than no flag, because what it breaks is the next one.
Sharing, and the boundary that has not moved
A property can be shared as a single file (c4f33f3), which required teaching two separate import paths about them before shared properties would open (4b4cd04). Sharing stays what it has always been in ICIDO: a file you choose to send, going only where you send it.
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, groups 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.