How accurate will the measurements actually be?

It depends on the phone. MEMS accelerometers and gyroscopes vary between models and between individual units, drift over time, and pick up vibration, so we define a tolerance band per device class and test against it. You see the band before development starts, and the app warns the user when a reading sits outside the range it can support.

Can you measure distance or area with the camera instead of a sensor?

Yes, using ARKit and ARCore for plane detection and point measurement, with depth sensors where the device has them. Camera measurement needs reasonable lighting and a textured surface, and accuracy falls off with distance, so it suits layouts and box sizing better than survey work. Most projects pair it with a physical reference the user sets first.

Do users need to calibrate, and how strict is the flow?

Any app that claims repeatable readings needs a zero or reference step. We build calibration against a known reference, such as a flat bench, a spirit level, or a marked height, and store the offset per device so it is not repeated every session. How strict the flow is depends on the tolerance your use case needs.

Will the app drain the battery if the screen stays on?

The display is the largest cost in a measurement session, followed by high sensor sample rates. We size the sample rate to the measurement, pause sampling when the screen sleeps, and aim for a full working day on one charge. iOS and Android both limit background sensor use, so the workflow is built around a session rather than permanent monitoring.

Can we store and export measurement history?

Yes. Readings can be saved locally with timestamps, notes, and photos, and they keep working with no connection. Export runs to CSV or PDF for a job record, and each entry records which device took the reading, because tolerance bands differ between phones.

Sensor & Precision Measurement Apps

Build iOS and Android measurement apps using accelerometers, gyroscopes, cameras, or linked hardware, with calibration and honest accuracy limits.

See our work:

AccuLevels: Precision Measurement Mobile App→CAMERA MIRRORS→Black Box Control→

A phone already carries an accelerometer, a gyroscope, a magnetometer, a barometer, and one or more cameras. Turning that collection into a reading a tradesperson, installer, or surveyor will act on takes more work than printing a sensor value on a screen.

Buyers arrive with one of two stories. An existing utility app draws complaints that its level is off by a degree, or that the same surface reads differently on two phones. Or a new product needs measurements accurate enough to replace a dedicated instrument in one defined workflow. Both stories turn on the same questions: what precision does the hardware support, what does the app do about sensor noise, and what can we honestly claim on the store listing.

What a measurement app can promise

No app adds precision the hardware does not have. A MEMS accelerometer in a mid-range Android phone and the one in a recent iPhone differ in bias, noise, and response to temperature. A gyroscope drifts, so an angle computed from it alone wanders over a few minutes unless something corrects it. Magnetometer readings shift near metal, magnets, and speakers. Camera measurement depends on lighting, surface texture, and distance to the target.

The accuracy figure in your specification is therefore a range, and it is different for each device class you support. We fix that range with you, define a test method that reproduces it, and keep the marketing wording inside what the tests showed. When a reading drifts outside the reliable range, the app says so instead of printing a confident number.

What we do commit to is narrower and more useful: readings that repeat across sessions on the same phone, a calibration path against a known reference, and a documented tolerance that still holds up when a support question arrives six months after launch.

Who this is for

Site and trade work: levels, slopes, plumb checks, alignment, roof pitch
Technicians working alongside a linked instrument such as a Bluetooth laser meter, a clamp, a probe, or a scale
Motion and sport apps that read cadence, swing, stroke, or posture from phone sensors or a watch
Product teams publishing utility apps, including the ones that already have thousands of installs and tired code
Field data capture, where a reading is recorded with time, place, and photo for later reporting or invoicing

What we deliver

Sensor layer and filtering

Raw sensor streams are noisy, and the noise differs by axis and by device. We pick sample rates that suit the measurement, apply the filtering that fits (a low-pass filter for a level, fused attitude for angle work), and expose smoothing as a deliberate trade between responsiveness and stability. Platform APIs such as CoreMotion on iOS and SensorManager on Android need explicit handling: availability checks, permission prompts, and behaviour on a device that has no barometer or magnetometer at all.

Calibration

Users calibrate against a known reference, for example a flat bench, a spirit level, or a wall marked at a fixed height. The offset is stored per device and reapplied automatically. The design also covers what happens when calibration is stale, when a case or magnetic mount changes the reading, and when the app is used in a cold van rather than a warm room.

Units and rounding

Degrees, percent grade, millimetres per metre, inches per foot, millimetres, inches. Display precision has to match the hardware, because showing two decimal places when the sensor varies by more than that teaches users to distrust the tool. We fix a rounding rule per unit, keep stored values at full precision, and round only for display and export.

Measurement history

Sessions are recorded locally with timestamps, notes, and optional photos, and they keep working without a connection. Cloud sync and sharing are added where a team needs them. Export to CSV or PDF produces something a customer can attach to a job record. Each entry notes which device took the reading, since tolerance bands differ between phones.

Screen-on and battery cost

A measurement session holds the screen awake, and that display is the largest drain in the app. Sampling pauses when the screen sleeps, and the sample rate stays at the lowest value the measurement allows. iOS and Android both restrict background sensor use, with Android tightening it further in recent releases, so the workflow is shaped around a session rather than around continuous tracking.

Camera and computer vision

Where the camera is the sensor, we use ARKit and ARCore for plane detection and point measurement, plus depth sensors where the hardware carries them. That combination fits room layouts, box sizing, and rough distances. It does not fit a legal measurement, and the interface says so.

Real-device testing

Simulators return synthetic sensor values or none at all, so every build goes onto a matrix of physical phones across manufacturers and OS versions, held the way your users hold them. We test calibration, drift across a long session, and what happens after a call, a notification, or a screen lock interrupts the tool.

How the engagement runs

A project starts with a short paid discovery: define the measurement, the tolerance, the reference, and the device classes you will support. Then a prototype on two or three real phones, which is where the accuracy conversation becomes concrete before any interface design is committed.

The build follows, covering the sensor layer, calibration, history, export, and store assets. Before launch we run the device matrix, check the behaviours users hit daily, and handle submission to the App Store and Google Play. After launch, our free bug-fixing policy applies to the code we wrote.

What it costs

Work is billed at our flat rate of $39 per hour, or as fixed scope once the measurement and the device list are agreed. A single-purpose utility is often smaller than a full app; a complete cross-platform build with calibration, history, cloud sync, and store submission sits in the range published on the pricing page, where the mobile app MVP is listed at $4,800 to $8,500 across four to six weeks. Adding a second sensor family or a linked Bluetooth instrument extends that timeline. Sustained work runs on the monthly capacity plan from $2,699.

Proof

AccuLevels is a precision leveling and angle app for iOS and Android, built in React Native on the accelerometer and gyroscope with a user calibration flow that zeroes the app against a known reference. It is the closest thing in our portfolio to this exact brief, and it shows how sensor variance between devices is handled before the reading reaches the screen.

Black Box Control puts a rainwater harvesting system under a simple mobile control layer on both platforms. The relevant part is the discipline of translating hardware data into a screen a non-technical owner can read without hesitating.

Camera Mirrors processed live camera frames through custom OpenGL shaders rather than a high-level framework. That work is the reason we can handle the camera as a measurement sensor, where frame timing, resolution, and lighting decide how stable the numbers are.

Related services

Bluetooth and IoT device integration for measurement apps that read a separate instrument over a radio link
Mobile apps development for the full build around the measurement feature
Native iOS app development when the sensor work depends on CoreMotion, ARKit, or LiDAR depth
Wearable and smartwatch app development for motion measurement that runs on a watch rather than a phone
Offline-first mobile development for measurements taken where there is no signal

Next step

Tell us what has to be measured, who will read the result, and how precise it needs to be. We will say which sensors can carry it, what tolerance is realistic, and what the first phase costs.

Contact us with the measurement and the devices you have in mind, or run the idea through the Vasilkoff.info estimator for a first scope and cost range.