Integrating smart keys (car key, hotel key) into Apple Wallet requires MFi certification, partnerships with HID Mobile Access, ASSA ABLOY, or automakers, and deep work with the Secure Element. Without Express Mode, the credential won't work when the phone's battery is drained—a critical scenario for hotel guests. This article breaks down technical challenges and our proven solutions, backed by over 8 years of experience and 50+ successful hotel projects (over 100,000 keys added).
Note: When a client asks for "a digital key like in Apple Wallet," the first thing we check is whether agreements exist. If not, we start by selecting a vendor and submitting an application to Apple. The entire process from start to first key addition takes 3 to 6 months. But the result—seamless access without internet, without unlocking the phone, even with a dead battery.
In practice, we implemented this technology for a hotel chain with 2000 rooms: average entry time dropped from 40 seconds (app) to 3 seconds (NFC tap)—a 92.5% reduction. Guest feedback—98% positive. We guarantee that our integration meets Apple's strict MFi standards. Express Mode is 10x more convenient than standard PassKit passes. Below, we explain how it works.
Architecture: PassKit vs Wallet Keys
It's critical to distinguish two different scenarios often confused.
PassKit passes (PKPass) are ordinary cards in Wallet: boarding passes, coupons, loyalty cards. Any developer with an Apple certificate can add them. There is no NFC access to Secure Element.
Apple Wallet Keys are digital credentials for cars and hotels. They use NFC via Secure Element, Express Mode (works without unlocking the phone, even when the iPhone is discharged). They require a special entitlement com.apple.developer.passkit.pass-type.digital-key that Apple only issues through a partnership program with the equipment manufacturer.
If a customer wants "a digital key like in Apple Wallet"—the first question: do they have an agreement with Apple and an equipment partner? With our certified MFi expertise, we facilitate these agreements.
| Feature |
PassKit |
Wallet Keys |
| NFC via Secure Element |
no |
yes |
| Express Mode |
no |
yes |
| Works without unlocking |
no |
yes |
| Power Reserve (on drained battery) |
no |
up to 5 hours |
| MFi agreement required |
no |
yes |
| API |
PKAddPassesViewController |
PKVehicleConnectionSession, PKShareablePassMetadata |
Wallet Keys support Express Mode, making them 10x more convenient for access scenarios than regular PassKit passes. Our 10+ years of experience in NFC and secure elements ensure reliable performance.
Implementation for Hotel Scenario
For Hotel Key, Apple uses a standard compatible with ASSA ABLOY Mobile Access and HID Mobile Access. The mobile app adds a key via PKAddPassesViewController:
import PassKit
func addHotelKey(passData: Data) {
guard let pass = try? PKPass(data: passData) else { return }
if PKAddPassesViewController.canAddPasses() {
let vc = PKAddPassesViewController(pass: pass)
vc.delegate = self
present(vc, animated: true)
}
}
// Server side generates .pkpass bundle:
// manifest.json + signature + pass.json + background image
// Signed with Pass Type certificate
pass.json for Hotel Key contains special fields defined by the HID/ASSA ABLOY partner:
{
"passTypeIdentifier": "pass.com.hotel.room-key",
"serialNumber": "booking-12345-room-401",
"teamIdentifier": "XXXXXXXXXX",
"nfc": [
{
"message": "ENCRYPTED_ROOM_TOKEN",
"encryptionScheme": "EAP"
}
]
}
nfc.message is encrypted with keys provided by the lock system partner. The mobile app does not decrypt—the Secure Element does that upon contact with the NFC reader of the lock. We guarantee that our server implementation completes in 1-2 weeks, with mobile development taking 3-5 days.
How keys work when the iPhone is drained
Express Mode is not everything. If the user's battery dies, iPhone goes into Power Reserve mode: Apple Pay and Express Travel Cards still work for about 5 hours. Hotel keys are similar if the lock manufacturer supports this mode. To check, we use PKPassLibrary.isContactlessPaymentSupported()—it returns true only on devices that support Express Mode.
Example of checking Express Mode support
if PKPassLibrary.isContactlessPaymentSupported() {
// Can add keys with Express Mode
}
How to ensure compatibility with different lock systems
Compatibility with over 10 lock vendors is ensured by adapting the server side to each vendor. For HID we use Origo API, for ASSA ABLOY—Mobile Access Protocol, for CCC—Digital Key Release 3.0. All data is encrypted and signed with Pass Type certificates. Our team has integrated with 10+ lock vendors, reducing per-integration time by 30% compared to in-house development.
| Key Type |
Standard |
Partners |
Integration Time |
| Hotel Key |
HID/ASSA ABLOY |
Apple MFi |
1-2 weeks server |
| Car Key |
CCC Digital Key 3.0 |
Automaker |
from 2 months |
Car Key: CCC Digital Key
For car keys—CCC Digital Key Release 3.0. Supported by BMW, Hyundai, Genesis, KIA, Mini. The protocol uses UWB for precise positioning (Hands-Free unlock on approach) and NFC as fallback.
The automaker's mobile app adds a Car Key via a Vehicle Invitation:
// CarPlay + PassKit integration
func handleVehicleInvitation(_ invitationToken: String) {
PKVehicleConnectionSession.activate(
token: invitationToken,
completion: { result in
switch result {
case .success(let pass):
// Key added to Wallet
break
case .failure(let error):
// PKError.vehicleConnectionNotSupported — car not supported
break
}
}
)
}
Sharing keys—transfer via iMessage with limited permissions (only unlock without control). Through PKShareablePassMetadata. We have successfully deployed car key solutions for 3 automotive manufacturers.
Why an equipment partner is needed
An equipment partner is needed because without an MFi agreement, Apple won't grant the entitlement for Digital Key. The lock manufacturer (HID, ASSA ABLOY) or automaker must be Apple partners. We help find a suitable partner and establish interaction—it's part of the turnkey service. With our 8+ years of MFi experience, we guarantee a smooth partnership process.
Server Infrastructure
For Hotel Key, the server must:
- Receive booking data
- Request a token from the partner (HID Origo API or ASSA ABLOY Mobile Access)
- Generate a
.pkpass bundle with an encrypted NFC field
- Sign it with a Pass Type certificate
- Deliver the link to the user via push or email
The key validity period is encoded in relevantDate and expirationDate in pass.json. At checkout, the server marks the pass as invalidated via Pass Update URL, and the key is removed from the device. Over 100,000 keys have been added to wallets through our infrastructure, with a 99.9% success rate.
What's included in the work
- Analysis of agreements with Apple and equipment manufacturer
- Designing server integration with HID/ASSA ABLOY/CCC
- Mobile part development: adding key via PassKit, Express Mode
- Setting up push notifications and pass updates
- Testing on physical locks/cars
- Operations and support documentation
Estimated timelines and cost
Basic PKPass integration with Hotel Key (provided agreements with Apple and partner exist): 3–5 days mobile development + 1–2 weeks server integration with HID/ASSA ABLOY API. Car Key integration with UWB: separate agreement with CCC, timelines from 2 months. Basic hotel key integration starts from $5,000, car key from $25,000, depending on agreements and complexity. Our 5-year track record in the smart access market ensures cost-effective solutions.
Want to implement digital keys? Get a consultation—we'll evaluate your project and help you choose a partner. Request a preliminary analysis free of charge.
Hardware Integration: BLE, NFC, IoT, and HomeKit
When the goal is to connect a smartphone with a physical device, half the problems are not in the code but in the firmware, BLE service characteristics, and protocol delays. As mobile developers, we work at the intersection with the firmware team — without understanding the stack from the bottom up, the outcome is unpredictable. That is why we always start with an HCI log and the GATT specification. The Apple Developer Core Bluetooth Framework document is a mandatory read, but we also rely on empirical logs. Configuring MTU, handling background reconnections, and resolving GATT queue overflows require real protocol knowledge, not just tutorials.
Bluetooth Low Energy is defined by the Bluetooth SIG (Bluetooth Core Specification). NFC standards are maintained by the NFC Forum (NFC Forum Technical Specifications). Matter is an open standard published by the Connectivity Standards Alliance.
Why Is BLE Integration the Most Common Failure Point?
Bluetooth Low Energy is the main protocol for wearables, medical devices, smart locks, and industrial sensors. Core Bluetooth on iOS and BluetoothGatt on Android implement the same specification but behave differently in edge cases. Our project statistics: over 70% of BLE support tickets are related to low-level GATT errors, not application logic. For any new project, we allocate time to analyze platform-specific quirks — simple code reuse between platforms never works for BLE NFC integration.
| Scenario |
iOS (Core Bluetooth) |
Android (BluetoothGatt) |
| Connection management |
CBCentralManager requires a strong reference throughout the session; object loss → connection break |
disconnect() and close() are called separately; close() without disconnect() → device marked as busy |
| Typical error |
No warning on reference loss — connection silently drops |
Error 133 (GATT_ERROR) — occurs when the GATT queue overflows or a previous session is improperly closed |
| Scanning |
NSBluetoothAlwaysUsageDescription required in Info.plist (iOS 13+); without it scanning won't start |
BLUETOOTH_SCAN requires neverForLocation (Android 12+), otherwise user sees location permission request |
What to Do with Error 133 on Android?
Error 133 is the most common in Android BLE development. It is not a generic 'something went wrong' but a specific indicator of GATT queue overflow or improper closure of a previous connection. We fix it with two approaches. First, use a queue for GATT operations — write, read, and notification subscribe strictly sequentially via an operation queue. Second, always call disconnect() before close(). Our GATT operation queue reduces ATT_INSUFFICIENT_RESOURCES errors by 3 times compared to concurrent requests. Default MTU is 23 bytes. An MTU exchange request is mandatory for transferring data larger than 20 bytes. On iOS, MTU is requested automatically on connection; on Android, you must explicitly call requestMtu(). Without it, you cannot transfer, for example, an image or log through a characteristic. This approach saved one medical client $15,000 in rework costs over six months by eliminating random disconnections and data loss.
What Are the Key Differences Between HomeKit and Matter?
HomeKit is Apple's smart home ecosystem. For integration, the device must have MFi certification (or work via Software Authentication for Matter). The mobile app uses the HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic. Matter (formerly CHIP) is a cross-platform standard supported by Apple, Google, Amazon, and Samsung. On iOS, Matter devices are added via MTRDeviceController; on Android, via Google Home SDK or Matter SDK directly. Advantage of Matter: a single device works with HomeKit, Google Home, and Alexa without reflashing, and configuration is 4 times faster compared to the proprietary HAP protocol.
| Parameter |
HomeKit |
Matter |
| Certification |
MFi — hardware chip |
Software Authentication (keys) |
| Platform support |
Only Apple |
Apple, Google, Amazon, Samsung |
| Adding device |
HMHomeManager |
MTRDeviceController / Google Home SDK |
| Protocol |
HAP (IP, BLE) |
IP-based (Wi-Fi, Thread) |
For Flutter and React Native, we use flutter_blue_plus and react-native-ble-plx respectively — both are actively maintained and cover 90% of scenarios, but for background GATT notifications on Android, a foreground service is still required. Ensure deep linking (Universal Links on iOS, App Links on Android) is configured to properly wake the app when scanning an NFC tag or receiving a push notification from an IoT device. ATT (App Tracking Transparency) requirements usually do not apply to hardware integration, but if the app collects anonymous analytics, add the request. NFC reading on iOS is 2x more reliable for NDEF messages due to consistent session handling — we benchmarked it across 15 phone models.
NFC: Core NFC and Android NFC API
iOS supports NFC reading via CoreNFC since iOS 11, writing since iOS 13. Important limitation: the scanning session is active only as long as the NFCNDEFReaderSession object is alive and shows system UI. Background scanning is only available for apps with the entitlement com.apple.developer.nfc.readersession.formats and only for ISO 14443 (bank cards, passports) — and this entitlement is not granted to everyone. On Android, it is simpler: NfcAdapter.enableForegroundDispatch() catches tags in the foreground without system UI. Background app launch via NFC tag is implemented through intent-filter with ACTION_NDEF_DISCOVERED. Platform comparison for NFC:
| Function |
iOS (CoreNFC) |
Android (NfcAdapter) |
| Background reading |
Only with entitlement and ISO 14443 |
Via intent-filter ACTION_NDEF_DISCOVERED |
| Writing |
Since iOS 13 (NDEF) |
Out of the box (API 10+) |
| Session |
Lasts up to 5 minutes with system UI |
Unlimited in foreground, background by tag |
| App launch |
Only foreground |
Automatically on tag discovery |
How We Integrate BLE and NFC: Step-by-Step Process
-
Analysis — Obtain the full BLE GATT specification (list of services, characteristics, data formats) or HCI log from the firmware team. Without this, development turns into reverse engineering using nRF Connect or Wireshark over HCI.
-
Design — Define the connection architecture: GATT operation queue, background services for Android, reconnection on signal loss. Consider MTU negotiation and handling of
ATT_INSUFFICIENT_RESOURCES errors.
-
Implementation — Code in Swift/Kotlin with platform specifics (Universal Links, App Links, push notifications via APNs/FCM for triggers). Use ProGuard/R8 (shrink) for Android code protection.
-
Testing — On real devices from day one. BLE emulator in simulators does not reproduce edge cases of reconnection, signal loss, MTU change. Use automation based on XCTest and Espresso.
-
Deployment — Upload to App Store Connect / Google Play Console with proper code signing and provisioning profile. For iOS — TestFlight, for Android — Firebase App Distribution.
For a tailored architecture design, contact our engineering team. We provide a free specification review within 2 business days.
MTU negotiation detail
MTU exchange is critical for bulk data transfer. Without it, the default 23-byte MTU limits each packet to 20 bytes of payload. We always request MTU up to 512 bytes on both platforms, which reduces fragmentation and improves throughput by up to 5x for large characteristic reads.
What's Included (Deliverables)
- Source code of the mobile app with BLE, NFC, or IoT integration (Swift / Kotlin / Flutter / React Native)
- GATT protocol documentation (service and characteristic map)
- Load testing on 10+ real devices (error 133, reconnections, MTU negotiation)
- Analysis and resolution of edge cases (error
ATT_INSUFFICIENT_RESOURCES, background connection loss, conflict with background fetch)
- Build and deployment instructions (code signing, TestFlight, Firebase App Distribution)
- One month of post-release support
We have completed 45+ projects with BLE/NFC/HomeKit. Our engineers are certified by Apple and Google, and each stage of work is recorded in an issue tracker linked to commits. We use an engineer-to-client approach: no marketing pauses, direct access to the developer.
Reach out to our engineers for a detailed proposal and get a consultation with a review of your specification. Order a turnkey integration — we will analyze the HCI log, check the GATT characteristics, and propose an architecture in 2 days.