Mobile App Development for Smart Home (Electronic Locks/Doorphones)

Mobile App Development for Smart Home (Electronic Locks/Doorphones)

The lock hangs, the API returns 503, the BLE connection fails — the user stands at the door with a dead phone. This is not a UX problem; this is an incident. We design apps for electronic locks and doorphones where every communication channel has a backup. Our experience: 10+ years and 15 projects in the smart home domain. Recently, we solved an issue with Nuki locks on iOS: the app did not receive BLE notifications about the lock state due to incorrect CoreBluetooth background mode configuration. After adding bluetooth-central to Info.plist and using CBCentralManagerOptionShowPowerAlertKey, everything worked. Such details determine reliability. We are ready to evaluate your project in 2 days: contact us, and we will offer a turnkey solution.

How Do We Ensure Reliability When All Channels Fail?

The architecture is built on redundancy. At least two independent ways to open the lock. If the primary channel fails, the user should not call support standing in the cold. Typical channel hierarchy:

1. BLE (local, no internet) — first priority when close
2. Wi-Fi/cloud — if BLE is not available
3. PIN code on the lock — if the system completely fails
4. Mechanical key — physical fallback

The app automatically detects available channels and switches. BLE: check Bluetooth state via FlutterBluePlus.adapterState. No BLE or device is far — try Wi-Fi/cloud. In the UI, show the active channel to the user. Reduce support costs — fewer calls, higher satisfaction.

Why Is BLE the Primary Channel for Fast Opening?

BLE provides latency under 200 ms — 10 times faster than cloud control. Range 5–15 meters, no internet required. Native implementation via CoreBluetooth (iOS) / Android BLE API, on Flutter — flutter_blue_plus. Each lock is a GATT service with its own characteristics. For example, August locks use service UUID 00001523-1212-EFDE-1523-785FEABCD123 with proprietary protocol — no official SDK, we work via reverse engineering or August API.

Protocols and Lock Types

For Wi-Fi Tuya locks, use Tuya Open API: POST /v1.0/devices/{deviceId}/commands with {"commands": [{"code": "switch_1", "value": true}]}. For Zigbee — MQTT command to topic zigbee2mqtt/{device}/set with {"state": "UNLOCK"}. Z-Wave works via Z-Wave JS or Home Assistant.

Comparison of Temporary Access Approaches

Temporary Access and Guests

A key for a guest for 24 hours, for an Airbnb tenant for a week, for a cleaner on Tuesdays from 10 to 14 — this is core functionality. Implementation depends on the lock. Nuki Web API: POST /smartlock/{smartlockId}/auth creates an authorization with allowedWeekDays, allowedFromDate, allowedUntilDate, allowedFromTime, allowedUntilTime. August API: POST /access_codes with access_code type.

For BLE locks without a cloud, a temporary key is a cryptographically signed token with temporal constraints, transmitted via BLE. On the backend, we store all issued keys with metadata (to whom, by whom, expiry, usage list). Push notification to the owner on each use of the guest key.

How to Implement a Video Call from a Doorphone?

Video call from doorphone to mobile = WebRTC + VoIP push. When someone presses the doorphone button:

1. Doorphone publishes an event to MQTT
2. Backend sends a VoIP push to iOS (via PushKit) or FCM with priority: high to Android
3. The app wakes up in the background, establishes a WebRTC connection with the doorphone
4. Shows incoming call UI via CallKit (iOS) or android.telecom.ConnectionService

VoIP push on iOS via PushKit is the only way to reliably wake the app for a video call. Normal push arrives with a delay of 2–30 seconds. PushKit is instant. Requires VoIP certificate in Apple Developer Portal, entitlement com.apple.developer.pushkit.unrestricted-dispatch. On Android, a background service with startForeground keeps the WebRTC connection ready. Starting from Android 14, restrictions on background services have tightened; need ForegroundServiceType.CAMERA + ForegroundServiceType.MICROPHONE in the manifest.

Event Log

Every opening is recorded in the log: who, by which method, at what time. For rental properties, this is legally important. Storage: PostgreSQL with table access_log (id, lock_id, user_id, method, timestamp, result). Index on (lock_id, timestamp DESC). The mobile app requests paginated: GET /api/locks/{id}/access-log?page=1&per_page=50.

What Is Included in Development?

You get the full cycle: requirements analysis and protocol agreement, architecture design with fallback channels, mobile app development (iOS/Android), integration with locks and doorphones via API, push notification setup (PushKit, FCM), testing on real devices, preparation of documentation and user guides. Includes 3 months of warranty support after release.

Timeline and Cost

One lock type (BLE or Wi-Fi/cloud), basic control, temporary access — 6–8 weeks. Multi-protocol, doorphone with video, CallKit/VoIP, log, notifications — 4–6 months. Cost is calculated after determining lock models and guest access requirements. Contact us — get architecture consulting and a preliminary estimate. Order turnkey development — we will offer a solution in 2 days.

Apple PushKit documentation: https://developer.apple.com/documentation/pushkit