A Multi-Sensor Consumer Privacy Application for Detecting Concealed Recording Devices

Delivered remotely for a business based in Munich, Germany. Names withheld by agreement.

Project Overview

Industry: Consumer privacy and personal security utilities.

Type of solution: A self-contained native iOS application with on-device sensor processing, hosted content services, and freemium monetisation.

Business context: Concern about concealed recording devices in rented accommodation, hotels and changing facilities is a real and growing consumer anxiety, and a category of apps has grown up to serve it. Most of them are not useful. They implement a single detection approach — typically a magnetometer readout — and present it with enough theatre to feel convincing until the user notices it reacts identically to a door hinge. That gap between the anxiety and the quality of the available tools was the commercial opportunity.

General users: Consumers checking a space they are occupying — travellers, renters, and anyone with reason to be concerned about privacy in an unfamiliar room.

General purpose: To give a non-technical person several independent ways to check a space, and enough interpretation to know what the results mean.

The Business Challenge

One detection method is not enough to be trustworthy. Any single sensor reading in this domain is ambiguous. Magnetic readings respond to any ferrous object; optical reflection responds to any shiny surface. Without corroboration, a positive result carries almost no information.

False positives destroy the product. A tool that alarms constantly trains its user to disregard it — which means it fails precisely in the case it exists for. Restraint matters more than sensitivity.

The user is anxious and not technical. Someone using this application is already uneasy. Presenting raw sensor values would be both unhelpful and distressing. The interpretation layer is as important as the detection itself.

Modern cameras are network devices. A concealed camera that is optically hidden and magnetically unremarkable may still be connected to the local network — a completely different detection surface that most competing products ignore entirely.

Real-time frame analysis is demanding. Analysing camera frames as they arrive, on the device generations this category needs to support, is at the edge of what an interpreted layer can do comfortably.

Occasional-use utilities are hard to monetise. People use a tool like this a few times a year. Subscription alone would not convert; advertising alone would not sustain. The model had to accommodate both usage patterns.

Sustained sensing drains batteries. Scanning uses camera, motion sensors and networking simultaneously, in a situation where the user may be away from a charger.

Our Approach

Build three independent detection paths, deliberately. The product's entire credibility rests on corroboration. Magnetic sensing, optical analysis and network discovery have uncorrelated failure modes — a metal fixture that triggers one will not trigger the others — so agreement between methods carries real information in a way that any single reading cannot. This was the founding decision and everything else followed from it.

Treat network discovery as a first-class method. Because many concealed cameras are network-connected, host discovery across the local network was built as a full detection modality rather than an afterthought. It finds a class of device the other two methods cannot see at all, and it is the capability most competing products omit.

Drop into C++ where performance requires it. The optical analysis path processes camera frames as they arrive, which is not a workload to leave in a higher-level layer on older hardware. The analysis is implemented in C++ with a bridging layer into the interface code — a deliberate, contained use of a lower-level language exactly where it earns its complexity.

Make interpretation part of the product. Onboarding, information content and guidance were built as core features rather than help-screen afterthoughts, because a reading the user cannot interpret is not a result. The product's job is to help someone decide what to do, not to display a number.

Let users record what they find. Photo capture with a review view turns a momentary reading into something durable — evidence a user can keep, show to someone, or act on. That is the difference between a scanner and a tool.

Monetise for both usage patterns. Advertising covers the occasional user who scans a hotel room twice a year; subscription serves the frequent user who wants an uninterrupted experience. Neither model alone fits a utility used sporadically.

Keep the backend footprint minimal. With no server-side business logic — all detection runs on the device — remote content and configuration are served from a hosted realtime database rather than bespoke infrastructure, keeping operating cost proportionate to a consumer utility.

The Solution

Magnetic field detection. Device motion sensing identifies magnetic characteristics associated with electronic devices, giving the user a first, fast way to sweep a space.

Optical lens detection. The camera pipeline feeds custom image analysis that looks for the distinctive optical signature a lens produces — a method that finds devices with no meaningful magnetic signature at all.

Local network discovery. Host discovery across the local network identifies network-connected devices present in the space, covering the increasingly common case of a camera that is neither visible nor magnetically detectable but is quietly connected to the same Wi-Fi.

Guided onboarding. A walkthrough introduces the detection methods and how to use them, because the techniques are only effective when applied properly — sweep speed and proximity both matter.

Interpretation and guidance content. In-app information explaining what each method detects, what a result does and does not mean, and what to do next.

Photo capture and review. Users photograph anything they find, with a detail view for reviewing captures — turning a transient reading into a durable record.

Progress and feedback during scanning. Custom animated indicators and audible feedback give the user clear, continuous signalling during a scan, which matters when their attention is on the room rather than the screen.

Subscription and advertising. A subscription removes advertising and unlocks the full experience, while advertising supports free use — accommodating both the occasional and the frequent user.

Content and communication. Remotely served content, email capture with mailing-platform integration, and push notification support for reaching users after installation.

Key Features

Three independent detection modalities Magnetic, optical and network-based detection with uncorrelated failure modes, so results can corroborate one another instead of resting on a single ambiguous reading.

Local network host discovery Detection of network-connected devices present in the space — a class of device invisible to both magnetic and optical methods, and one most competing products do not attempt.

Camera-based optical analysis with C++ processing Per-frame analysis of the camera feed implemented in a lower-level language for throughput on older hardware, bridged cleanly into the native interface layer.

Magnetic field sensing Device motion sensing providing a fast initial sweep of a space for magnetic signatures associated with electronic devices.

Interpretation-first design Onboarding, guidance and explanatory content treated as core features, because a sensor reading a user cannot interpret is not a usable result.

Photo capture and review Findings can be photographed and reviewed, turning a momentary detection into a durable record the user can act on.

Clear in-scan feedback Custom animated progress indicators and audible cues providing continuous signalling while the user's attention is on the room rather than the screen.

Hybrid monetisation Advertising for occasional users and subscription for frequent ones, matched to the sporadic usage pattern of a utility application.

Minimal backend footprint All detection runs on the device, with only content and configuration served remotely — keeping operating cost proportionate to a consumer utility.

Technical Architecture

Detection layer. Three independent pipelines, each reading a different sensor surface: device motion for magnetic sensing, the camera capture pipeline for optical analysis, and platform networking for local host discovery. Each produces results independently, and the interface presents them together.

Image analysis layer. Camera frames are processed through custom analysis implemented in C++ with supporting data-structure utilities, bridged into the application through Objective-C++ so the performance-critical path stays out of the interface layer.

Presentation layer. Native interface code composing scanning, results, capture, review, information and subscription flows, with custom animated indicators providing continuous scan feedback.

Media layer. Camera capture, image handling and photo review, with audible feedback for capture events.

Content and configuration layer. A hosted realtime database serving remote content and configuration, avoiding bespoke backend infrastructure for an application with no server-side business logic.

Monetisation layer. Platform in-app purchase handling behind a purchase wrapper with a dedicated subscription interface, alongside an advertising integration for non-subscribed use.

Instrumentation layer. Analytics, crash reporting and push notification support for understanding real-world usage and reaching users after installation.

Flow: Device sensors (motion / camera / network) → Three independent detection pipelines → C++ analysis on the optical path → Interpretation and presentation → Photo capture and review → Hosted content and configuration

Technology Stack

Technical Challenges & Solutions

Security & Reliability

Permission-scoped sensor access. Camera, motion and local network access are requested through the platform permission model, each intrinsic to a specific detection method rather than requested speculatively.

On-device processing. All detection and analysis runs locally on the device. Sensor data and camera frames are processed on the handset rather than transmitted for server-side analysis, which is the appropriate design for an application used in private spaces.

Minimal data footprint. With no server-side business logic and no user account model, the application holds no meaningful personal dataset — remote services carry only content and configuration.

Measured presentation of results. The interface is built to communicate what each method indicates rather than to present findings as definitive, because a detection tool that overstates its certainty misleads users in both directions.

Instrumentation. Crash reporting and analytics provide visibility of real-world failures and usage across a wide range of device generations.

Platform-managed purchases. Subscription entitlement is handled through the platform's own in-app purchase infrastructure behind a dedicated purchase wrapper.

Scalability & Performance

On-device detection. Because all processing happens on the handset, the application's capacity is not bounded by server infrastructure and its operating cost does not scale with usage.

Native and lower-level processing. Per-frame image analysis in C++ keeps the optical detection path viable on older devices, where an interpreted implementation would not sustain the frame rate.

Bounded scan operations. Scanning runs as discrete bounded operations rather than continuous background sensing, limiting battery and thermal impact.

Lightweight scan-time interface. Custom lightweight animations provide feedback during scanning without competing with the detection pipelines for processing capacity.

Cached remote content. Remote imagery loads through a caching loader, keeping content responsive without repeated fetching.

Minimal backend dependency. A hosted realtime database for content and configuration means there is no bespoke infrastructure to scale, monitor or maintain.

Business Outcomes

• Results can be corroborated, because three independent methods with uncorrelated failure modes replace a single ambiguous reading.
• A whole class of device is detectable that sensor-only competitors cannot find, through local network discovery.
• Users can interpret what they are seeing, because guidance and explanation were built as product features rather than help content.
• Findings become durable, through photo capture and review rather than a reading that disappears when the screen changes.
• The application performs on older hardware, because the demanding analysis path was implemented at the right level.
• Both usage patterns are monetised, with advertising for occasional users and subscription for frequent ones.
• Operating costs stay proportionate, since detection runs entirely on the device and the backend footprint is minimal.

Why it worked

Utility applications look simple from the outside and are frequently where engineering judgement matters most, because there is nowhere to hide. There is no feature list to distract from the fact that the core function either works or does not.

Our team built this one around a single honest observation: any one sensor reading in this domain is ambiguous, so a product resting on one method cannot be trustworthy however well it is presented. Three independent methods with uncorrelated failure modes is a harder engineering commitment — three pipelines, three sets of failure characteristics, three things to explain to the user — and it is the only version worth building. We then put the demanding work where it belonged, dropping into a lower-level language for per-frame analysis while keeping that code contained rather than letting it spread.

We also treated interpretation as engineering scope. For a product whose users are anxious and non-technical, the difference between a number on a screen and a decision the user can make is the entire value of the application. Our teams work across native mobile with direct sensor, camera and networking integration, performance-critical processing, and platform monetisation — and, importantly, know when a product's real challenge is not the code but what the code is asking the user to understand.

Final Summary

Concern about concealed recording devices in unfamiliar spaces is real, and the applications addressing it are mostly theatre — one sensor, one dial, and an alarm that reacts to the nearest door hinge. Users work that out quickly, and the category's credibility suffers for it.

Our team built a native iOS application on the opposite premise: that a single reading in this domain is ambiguous by nature, so trustworthiness has to come from corroboration. Three independent detection methods run in the product — magnetic sensing through device motion, optical analysis of the camera feed, and local network host discovery — chosen specifically because their failure modes do not correlate. The network method matters disproportionately, because it finds connected cameras that are invisible to both of the sensor-based approaches and that most competing products do not attempt to detect at all.

The optical path processes camera frames through analysis implemented in C++ and bridged into the native interface, keeping it viable on older hardware. Around the detection core sit the things that make the results usable: onboarding and guidance that explain what each method indicates, photo capture so a finding becomes a durable record, and clear feedback during scanning for a user whose attention is on the room rather than the screen. A hybrid advertising and subscription model matches the sporadic way a utility like this is actually used, and with all detection running on the device, the backend footprint — and the operating cost — stays proportionate to what the product is.