Autolink Native Libraries
Autolink helps a Lynx app discover native library packages from node_modules and register their Android and iOS capabilities automatically. Library packages declare their native entry points in lynx.lib.json; the host app enables the Autolink build integration once, then the generated registry takes effect during Lynx initialization instead of requiring manual wiring for each Element, Native Module, or Service.
Autolink currently covers native Android and iOS libraries only. It does not generate Web or HarmonyOS integration code.
✅ Completed Integrate with Existing Apps
✅ Familiar with Native Modules and Custom Native Element
Use Autolink tooling from the same Lynx release channel as your app. The package and plugin names are:
- npm:
create-lynx-libraryand@lynx-js/autolink-codegen(lynx-autolink-codegenbinary) - Android: Gradle plugins
org.lynxsdk.library-settingsandorg.lynxsdk.library-build - iOS: Ruby gem
cocoapods-lynx-library
If one of these packages cannot be resolved from your configured registries, your current Lynx SDK release does not include Native Autolink in that registry yet. Keep using the existing manual native registration flow until the matching release is available.
Host App Project Structure
Before enabling Autolink, make sure the host app has a project root that can install npm packages and expose the native app build entry points. A typical host app looks like this:
package.jsonis required so the app can declare Autolink library packages as dependencies.- For Android, the project needs a Gradle settings file, such as
settings.gradleorsettings.gradle.kts, and an Android application build file, such asapp/build.gradleorapp/build.gradle.kts. - For iOS, the project needs a CocoaPods entry point, usually
Podfile. If your team manages Ruby dependencies with Bundler, keep thecocoapods-lynx-librarygem inGemfile.
After you install dependencies, Autolink scans the installed npm packages for lynx.lib.json files at package roots. A lockfile such as package-lock.json, pnpm-lock.yaml, or yarn.lock is recommended for reproducible installs, but it is not required by Autolink.
Set Up Autolink in an App
Set up Autolink once in the host app. After that, installed library packages can be discovered from node_modules and registered through the generated registry during Lynx initialization.
Install the cocoapods-lynx-library gem in your iOS build environment. Then add the CocoaPods plugin to the app's Podfile and call use_lynx_library! so podspecs from installed libraries and the generated registry pod are added during pod install:
After pod install, Autolink generates the registry pod and hooks it into the Lynx initialization flow. When the app creates LynxConfig or initializes LynxEnv, Elements, Native Modules, and Services from installed libraries are registered automatically. App code does not need to import generated files or add extra native initialization.
Use a Library
After the app has set up Autolink, install the library package in your Lynx app:
Each library package exposes a lynx.lib.json manifest at the package root. Autolink scans installed npm packages for this file.
For Android, platforms.android.packageName is required, and sourceDir defaults to android. For iOS, sourceDir defaults to ios, and podspecPath defaults to the first .podspec found under the iOS source directory.
After installing or updating a library package, sync/build the Android app and run pod install for iOS so the generated registry and native dependencies are refreshed. You do not need to add per-library manual registration code in the app.
Library Package Role and Structure
An Autolink library package is an npm package that bundles the JavaScript facade, type declarations, native implementation, and Autolink manifest for one reusable capability. App teams install the package as a normal dependency; the Android Gradle plugins and iOS CocoaPods plugin read lynx.lib.json and link the native code into the host app.
A typical library package looks like this:
package.jsonmakes the package installable from npm and usually provides thecodegenscript.lynx.lib.jsonis the Autolink contract. It tells the host app where Android and iOS source code lives.types/index.d.tsdescribes the Native Module API that codegen uses to create platform specs and the JavaScript facade.src/index.tsexports the JavaScript API that app code imports.android/andios/contain native implementations and generated native specs.example/is a local app used by the library author to verify the package.
Create a Library
Create a new library package interactively:
For scripts and tests, the same scaffold can run without prompts:
The generated package includes:
package.jsonwith"codegen": "lynx-autolink-codegen"lynx.lib.jsonfor Android and iOS Autolink discoverytypes/index.d.tsfor Native Module type declarationssrc/index.tsfor the JavaScript facadeandroid/andios/native source foldersexample/,tsconfig.json, andREADME.md
Run codegen from the library root:
lynx-autolink-codegen reads lynx.lib.json and scans types/**/*.d.ts for @lynxmodule declarations:
It generates:
generated/<ModuleName>.tsfor the JavaScript facade- Android
<ModuleName>Spec.java - iOS
<ModuleName>Spec.hand<ModuleName>Spec.m
The first version supports void, string, number, boolean, and nullable unions with null.
Write Native APIs
Use the Autolink annotations and markers in library packages. Native Modules usually extend the spec generated by lynx-autolink-codegen; Elements and Services are discovered from their native markers.
Native Module example:
Element example:
Service example:
Autolink uses the LynxAutolink names as its public library authoring API.
For iOS packages that already use Lynx native registration macros, Autolink also scans existing LYNX_LAZY_REGISTER_UI, LYNX_LAZY_REGISTER_SHADOW_NODE, and @LynxServiceRegister(...) declarations so those packages can be linked without rewriting their native code.