
How to Make an App Like RoomScan Pro

Building a floor-plan scanning app is a genuinely hard engineering problem. It sits at the intersection of computer vision, sensor fusion, and mobile UX — and most teams underestimate all three. This post walks through what it actually takes to build something comparable to RoomScan Pro, from the core measurement pipeline to the edge cases that will cost you weeks if you're not prepared for them.
What Does RoomScan Pro Actually Do Under the Hood?
RoomScan Pro lets a user walk around a room, tapping walls, and produces a dimensionally accurate floor plan. The deceptively simple UX hides a sensor fusion stack that combines ARKit (on iOS) or ARCore (on Android), the device barometer, accelerometer, gyroscope, and magnetometer. The app triangulates room dimensions using the phone's pose estimation against detected planes, then applies constraint-solving to snap angles to 90° or 45° when the geometry warrants it.
The output is a 2D polygon with measured edge lengths. Behind that polygon is a graph of wall nodes, each with a position in 3D space, projected down to 2D after the scan. Accuracy in a typical rectangular room runs to ±2–5 cm with ARKit on a modern iPhone. That degrades in rooms with glass, dark surfaces, or complex geometry.
There is no magic. It is careful engineering of well-documented APIs with a lot of edge-case handling.
How Do You Build the Core Measurement Pipeline?
Plane Detection and Pose Tracking
ARKit's ARWorldTrackingConfiguration is your starting point on iOS. Enable planeDetection: [.horizontal, .vertical] and you get ARPlaneAnchor updates as the framework builds its internal map. For wall detection specifically, vertical plane anchors are what matter. Each anchor gives you a transform, an extent, and a centre point in world space.
The problem is that ARKit's plane anchors are noisy at edges. A wall detected near a door frame will have an anchor that shifts as more feature points are observed. You need to debounce anchor updates. A practical approach: buffer the last N anchor transforms, compute a rolling median position, and only commit a wall node when the variance drops below a threshold (typically 1–2 cm in practice).
On Android, ARCore's Session.update() loop gives you Plane objects with a similar structure. The plane extent polygon is more explicit than ARKit's bounding rectangle, which can be an advantage in irregularly shaped rooms.
Constraint Solving for Clean Floor Plans
Raw scanned polygons look terrible. Walls come in at 88.3° instead of 90°. Two parallel walls are 1.4 cm off from truly parallel. Users expect a clean architectural drawing.
You need a constraint solver. The approach used in most commercial apps is a variant of least-squares adjustment: you define a set of geometric constraints (right angles, parallel pairs, equal-length pairs where the user has indicated symmetry) and minimise the sum of squared deviations from the raw measurements subject to those constraints. Libraries like G2o or a simple custom implementation using Eigen work well here. The solver runs after each wall tap, not in the AR frame loop.
One honest trade-off: aggressive constraint solving makes plans look clean but can introduce errors of 5–10 cm in rooms that genuinely are not square. Older buildings in particular. Give users a way to toggle constraints off.
Dealing with Multi-Room and Multi-Floor Plans
Single-room scanning is tractable. Connecting rooms is the hard part. When a user moves from one room to the next, the AR world map needs to persist across the doorway. ARKit's ARWorldMap serialisation lets you save and reload a spatial map, but map merge quality degrades as the physical distance from the original tracking origin increases. Beyond 15–20 metres the drift becomes noticeable.
For multi-floor plans, you need to use the barometer to track elevation changes between floors. Combine barometric altitude delta with the AR session's y-axis translation. Neither alone is reliable; together they give you a floor-change detection that works in most cases.
/// Not sure where to start?
Get the architecture before you commit
Tell us what you're building and we'll map the technical approach, stack, and rough timeline. No cost, no obligation, no sales call required.
What Tech Stack Should You Actually Use?
| Concern | iOS Choice | Android Choice |
|---|---|---|
| AR tracking | ARKit 6 (iOS 16+) | ARCore 1.40+ |
| 3D scene graph | RealityKit or SceneKit | Sceneform (deprecated) / custom OpenGL |
| Constraint solving | Eigen via C++ bridged to Swift | Eigen via JNI or Kotlin/Native |
| Floor plan rendering | CoreGraphics / SwiftUI Canvas | Android Canvas / Jetpack Compose Canvas |
| Export (DXF/PDF) | libdxfrw or custom DXF writer | Same via NDK |
| Backend sync | Firebase or custom REST API | Same |
RealityKit is the right choice for new iOS development. SceneKit is mature but Apple's investment is clearly in RealityKit now. On Android, Sceneform was deprecated in 2021; you'll need to either use an actively maintained fork (the io.github.sceneview:sceneview fork on GitHub is the most active as of 2024) or handle the 3D rendering yourself.
For cross-platform, Flutter with ARCore/ARKit plugins (ar_flutter_plugin) is viable for the camera and basic plane detection, but you'll still need platform-specific channel calls for anything advanced. React Native has thinner AR support. If the AR pipeline is central to the product, native is the lower-risk path.
Export Formats and Third-Party Integrations
Architects and contractors expect DXF or PDF output. DXF is the default exchange format for CAD tools including AutoCAD and DraftSight. Writing a DXF file is not complicated — the format is ASCII and well-documented — but generating one that imports cleanly into AutoCAD requires attention to layer naming, unit declarations in the $INSUNITS header variable, and using LWPOLYLINE entities rather than LINE sequences for walls.
PDF export with embedded dimensions is simpler. CoreGraphics on iOS and Android's PdfDocument class both produce vector PDFs. Scale the floor plan to a standard paper size and annotate dimension lines using the wall lengths from your constraint-solved graph.
If you want RoomScan Pro's tier of third-party integration, look at HomeKit (for smart home devices), Matterport's API (for 3D model enrichment), and direct export to SketchUp via SKP format. SKP is a proprietary binary format; there are open-source readers but no clean open-source writer. RoomScan Pro handles this by exporting to DXF and letting SketchUp import that.
Monetisation and App Store Realities
RoomScan Pro uses a freemium model: basic single-room scans are free, multi-room plans and export formats are behind a one-time purchase or subscription. As of 2024, the Pro tier is priced at roughly $7.99 USD as a one-time in-app purchase.
Apple's StoreKit 2 API makes subscription and one-time purchase management significantly cleaner than the original StoreKit. Use Transaction.currentEntitlements to verify purchase state on app launch rather than storing entitlement locally, which is easy to spoof.
App Store review is strict about apps that use the camera. You need a clear Privacy Nutrition Label declaring camera and motion sensor usage. Any AR app that stores scan data remotely needs an explicit data retention and deletion policy in both your privacy policy and the App Store listing.
Conclusion
If you have a team with iOS or Android native experience and six to nine months of runway, building a RoomScan Pro-level app is achievable. The core technical risks are the constraint solver for non-square rooms, multi-room map stitching, and DXF export compatibility. Those three things will eat more time than anything else.
If you're evaluating whether to build this in-house or with a development partner, the most useful first step is a two-week technical spike on just the single-room scan pipeline. That gives you real data on accuracy and frame-rate performance on your target device range before you commit to a full build.
Sodio has built AR measurement and spatial computing features across several mobile projects. If you want to talk through architecture before committing to an approach, get in touch.
FAQ
How accurate can an ARKit-based floor plan app be? In a well-lit rectangular room with textured surfaces, ARKit-based apps typically achieve ±2–5 cm accuracy. Accuracy drops with reflective or dark surfaces, low feature density, and rooms larger than roughly 10 × 10 metres. Multi-room stitching introduces additional drift that compounds with each room added.
Does this work on Android as well as iOS? Yes, but with caveats. ARCore supports a wide device range but plane detection quality varies more across Android hardware than it does across the Apple device line. Budget-tier Android phones with lower-quality IMUs will produce noisier scans. Test on a range of target devices early.
What's the minimum iOS version you need to target? ARKit's vertical plane detection, which is essential for wall measurement, requires iOS 11.3 or later. For RealityKit and the more accurate scene reconstruction features used in advanced apps, iOS 13 is the practical floor. If you want LiDAR-assisted scanning (available on iPhone 12 Pro and later), you're targeting iOS 14+.
Can you use LiDAR to improve accuracy?
Yes. On LiDAR-equipped iPhones, ARKit's ARWorldTrackingConfiguration with sceneReconstruction: .mesh produces a dense mesh of the room rather than sparse feature points. This gives sub-centimetre accuracy for wall positions and handles dark or textureless surfaces that defeat visual SLAM. The trade-off is that this works only on iPhone 12 Pro, 13 Pro, 14 Pro, 15 Pro, and iPad Pro models with LiDAR.
How long does it realistically take to build this? A single-room scan app with basic export can be production-ready in three to four months with two experienced mobile engineers. Adding multi-room stitching, DXF export, and a backend sync layer brings it closer to eight to twelve months. The constraint solver and edge-case handling in the AR pipeline are the biggest time sinks, not the UI.
Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.
/// Work with us
Talk to the engineers who'd build it
You'll get a technical scope, timeline and cost estimate from the people doing the work, not an account manager. In-house team, no subcontracting, since 2016.
