SDK Integration

LimeLink provides direct native iOS and Android SDKs plus React Native and Flutter wrappers for Link resolution, platform link handling, deferred deep links, and explicit event handling.

Current Guides

PlatformCurrent guideSetup model
iOSiOS SDK 1.0.1Public SwiftPM and CocoaPods integration
AndroidAndroid SDK 1.0.1Public Maven integration
React NativeReact Native SDK 1.0.1Public npm package; native SDK 1.0.1 dependencies
FlutterFlutter SDK 1.0.0Public pub.dev plugin; native SDK 1.0.1 dependencies

Use Previous Releases only when maintaining an older integration. React Native requires New Architecture interoperability with Hermes (not Expo Go, web, Legacy Architecture or JSC). Flutter requires Flutter 3.44+/Dart 3.12+. Both wrappers pin native SDK 1.0.1; the Flutter package itself is 1.0.0.

Before Integration

  1. Create or open an Organization and Project.
  2. Register the corresponding iOS or Android Application in the Project.
  3. Copy the canonical Project UUID from Project settings for native, React Native, and Flutter SDK initialization.
  4. Follow the platform or wrapper guide for package installation, app configuration, initialization, and Link callbacks.
  5. Define an app-owned allowlist of destination schemes and HTTPS hosts before routing any resolved URI.

Plan Boundary

Free includes SDK installation, Universal Links/App Links, and deferred deep links. Pro adds Custom Domains for USD $10/month or USD $100/year.

Custom Domains require an active Pro Project and additional platform domain association. Add the custom hostname to Android App Links or iOS Associated Domains, publish the platform association file for that hostname, and verify domain association before testing Links. See the current platform guide for exact setup.

Identity and Security Boundary

Initialize native, React Native, and Flutter SDKs with the public Project UUID. It scopes SDK-owned V2 Dynamic Lookup, Deferred, and explicit Stats behavior. Reserve Organization API credentials for trusted server-side integrations.

Open a resolved destination only when its parsed scheme and host exactly match an explicit app-owned allowlist. Version 1.0.1 reports unresolved Universal/App Links as successful results with a nullable deeplinkUrl and the exact inbound HTTPS URL in originalUrl; use that original URL only for an explicitly allowlisted browser fallback.

The public create-Link API remains a separate server-to-server integration. Store its Organization API credential on the trusted server.

Verification Checklist

  1. Confirm the installed package and native dependency versions match the selected current guide.
  2. Initialize with a canonical lowercase Project UUID after registering a long-lived listener where the platform guide requires it.
  3. Open a direct custom-scheme link and confirm the destination passes the app-owned allowlist.
  4. Test a resolved and unresolved iOS Universal Link or Android App Link. An unresolved web link remains a success with nullable deeplinkUrl and exact originalUrl.
  5. Test an eligible install-before-open deferred journey and choose only one completion/listener channel as navigation owner.
  6. Confirm errors and deferred not-found outcomes are handled without blocking normal app startup; these are live-only, unlike buffered successes. Forward each native lifecycle event once, and do not feed wrapper/router initial-link events back into an already-owned native path.

If app routing falls back to a browser or store unexpectedly, verify the Project Application record, Bundle ID/package name, signing fingerprint, Associated Domains/App Links files, selected Link Application, and exact scheme/host allowlist.