Smart Lock Bluetooth Key-Share UI in SwiftUI

What is a smart lock key-share screen actually doing?

Delegating access to a physical door, which is a permissions problem, not a button. Sharing a key to a smart lock means granting another person the ability to open a real door, so the screen is closer to an access-control panel than to a share sheet. The owner decides who gets in, for how long, and with what limits, and the app records and enforces that. So the core of the UI is not the “share” button; it is the access list: who currently holds a key, what kind, and the ability to take it back.

The honest framing first: a shared key is a credential, and the app delegates intent while the lock enforces it. The phone does not open the door by willpower; it sends a request, and the lock (directly over Bluetooth, or through the lock’s hub or cloud) is what actually grants entry. This is the same intent-versus-confirmation discipline as a Bluetooth car-sharing unlock: the UI should never claim access is granted until the system that controls the lock confirms it. Bluetooth companion apps are well-established ground for this, the React Native BLE library alone pulls over 238,762 weekly npm downloads, and the native Core Bluetooth path is the SwiftUI equivalent.

What does the access list need to show?

Who has access, what kind, and how to revoke it, at a glance. The access list is the product, and it has to answer the owner’s real questions instantly:

• Who holds a key, named, with their access clearly labeled.
• What kind of access, permanent, scheduled (recurring hours), or temporary (a one-time or expiring key).
• Current state, active, scheduled-for-later, or expired, so the owner sees reality, not just intent.
• One-tap revoke, the most important control, immediate and unambiguous.

Revocation is the feature that makes sharing safe, because the willingness to grant access depends entirely on being able to take it back. An access list that shows who has keys but buries or delays revocation gets the priority backwards.

Why is revocation the hard part?

Because taking access away has to actually reach the lock. Granting access is the easy direction; revoking it is where honesty matters, because a revoked key must stop working at the door, not just disappear from a list. If the lock is online (connected through a hub or the vendor’s cloud), revocation can propagate quickly. If the lock is reached only over Bluetooth when someone is near it, the revocation may not take effect until the lock next syncs, and the UI has to be honest about that gap rather than implying instant, universal cutoff.

So the revoke flow should confirm the action and reflect its real state: revoked-and-synced versus revoked-pending-sync. Pretending a key is dead the instant it leaves the list, when the lock has not yet heard about it, is the dangerous lie here, the same honesty a hotel digital key needs about when a key actually activates and expires. Access control is only trustworthy if its state matches the door.

How does the share itself stay secure?

The key travels through the lock’s system, never as a raw secret in a text message. Sharing should hand the recipient an invitation that their app redeems against the lock vendor’s account system, so the actual credential is provisioned securely to their device, rather than the owner texting a code that anyone could forward or intercept. The recipient confirms, their app pairs, and the lock recognizes them, the credential is never a plaintext secret passed around. This is the same reason sensitive credentials belong in secure provisioning rather than shareable text, a discipline shared with any credential the device must protect.

The screens, the access list, the share-invitation flow, the schedule picker, the revoke confirmation with its synced-versus-pending states, come as free VP0 designs built around access control, so an agent wires the Bluetooth and vendor-account logic onto a UI that already treats a key as a revocable credential rather than a simple toggle. The pairing is the engineering; the honest access model is the design.

Key takeaways: a smart lock key-share UI

• It is access delegation, not a button: the screen is an access-control panel, and the access list is the product.
• The app delegates intent; the lock enforces it: never show access as granted until the controlling system confirms.
• The access list answers the owner’s questions: who holds a key, what kind, its current state, and one-tap revoke.
• Revocation is the hard, honest part: a revoked key must reach the door, so show revoked-and-synced versus revoked-pending-sync rather than implying instant universal cutoff.
• Share through the lock’s system, provisioning the credential securely, never texting a raw code that can be forwarded.

Frequently asked questions

How do I build a smart lock key-sharing UI in SwiftUI? Build it as an access-control panel, not a share button: the core is an access list showing who holds a key, what kind (permanent, scheduled, or temporary), each key’s current state, and a one-tap revoke. The app sends access intent while the lock (over Core Bluetooth or through its hub or cloud) enforces it, so never show access as granted until that system confirms. A free VP0 design supplies the access list, share flow, and revoke screens.

Why is revoking a shared key the hard part? Because revocation has to actually reach the lock, not just remove a row from a list. An online lock connected through a hub or cloud can cut off a key quickly, but a lock reached only over Bluetooth may not learn of the revocation until it next syncs when someone is near it. The UI must be honest about that gap, showing revoked-and-synced versus revoked-pending-sync, rather than implying a key is instantly dead everywhere.

Should I share a smart lock key over text message? No. Texting a raw code or secret is insecure because it can be forwarded, screenshotted, or intercepted. Instead, send an invitation that the recipient’s app redeems against the lock vendor’s account system, which provisions the actual credential securely to their device. The key should travel as a securely provisioned credential, never as a plaintext secret passed around in a message.

What should the access list display? Who currently holds a key (named), what kind of access they have (permanent, scheduled recurring hours, or temporary and expiring), the current state of each key (active, scheduled for later, or expired), and an immediate one-tap revoke. The list should reflect reality at the door rather than just the owner’s intent, so the owner can see and trust who can actually get in at any moment.

Does the phone open the lock directly? It sends a request, and the lock grants entry; the phone does not open the door by itself. Depending on the lock, the app communicates directly over Bluetooth or through the lock’s hub or cloud, and the lock is what actually unlocks. This is why the UI should show access as confirmed only when the controlling system responds, rather than assuming success the moment the user taps, the same intent-versus-confirmation discipline as any Bluetooth unlock flow.