Scan-to-CAD/BIM on iOS: From RoomPlan Mesh to Revit-Ready Models

Scan-to-CAD is the process of converting a phone-captured LiDAR scan of a physical space into editable CAD or BIM models - the DWG, Revit, or IFC files that architects, contractors, and facility owners actually work in. On iOS the capture side is nearly solved: Apple's RoomPlan API produces a parametric room model in minutes. The hard, billable part is everything between that model and a file a BIM manager will accept.

This post maps that middle: what RoomPlan really outputs, where the format gap bites, what the market charges for the conversion, and the engineering that separates a demo from a production pipeline.

What does RoomPlan actually give you?

RoomPlan is Apple's room-scanning API: camera plus LiDAR plus two neural networks producing a parametric model - walls, doors, windows, openings, and classified furniture - with dimensions, exported as USD or USDZ. That parametric output is the point: unlike a raw mesh, it knows a wall is a wall.

Its operating envelope is documented by Apple (RoomPlan documentation) and real:

• Recommended room size up to about 9x9 m - larger scenes hit the exceedSceneSizeLimit error developers know well.
• At least 50 lux of light; LiDAR works in darkness but the camera pipeline does not.
• Sessions kept under about 5 minutes before thermal and battery limits degrade capture.

RoomPlan is room-centric by design. It is not a building scanner, and multi-room, multi-floor continuity is your engineering problem, not Apple's.

Why is the export the hard part?

Because Apple and the AEC industry speak different formats, and the semantic translation between them is where projects stall.

The format conversion itself is scriptable. What does not survive automatically is semantics: wall thickness, which side of a wall a surface belongs to, door swing direction, opening boundaries. Developer forums document the same discovery again and again: a beautiful USDZ becomes a Revit model a BIM manager rejects - because downstream trades need walls with correct thickness and hosted openings, not surfaces that merely look right. A pretty mesh with wrong wall semantics is worthless downstream.

What does the market charge for the conversion?

Twindo (formerly Canvas) - the reference business in this niche - sells scan-to-CAD as a service at $0.14 per square foot for 2D outputs and $0.22 for 3D/BIM, delivered in about 1-2 days, with human modelers in the loop for quality (company-reported). It reports over 12,000 customers and 100M+ square feet modeled - which tells you the willingness to pay is proven, and that full automation is still the open prize. Whoever automates the human-in-the-loop step at acceptable quality changes the category's economics.

For product builders the takeaway is the same one we drew in the industry map: monetize the deliverable. Nobody pays for a scan; they pay for the Revit-ready model.

What engineering separates a demo from a production pipeline?

Four problems absorb most of the real budget:

1. Drift. Pose error accumulates as the operator walks. Production mitigations: ARKit anchors, loop closure and keyframing, zero-velocity updates, and - underrated - a coaching UI that makes operators scan slowly and favor structured corners. Software pipeline quality is why identical hardware produces up to 9x different output accuracy across apps (the measured data).
2. Mesh cleanup. The standard pipeline is voxel downsampling, statistical outlier removal, then Poisson surface reconstruction before any export - budgeted as a first-class stage, not a post-processing afterthought.
3. Memory and thermals. LiDAR meshing is among the most power-hungry things a phone does. In the production scanning app we build for a surveying technology company, a 1,000-frame scan initially meant roughly 490 MB of depth data in memory - and a crash around frame 400. The fix was streaming depth maps to disk as 32-bit TIFF during capture, dropping the in-memory frame to about 1 KB of metadata and keeping peak memory under 50 MB on long scans, while a Metal pipeline renders up to 15 million points at 60fps for live operator feedback. That live preview matters commercially: operators see missed corners immediately, which eliminates re-scan site visits.
4. Export semantics. Treat DXF/IFC/E57 export as a product surface with tests, golden files, and versioned tolerances - not a converter script. Open, local, on-device exports are also a sales argument: enterprises are wary of cloud lock-in, and EU buyers read on-device processing as a GDPR feature.

How long does it take to build?

Converged estimates across the industry, matching our own delivery experience:

The step change between tiers is not scanning quality - it is deliverable quality and integration depth. A useful rule from the field: using RoomPlan instead of a fully custom capture pipeline can cut development time by half or more (vendor-reported), which is why the right architecture usually starts with Apple's APIs and spends the savings on the export and QC layers.

Where does this leave a team planning a build?

Three questions decide the scope honestly: which file format does your buyer's system of record demand, what accuracy class does the use case truly need (as-built scoping tolerates 10-20 cm at building scale; fabrication does not), and who fixes semantic errors - software, a human QA step, or your customer discovering them in Revit. The third question is the one that quietly defines the business model.

We build this layer - ARKit/RoomPlan capture, Metal point-cloud rendering, drift control, and the unglamorous export pipelines that make scans land in CAD, BIM, and estimating systems. If you are scoping a scan-to-CAD product or adding capture to an existing platform, talk to us or start with the AR and spatial engineering services page.