Digital Keys in Apple Wallet: Cars & Hotels

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Digital Keys in Apple Wallet: Cars & Hotels
Complex
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1161
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    563

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:

  1. Receive booking data
  2. Request a token from the partner (HID Origo API or ASSA ABLOY Mobile Access)
  3. Generate a .pkpass bundle with an encrypted NFC field
  4. Sign it with a Pass Type certificate
  5. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.