Smart lock apps (August, Schlage, Yale, Latch, Airbnb) combine mobile, IoT, and security in a high-stakes UX. Forget your password? Annoying. Cannot unlock your front door? Major problem. The interview tests whether you understand the protocols and the safety mechanisms.
Functional requirements
- Pair lock with phone
- Unlock via tap, proximity, or schedule
- Grant time-bounded access to others (cleaners, guests, deliveries)
- Audit log of who unlocked when
- Lock/unlock works offline (Bluetooth or local network)
- Multi-user (family, vacation rental)
Architecture
Three components: lock, app, cloud.
The lock
Hardware:
- Bluetooth Low Energy radio
- Optional Wi-Fi or Thread for cloud connectivity
- Battery (often 2 AA, lasting ~6 months)
- Mechanical actuator that engages the deadbolt
Firmware handles BLE protocol, key validation, audit logging.
Pairing
First-time setup:
- User puts lock in pairing mode (button press)
- App scans for BLE advertisement
- BLE handshake establishes initial connection
- App provisions an admin key
- Lock is now under that user’s control
Matter (universal smart-home standard) increasingly supports smart locks.
Time-bounded access keys
Owner grants access to a guest:
- Generate a key tied to the lock + valid time window
- Sign with the owner’s private key
- Send to guest via push
- Guest’s app stores the key
- On unlock, app sends the key over BLE; lock validates the signature and time window
Lock revokes keys when window expires. Owner can revoke remotely.
Offline operation
Critical: lock must work even without internet. Implementation:
- BLE communication direct from phone to lock
- Cached key in the app, valid for the entire access window
- Lock validates locally; no cloud round-trip
Audit log
Lock records every unlock attempt:
- Who (key ID)
- When (timestamp)
- Result (success / failure)
Synced to cloud when online. Owner can see “Maria unlocked at 2:34pm Tuesday.”
Auto-unlock
Some locks support proximity-based unlock:
- Phone detects approach via geofence + BLE proximity
- Auto-sends unlock command when within range and going home
- Should not unlock when you are leaving
Direction inference is tricky; many apps use “leave home” + “arrive home” detection from past patterns.
Battery monitoring
Lock reports battery level periodically. App alerts owner when low. Critical: avoid the dead-battery-locked-out scenario.
Security model
- End-to-end encrypted communication between app and lock
- Per-user keys, never shared
- Server cannot unlock the lock (no master key in cloud)
- Compromised phone: revoke key remotely
- Lost phone: factory-reset lock as last resort
Vacation rental use case
Airbnb integration: hosts grant time-bounded access for the guest’s stay. Cleaning crew gets separate key valid only on cleaning days.
Common gotchas
- BLE connection drops mid-unlock; user has to retry
- Phone battery dead — physical key is essential backup
- Guest forgets to download the app; fall back to entry codes
- Lock firmware update bricks the lock (rare but devastating)
Frequently Asked Questions
Can the manufacturer remotely unlock the lock?
Most reputable products: no. The cloud is for key delivery; the lock validates locally. Some legacy products had backdoors; consumer pushback has reduced these.
Why is BLE used instead of Wi-Fi?
Battery. BLE is much more efficient. Wi-Fi support is optional for cloud connectivity, not required for unlocking.
What about Apple HomeKit / Matter integration?
Matter is becoming standard. Both iOS and Android can manage Matter locks alongside other smart-home devices.
Keep sharpening your system design:
