Skip to main content

Link Mobile SDK React Native

This page is the integration guide for embedding the Link Mobile React Native SDK into iOS and Android apps. It covers SDK configuration, device discovery, and BLE credential exchange. Choose one of the three integration routes below based on where your app owns its access features.

Link Mobile SDK lets your app discover Last Lock devices over Bluetooth Low Energy (BLE), present credentials, and run Proxy, which carries encrypted traffic between locks and Link through the phone.

Example integration apps: source code in the production SDK repository.

Choose an integration route​

RouteChoose it whenWhere you call Link MobileWho maintains the React Native bridge?Effort
1. Supplied library (recommended)You want the supplied JavaScript API and the quickest setup.JavaScript / TypeScript through @last-lock/link-mobile.Last Lock.Lowest; choose A or B for native project setup.
2. Native SDKsYou already have a native feature, screen, or service that should own Link Mobile.Swift on iOS and Kotlin on Android.No JavaScript bridge is added.You integrate and maintain each native platform.
3. Your own TurboModuleJavaScript needs a custom contract or native functionality outside the supplied library's API.JavaScript / TypeScript through an adapter you write.Your team, on both platforms.Highest; native setup plus codegen, adapters, events, and lifecycle handling.

Route 2 alone does not expose SDK methods to JavaScript. If React Native screens need to call the native SDKs, choose Route 1 or add Route 3 on top of Route 2. Installing an XCFramework or Maven dependency does not create a JavaScript module.

Route 1 is recommended for the easiest integration. It supplies the JavaScript API and native adapters. Choose Route 2 for features owned by Swift/Kotlin, or Route 3 when your team needs to maintain a custom JavaScript contract.

What each call path looks like​

Examples of choosing a route​

  • React Native lock list and unlock button: start with Route 1, using A for Expo prebuild or B for projects you manage directly.
  • An existing Swift or Kotlin access screen inside a React Native app: use Route 2 if that screen owns SDK calls and results in native code.
  • An app with an existing native access service: use Route 3 if a React Native screen must call both Link Mobile operations and your own native policy or credential-storage code through one JavaScript interface. Build on Route 2's setup and maintain the TypeScript contract, native adapters, events, and lifecycle handling on both platforms. For a lock list and unlock button using the supplied API, choose Route 1.

For each distinct app identity integrated with the SDK, send Last Lock the following information so operators can add it to Link's attestation allowlist before testing connectivity:

PlatformInformation to provide
iOSExact {TEAM_ID}.{BUNDLE_ID}, for example ABCDE12345.com.example.app. Enable App Attest on the signed app target.
AndroidEach variant's applicationId and the SHA-256 fingerprint of the certificate signing the installed app. Debug, release, and Play App Signing certificates may differ.

See the iOS allowlisting instructions and Android allowlisting instructions for details. Expo bundle identifiers and package names must match the final signed native application. Register each identity you distribute.

Internet access is required to establish the attested Link channel. Validate on physical devices; Simulator builds and Android emulators do not establish that device attestation will succeed. Until Last Lock applies the allowlist entries, Proxy connectivity will fail.

Guides and API references​

The native API references cover platform types and methods. Match them to your selected native SDK versions. The supplied JavaScript library exposes a subset of those APIs.