How to Make an App Like MagicPlan

A technical breakdown of what goes into building a room-scanning, floor-plan-generating app: the computer vision stack, the AR frameworks, the data models, and where most teams underestimate the work.

What MagicPlan Actually Does Under the Hood

MagicPlan lets a user point a phone at a room and walk out with a scaled floor plan. That sounds simple. It is not.

At its core, the app combines ARKit (iOS) or ARCore (Android) with LiDAR data on supported devices, a room-segmentation model, and a structured data layer that converts raw spatial measurements into exportable drawings. On devices without LiDAR, it falls back to visual-inertial odometry, which is noticeably less accurate but still usable for rough layouts.

The output is not just a screenshot. MagicPlan exports to DXF, PDF, and its own JSON schema. That schema carries room metadata: area, perimeter, ceiling height, door and window positions. That structured output is what makes the app useful to architects, insurers, and facilities managers rather than just consumers.

If you are building something similar, understanding that distinction matters. You are not building a camera app. You are building a spatial data pipeline that happens to have a camera at the front end.

What Does the Core Tech Stack Look Like?

The stack splits into four layers.

Spatial capture — This is ARKit/ARCore doing SLAM (Simultaneous Localisation and Mapping). The framework tracks the device's position in 3D space using accelerometer, gyroscope, and camera feed. On LiDAR-equipped iPhones (iPhone 12 Pro onwards) and iPads, the depth sensor adds point-cloud data that makes wall detection dramatically more accurate.

Room understanding — Raw SLAM data gives you a point cloud and a camera pose. It does not give you walls. You need a plane-detection and room-segmentation step. Apple's RoomPlan API (introduced at WWDC 2022) does a lot of this automatically on iOS. It outputs a CapturedRoom struct with typed surfaces: walls, doors, windows, openings, and furniture. On Android, Scene Understanding in ARCore gives you plane and object detection, but it is less opinionated than RoomPlan, so you write more of the logic yourself.

Geometry processing — Once you have surface detections, you need to clean the data. Walls rarely align perfectly. Corner detection drifts. You run post-processing: snapping detected wall endpoints to a grid, enforcing right angles where the architecture implies them, merging co-planar segments. This is where most teams spend more time than they expected. Libraries like Open3D or CGAL help, but you still write significant custom logic.

Output and export — The processed geometry goes into your floor-plan data model. From there you generate the visual representation and handle exports. DXF generation is handled well by libraries like ezdxf (Python) or dxf-lib (Node). PDF rendering depends on your stack. If you are targeting architects, DXF accuracy matters more than PDF aesthetics.

Where LiDAR Changes the Numbers

Without LiDAR, wall measurement error on a 4m x 5m room is typically ±5–10 cm using visual odometry alone. With LiDAR, that drops to ±1–2 cm. For insurance assessments or construction planning, that gap is significant. For a simple moving estimate, it probably is not.

Know your use case before you decide which devices to support as first-class.

How Long Does It Take to Build, and What Does It Actually Cost?

Honest answer: a production-quality MVP takes 4 to 6 months with a team of four to five engineers. Here is a rough breakdown.

Component	Estimated Effort
ARKit/ARCore integration + basic SLAM	3–4 weeks
Room segmentation (RoomPlan or custom)	4–6 weeks
Geometry post-processing and snapping	4–8 weeks
Floor plan rendering (2D canvas)	3–4 weeks
Export (DXF, PDF, JSON)	2–3 weeks
Manual editing UI	4–6 weeks
Backend (project storage, sync, sharing)	3–5 weeks
QA, device testing, edge cases	4–6 weeks

The manual editing UI is often underestimated. Users will scan a room and get a result that is 90% correct. They need to fix the remaining 10%. A good editing experience, where users can drag walls, move doors, adjust dimensions, is as much engineering work as the scanning itself.

Cross-platform adds complexity. RoomPlan is iOS-only. If you want feature parity on Android, you reimplement the room-understanding layer using ARCore Scene Understanding and your own geometry logic. Budget an additional 6–10 weeks for that work.

Should You Use RoomPlan or Build Your Own Pipeline?

If your target platform is iOS 16+ and your use case fits the residential or commercial interior category, use RoomPlan. It handles wall detection, furniture classification (it recognises 80+ object types including beds, sofas, and appliances), and outputs a clean CapturedRoom you can work with directly. You skip months of CV research.

The reasons not to use it are specific:

• You need Android support as a first-class target
• Your rooms are industrial, outdoor, or non-rectangular in ways RoomPlan mishandles (long corridors, curved walls, atria)
• You need a custom object taxonomy that RoomPlan's fixed categories do not cover
• You are building on a platform where Apple's framework lock-in is a business problem

In those cases, you build on ARCore's Scene Understanding or go lower-level with a custom model. A PointNet++ or similar point-cloud segmentation model fine-tuned on your target environment type is the usual approach. Expect 8–12 weeks of ML work including data collection if you go this route.

Handling the Backend: What State Needs to Live Server-Side?

The floor plan itself is the obvious artefact. But a production app needs more than file storage.

Projects need versioning. A user scans a room, edits it, shares it with a colleague who edits it further. You need a history model. A simple approach is event sourcing: store each edit operation rather than only the current state. This gives you undo, audit trail, and conflict resolution at low cost.

Sharing and collaboration need access control. Role-based access at the project level (owner, editor, viewer) covers most cases. If you are building for enterprise clients, you will need team-level namespacing and SSO integration.

Media storage matters. Each scan session generates video frames, depth maps on LiDAR devices, and the processed floor plan. Depth maps can be 50–200 MB per room. Decide early whether you store the raw capture data or only the processed output. Storing raw data allows re-processing as your algorithms improve. It costs more in storage and transfer.

A PostgreSQL database with a PostGIS extension handles the spatial metadata well. The floor plan geometry itself stores efficiently as GeoJSON or a custom JSON schema in a JSONB column.

Conclusion

Building a MagicPlan-equivalent is achievable with the right team, but the geometry post-processing and editing UI are where timelines slip. Start with RoomPlan if you are iOS-first. Define your accuracy requirements early — they determine which devices you need to support and how much ML work you actually need. Build the manual editing layer in parallel with the scan pipeline, not after.

If you want a technical review of your planned architecture before you commit to a build, reach out to the team at Sodio. We have built on both ARKit and ARCore and can tell you quickly where your plan is solid and where it will cause problems six months in.

---

FAQ

Can you build a MagicPlan-type app for Android only? Yes, using ARCore and Scene Understanding. You will not have access to RoomPlan's structured output, so you handle room segmentation yourself. Accuracy on non-LiDAR Android devices is lower than on LiDAR-equipped iPhones. LiDAR is available on some Android devices, including recent Samsung flagships, and ARCore supports it.

Do you need a custom ML model, or do the AR frameworks handle everything? For most residential and commercial interiors, RoomPlan (iOS) or ARCore Scene Understanding (Android) handles the core detection without a custom model. You need custom ML work if your rooms are unusual (industrial, outdoor, non-rectangular) or if you need a furniture/object taxonomy the frameworks do not cover.

What accuracy can users realistically expect? On LiDAR-equipped devices, wall measurements are typically within 1–2 cm on rooms up to roughly 50 square metres. On non-LiDAR devices using visual odometry, expect 5–10 cm variance. Factors like lighting, surface texture, and user scanning speed affect accuracy more than most teams anticipate during planning.

How do you handle multi-room floor plans? Each room is scanned individually and produces its own CapturedRoom or equivalent. Stitching rooms together into a whole-floor plan requires aligning coordinate spaces across sessions. This is non-trivial: you typically use shared anchor points or manual alignment in the editing UI to connect rooms. Apple does not yet provide automatic multi-room stitching in RoomPlan.

What export formats should you support from day one? DXF covers professional users (architects, contractors, facilities managers). PDF covers everyone else. A JSON or GeoJSON export of the raw floor-plan data is worth adding early because it makes third-party integrations straightforward. Prioritise based on your target user: consumer apps can skip DXF initially, but professional tools need it from launch.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.