Smart Home Locks and Intercom Mobile App Development
Opening a door from your smartphone is a task with zero margin for error. Lock hangs, API returns 503, Bluetooth connection failed — user is standing at the door. This isn't a UX problem, it's an incident. Therefore, the architecture of a lock management app is not built on "how to make it simpler," but "what to do when every communication channel fails."
Protocols and Lock Types
BLE locks (August, Schlage Encode, Nuki) — direct control via Bluetooth without internet. Range 5–15 meters, latency < 200ms. Native implementation via CoreBluetooth (iOS) / Android BLE API. On Flutter — flutter_blue_plus. Each lock is a GATT service with its own characteristics. August locks use 00001523-1212-EFDE-1523-785FEABCD123 service UUID with proprietary protocol — no official SDK, work via reverse engineering or August API.
Wi-Fi locks (Tuya, Yale Connect, Kwikset Halo) — cloud control. Latency 300–2000ms, depends on internet. For Tuya — Tuya Open API: POST /v1.0/devices/{deviceId}/commands with {"commands": [{"code": "switch_1", "value": true}]}.
Zigbee locks (Samsung SmartThings, Kwikset) — via hub. MQTT command to topic zigbee2mqtt/{device}/set with {"state": "UNLOCK"}.
Z-Wave locks (Schlage, Kwikset Z-Wave) — via Z-Wave JS or Home Assistant.
Backup Opening Channels
Rule: minimum two independent ways to open the lock. If primary fails — user shouldn't call support standing in the cold.
Typical channel hierarchy:
- BLE (local, no internet) — first priority when close
- Wi-Fi/cloud — if BLE unavailable
- Backup PIN code on lock — complete system failure
- Mechanical key — physical fallback
App automatically detects available channels and switches. BLE: check Bluetooth state via FlutterBluePlus.adapterState. No BLE or device too far — try Wi-Fi/cloud. Show active channel to user in UI.
Temporary Access and Guests
Guest key for 24 hours, Airbnb tenant for a week, housekeeper Tuesdays 10-2 — core functionality.
Implementation depends on lock. Nuki Web API: POST /smartlock/{smartlockId}/auth creates authorization with allowedWeekDays, allowedFromDate, allowedUntilDate, allowedFromTime, allowedUntilTime. August API: POST /access_codes with access_code type.
For BLE locks without cloud: temporary key is a cryptographically signed token with time constraints, transmitted via BLE. Mechanism depends on manufacturer.
Backend: store all issued access keys with metadata (to whom, by whom, expiration, usage list). Push notification to owner when guest key used.
Video Doorbell and Video Call
Video call from doorbell to mobile = WebRTC + VoIP push. When someone presses doorbell:
- Doorbell publishes event to MQTT
- Backend sends VoIP push to iOS (via PushKit) or FCM with
priority: highon Android - App wakes in background, establishes WebRTC connection to doorbell
- Shows incoming call UI via
CallKit(iOS) orandroid.telecom.ConnectionService
VoIP push on iOS via PushKit — only reliable way to wake app for video call. Regular push arrives with 2–30 second delay. PushKit — instant. Requires VoIP certificate in Apple Developer Portal, entitlement com.apple.developer.pushkit.unrestricted-dispatch.
On Android background service with startForeground keeps WebRTC connection ready. Starting Android 14 — background service restrictions tightened, need ForegroundServiceType.CAMERA + ForegroundServiceType.MICROPHONE in manifest.
Event Log
Every opening — record in log: who, which method, 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). Mobile app requests paginated: GET /api/locks/{id}/access-log?page=1&per_page=50.
Timeline
One lock type (BLE or Wi-Fi/cloud), basic control, temporary access — 6–8 weeks. Multi-protocol, video doorbell, CallKit/VoIP, log, notifications — 4–6 months. Cost calculated after determining lock models and guest access requirements.