June 30, 2026

Yiming LiEngineering @ Lynx

Hengchang LuEngineering @ Lynx

Qingyu WangEngineering @ Lynx

Jing HuEngineering @ Lynx

Jingkai ZhaoFramework Lead @ Lynx

Jiahan ChenRstack Team

Xuan HuangArchitect @ Lynx

Copy Markdown

Lynx built its toolchain Rspeedy on top of Rstack, Rsbuild and Rspack, so every Lynx app gets the performance and capabilities of the upstream toolchain as soon as they land.

With Rspack 2.0 and Rsbuild 2.0 now out, Lynx picks up the upstream improvements for free: 18–39% faster builds, 3–9% smaller bundles, and config aligned with web conventions like resolve.alias and top-level splitChunks. On top of them, we've shipped a series of optimizations tailored to Lynx: more flexible code splitting and dynamic loading, PrimJS-tuned output, ES2017 by default, parallel Lynx Bundle encoding, and precise error de-mapping. And one more thing: an Agent Skill for bundle-size optimization, to help you systematically shrink an app.

These features are available from Rspeedy 0.15. We expect most projects to get them without any config changes; for the rest, see the upgrade guide.

#Rspack 2.0

Rspack is the bundler at the bottom of the stack. Upgrading to 2.0 brings the most direct performance and size wins, and most projects get them with no config changes. For the full set of changes Rspack 2.0 brings, see the Rspack 2.0 announcement.

#18–39% faster builds

Across a set of production Lynx apps, we measured build-time reductions of 18–39% with no config changes:

The core speedup comes from Rspack 2.0's engine optimizations; multi-page apps benefit further from parallel Lynx Bundle encoding.

#3–9% smaller bundles

Bundle size shrank as well. Across the intermediate main-thread.js, background.js, and the final Lynx Bundle, main-thread.js and the Lynx Bundle dropped by 3–9%.

This comes from Rspack 2.0's stronger tree-shaking, plus the background output target moving to ES2017.

#Node.js requirement raised

The minimum is now Node.js 20.19+ or 22.12+; Node.js 18 is no longer supported.

#@lynx-js/*-webpack-plugin drops webpack support

Now that Rspack is mature, we're dropping webpack support in the underlying @lynx-js/*-webpack-plugin packages: they're Rspack-only, with public types coming uniformly from @rspack/core. Most projects use them indirectly through Rspeedy and need no changes; if you depend on these plugins directly, you'll need to adjust accordingly.

#Rsbuild 2.0

Rsbuild provides the out-of-the-box build configuration on top of Rspack. 2.0 moves that configuration closer to the web ecosystem's common conventions; the changes at this layer are mostly renames and relocations of config options, with unchanged semantics. For the full set of changes, see the Rsbuild 2.0 announcement.

#source.alias → resolve.alias

Move aliases from source.alias to resolve.alias:

export default defineConfig({
-  source: {
+  resolve: {
    alias: {
      '@': './src',
    },
  },
})

#performance.chunkSplit → splitChunks

Move performance.chunkSplit.strategy to the top-level splitChunks.preset:

export default defineConfig({
-  performance: {
-    chunkSplit: {
-      strategy: 'single-vendor',
-    },
-  },
+  splitChunks: {
+    preset: 'single-vendor',
+  },
})

#Default decorators version 2023-11

source.decorators.version now defaults to 2023-11 (was 2022-03); set it explicitly to keep the old behavior.

#Optimizations for Lynx

On top of Rspack and Rsbuild, Rspeedy layers a series of optimizations targeting Lynx's dual-thread runtime and artifact format.

#More flexible code splitting and dynamic loading

Lynx supports three increasingly powerful ways to split an app, each with a counterpart in the web ecosystem, adapted by Rspeedy to Lynx's artifact format:

Build-time splitting with splitChunks is common (its config moved, see performance.chunkSplit → splitChunks), so we won't expand on it here; below we focus on Lazy Bundle and External Bundle.

#Lazy Bundle

Lazy Bundle defers part of a single app, loaded on demand with ReactLynx's lazy(), just like dynamic import() on the web:

import { Suspense, lazy } from '@lynx-js/react';

const LazyComponent = lazy(() => import('./LazyComponent.jsx'));

On top of this, we're adding per-import control over when a lazy bundle loads: powered by Rspack 2.0's import attribute support, you'll be able to specify per import whether it loads synchronously (for IFR) or asynchronously (background-driven, the default). The usage will look roughly like:

lazy(() => import('./LazyComponent.jsx', { with: { mode: 'sync' } })); // sync, for IFR
lazy(() => import('./LazyComponent.jsx', { with: { mode: 'async' } })); // background-driven (default)

This is in progress and will land in a future release.

#External Bundle

External Bundle is a separately built Lynx Bundle that another app can fetch and render at runtime, enabling cross-app reuse. The producer side is built with Rslib via defineExternalBundleRslibConfig; the consumer side uses the Rsbuild plugin pluginExternalBundle.

#PrimJS-tuned output: lowering let / const to var

Beyond build time, we also made the output parse faster in Lynx's runtime. On Android, Lynx's background thread runs on the PrimJS engine, and we found PrimJS parses var noticeably faster than block-scoped let / const. So Rspeedy 0.15 enables SWC's transform-block-scoping on both the main- and background-thread layers by default, lowering let / const to var, and sets output.environment.const to false so the bundler's own runtime code uses var too.

#Background target raised to ES2017

We raised the background-thread output target from ES2015 to ES2017 (the main thread stays at ES2019). As low-end devices age out, a higher baseline means less down-leveling and smaller, faster output. If you still need to down-level specific syntax, add the matching transform to tools.swc's env.include:

import { defineConfig } from '@lynx-js/rspeedy';

export default defineConfig({
  tools: {
    swc: {
      env: {
        include: ['transform-async-to-generator'],
      },
    },
  },
});

#Parallel Lynx Bundle encoding

For multi-page apps, the speedup isn't only from Rspack 2.0: Rspeedy runs each entry's tasm encode (@lynx-js/tasm) in a parallel worker pool, parallelizing what used to be serial Lynx Bundle encoding to cut build time further.

#Precise error de-mapping

Rspeedy 0.15 lets production errors resolve precisely back to your source: it generates a unified debug-metadata.json per Lynx entry that brings the JS, CSS, and UI source maps together, so both main-thread and background-thread errors can find the right de-mapping info. See Map Production Errors to Source for how it works.

#One More Thing: an Agent Skill for Bundle-Size Optimization

Pinpointing where the bytes are is often harder than the optimization itself. It takes understanding Lynx's artifact format and Rspeedy's dual-thread build. rspeedy-bundle-size encodes that knowledge into an Agent skill: it teaches the AI how a Lynx dual-thread bundle's size breaks down, measures first, then ranks the biggest wins (assets, background JS, redundant code that leaked into the main thread).

Install it into your agent (Claude Code, Codex, etc.):

npx skills add lynx-community/skills -s rspeedy-bundle-size

Then just describe the goal in natural language, e.g. "break down this app's bundle and tell me where it's big and how to shrink it." The skill runs Rsdoctor, reports the per-layer breakdown, and hands back a prioritized plan; code only changes once you confirm. In real projects, this workflow has cut page size by 10–13%, mainly by correctly marking background-only code (logging, network requests, telemetry) that had leaked into the main-thread render path and moving it out, plus de-duplicating packages via aliases.

#Migration

For migration steps, see the Rspeedy upgrade guide. The breaking changes listed by layer above mostly come with the Rspack 2.0 / Rsbuild 2.0 upgrade. To check them off one by one, see the Rspeedy CHANGELOG, the Rsbuild v1 → v2 guide, and the Rspack v1 → v2 migration guide.

#What's next

We'll keep working with the Rstack team on both build performance and output performance, and make more mature web capabilities work out of the box on Lynx, such as Module Federation.

You may have also noticed the Rspack → Rsbuild → Rspeedy layering above and found it confusing. We did too. We'll explore how to retire the Rspeedy layer by pushing Lynx specifics like the dual-thread model upstream into Rstack, reducing Lynx-only config, concepts, and documentation, so that long term you can configure and build a Lynx project directly with Rsbuild.

Try it on an existing project. If you hit anything or have suggestions, open an Issue or join the discussion on GitHub.

June 8, 2026

Jing HuEngineering @ Lynx

HaoYang WangEngineering @ Lynx

Hao AiEngineering @ Lynx

ChenChao GaoEngineering @ Lynx

Zhou FangEngineering @ Lynx

MoonfaceXComponent Lead @ Lynx

Jingkai ZhaoFramework Lead @ Lynx

Xuan HuangArchitect @ Lynx

Copy Markdown

Since the rise of AI Agents, we have been exploring what it would take to make Agent-driven generative UI feel truly native inside real apps. Lynx is uniquely placed for this: it renders natively across Mobile, Web, and Desktop, and embeds directly into the apps people already use. So when Google introduced A2UI, an open Agent-to-UI protocol that lets AI Agents safely generate rich interactive interfaces without executing arbitrary code, we saw a clean fit.

Today, we are officially releasing our A2UI renderer that brings Generative UI to Lynx.

#Streaming Generation, Native Rendering

The A2UI protocol natively supports streaming: the Agent sends UI fragments as it reasons, and the client renders them progressively. This incremental interaction model eliminates blank waiting screens, letting users watch the interface take shape as the Agent produces output.

Lynx A2UI inherits Lynx's dual-thread architecture, parsing A2UI protocol messages on the Background Thread while committing UI updates on the Main Thread, both running in parallel without blocking each other. Even when the Agent outputs UI fragments at high frequency, the interface remains smooth and responsive.

#A Catalog Built on lynx-ui

The core mechanism of A2UI is the Catalog: the client declares which components, functions, and parameters it supports, and the Agent can only choose from that authorized scope. This keeps generation bounded, while leaving how each component renders to the renderer.

Lynx A2UI ships with a built-in default component catalog based on lynx-ui, covering common components such as buttons, lists, and dialogs, ready to use out of the box. Beyond the defaults, developers will likely want to define their own components, registering business capabilities into the Catalog so the Agent can invoke them on demand during conversations.

#Programmable Actions

A2UI handles user interaction through the Action mechanism: components describe user intent as structured payloads instead of running arbitrary code. The spec also distinguishes functionCall, which runs locally without informing the Agent, from event, which round-trips back to the Agent.

What Lynx A2UI adds is the API shape on top. The <A2UI> render container subscribes to a MessageStore that holds raw protocol messages in arrival order. When an Action fires, onAction hands your code a unified { name, context } payload: push a follow-up message into the same store for a local update, or post to the Agent and stream the response back into it. The renderer stays the same; you own the round-trip.

#Try It Now

Lynx GenUI Playground provides a complete interactive experience covering the full pipeline from model conversation to UI rendering. No local setup required: open your browser, chat with the Agent, and watch the interface generate in real time. To experience native rendering on a real device, download Lynx Explorer and scan the QR code on the page.

Read the A2UI Guide under ReactLynx, or jump straight to the more detailed preview version of the integration guide to integrate Lynx A2UI into your app. The renderer ships as the @lynx-js/genui/a2ui package, with support starting at A2UI 0.9; we'll work with the A2UI team at Google to adapt the v1.0 candidate soon. If you encounter issues, have feature suggestions, or want to share your use cases, feel free to open an Issue or join the discussion on GitHub.

We believe that cross-platform frameworks in the AI era should do more than just run AI-generated code: they should provide Agents with a secure, efficient, and native channel for rendering interfaces. Lynx A2UI is our first step in that direction, and we look forward to exploring the future of Generative UI, Open UI included, together with the community.

May 31, 2026

Mitchell YueInfrastructure Lead @ Lynx

The Lynx Teamlynxjs.org

Copy Markdown

Lynx 3.8 is now officially released!

As outlined in our 2026 roadmap, Lynx 3.8 kicks off our new monthly release cadence. Moving to monthly means each release will be smaller and more focused. For 3.8, that's WebAssembly on Android, <frame> auto-sizing, line-aware text fitting, HarmonyOS SessionStorage, LynxEngine reuse, and DevTool protocol updates.

Before diving into 3.8, don't miss our recent lynx-ui announcement, where we introduced ready-to-use components for building cross-platform Lynx interfaces.

#WebAssembly on Android

This release introduces initial WebAssembly support on Android via the PrimJS runtime. Lynx apps can now load and execute WebAssembly modules on the background thread, making it possible to move computation-heavy logic into WebAssembly when JavaScript isn't fast enough.

The current implementation focuses on common constructor-based flows:

const module = new WebAssembly.Module(wasmBytes);
const instance = new WebAssembly.Instance(module, imports);

const result = instance.exports.add(1, 2);

The complete example below shows the same flow in a Lynx page:

The current implementation covers WebAssembly.Module and WebAssembly.Instance fully, plus common-case usage of WebAssembly.Memory, WebAssembly.Table, and WebAssembly.Global.

#Adaptive Layout, Text, and Platform Behavior

This release improves how Lynx content adapts to its host container, fits text into constrained layouts, and closes platform-specific behavior gaps.

#<frame> Auto-sizing and Load Metrics

<frame> can now size itself based on the embedded Lynx page's content with the new auto-width and auto-height attributes, reducing the need for host-side dimension calculation.

<frame src={url} auto-width auto-height />

It also improves startup and observability with preset layouts, better data and global-props passing, intrinsic size reporting through layoutchange, and <frame> load metrics on Android and iOS.

#Line-aware Auto Font Sizing

The new -x-auto-font-size-line-ranges CSS property lets developers define different font-size search ranges based on the actual number of rendered lines. Use it with -x-auto-font-size: true:

.title {
  -x-auto-font-size: true;
  -x-auto-font-size-line-ranges:
    line-range(1, 18px, 22px), line-range(2, 16px, 18px),
    line-range(3 to infinity, 14px);
}

This is useful for titles, cards, and feed layouts where one-line, two-line, and multi-line text need different fitting behavior.

css-apisrc/-x-auto-font-size-line-ranges/index.scss

Code

Preview

#Desktop Exposure

macOS and Windows now support enable-exposure-ui-clip, giving developers more control over exposure calculations in complex layouts.

#Native Integration

#Lynx Engine Reuse in LynxViewGroup

On Android, LynxViewGroup can now cache and reuse a LynxEngine across LynxView instances created from the same group. This is useful when an application repeatedly creates views from the same template bundle, such as in multi-page or embedded-view scenarios.

We've seen many apps where users leave and re-enter the same Lynx page. In these cases, caching the LynxEngine avoids the cost of repeatedly destroying and recreating it, and can reuse work the engine has already done, like the constructed UI tree, so re-entering the page renders faster.

Applications don't need to manage LynxEngine directly. Create a group with caching enabled, attach it to each LynxViewBuilder, and release it when no longer needed:

ILynxViewGroup group = new LynxViewGroupBuilder()
    .setContext(context)
    .setTemplateBundle(templateBundle)
    .setGlobalProps(globalProps)
    .setEnableCacheEngine(true) // Enable caching.
    .build();

LynxView first = new LynxViewBuilder()
    .setLynxViewGroup(group)
    .build(context);

// Later, another LynxView created from the same group can reuse the cached engine.
LynxView second = new LynxViewBuilder()
    .setLynxViewGroup(group)
    .build(context);

group.release();

#Resource Loading Callback

LynxViewClientV2 adds an onResourceLoaded callback so clients can observe resource loading from native code. This gives host applications a single hook for resource timing, success/failure status, and other diagnostics.

#SessionStorage on HarmonyOS

HarmonyOS now supports the SessionStorage API for cross-page data sharing. Front-end code can use the existing lynx.setSessionStorageItem, lynx.getSessionStorageItem, lynx.subscribeSessionStorage, and lynx.unsubscribeSessionStorage APIs to share session-scoped state across pages.

#DevTool Protocol and Debugging

DevTool protocol and debugging improvements include:

• MTS debugging now works with pre-executed and pre-decoded MTSRuntime instances.
• CDP support adds DOM.describeNode.
• DOM.getDocument now supports the depth parameter.
• DevTool can query PerformanceEntry data through the CDP Performance domain.

#Upgrade Guide

To upgrade to Lynx 3.8, follow the integration guide and update your Lynx dependency versions accordingly.

#Thank You

Lynx 3.8 is the first step in our monthly release cadence: smaller releases, clearer upgrade paths, and faster feedback loops.

Thanks to everyone building with Lynx, trying new releases early, filing issues, and helping the project improve in the open. See you in the next monthly release.

May 22, 2026

Zhou FangEngineering @ Lynx

Ryan WangEngineering @ Lynx

Adrian LuoEngineering @ Lynx

MoonfaceXComponent Lead @ Lynx

Guangyu DuDesign Engineering @ Lynx

Xuan HuangArchitect @ Lynx

Copy Markdown

lynx-ui has been quietly open-sourced since we gave an early preview at React Advanced London last December. After months of polishing components, building the documentation site, and adding examples, today we are excited to announce it as generally available.

#Native Foundations, Web Velocity

Built-in elements and XElement give Lynx the low-level capabilities that matter: fast scrolling, precise gestures, and native rendering. But products are not built from atoms alone. That is where components belong. At Lynx, native provides the foundation; the web-inspired frontend stack provides the extension layer for composition, state, styling, and product-specific behavior.

lynx-ui delivers on this layering principle: preserve native user experience, deliver the velocity of the web.

#Composable Primitives

Encapsulation can become a trap. lynx-ui does not treat components as black boxes with endlessly growing prop surfaces. Instead, it is an unstyled component library where each component is a primitive that handles behavior and state, but ships with no visual design. A primitive is composed of parts that you render and style independently.

Popover shows the idea. It is not a single opaque component, but a composition of parts with separate responsibilities: PopoverRoot owns state, PopoverTrigger defines intent, PopoverPositioner handles placement, and PopoverContent stays structurally independent.

Because primitives are unstyled, the same composable model creates a foundation for design systems. You can define your own themes through the styling and theming system, or follow the shadcn/ui pattern to compose themed wrappers on top of the primitives.

#LUNA

LUNA is a reference design language we built on top of that foundation.

It grows from Lynx's signature gradient, adapting the brand expression into a softer palette for UI: warm pinks and rose tones moving into lavender and aqua. In LUNA, gradients act as first-class visual materials for expressing form and movement, giving components a sense of changing mediums. That sensitivity also carries into token names: LUNA describes how surfaces are felt, not where they are placed. ambient dissolves into the background, faint sits near the threshold of perception, veil and film create soft translucent layers.

#Programmable Interaction

Components built around continuous input need two things at once: highly customizable behavior and low-latency response. A swipe, drag, or snap is judged frame by frame. If the visual response trails behind the gesture, the component may still work, but it no longer feels native.

Lynx's dual-thread model defaults JavaScript to the background thread, keeping the main thread free for rendering. But Main-Thread Script can move interaction logic onto the main thread when it matters, making per-frame behavior fully programmable without crossing a thread boundary. Swiper shows the idea directly: drag input feeds transform updates frame by frame, so the card follows the gesture instead of catching up to it later.

With native foundations and programmable interaction in place, motion becomes practical, not just decorative.

#Motion

Motion is one of the most popular animation libraries in the Web community, supporting both spring-based and bezier-based transitions. Thanks to the programmability that Main-Thread Script brings, we adapted Motion for Lynx as @lynx-js/motion, a thin layer that reuses Motion's source directly, and ship an experimental version together with lynx-ui. If you know Motion on the web, you already know how to use it in Lynx.

Sheet shows why that matters. Drag, resistance, release, and settling need to read as one continuous behavior. With Main-Thread Script keeping interaction close to rendering and Motion defining how the surface moves, the sheet feels held, not just played back.

#Try it today

lynx-ui is available on iOS, Android, and HarmonyOS today, with partial Web and Desktop support on the horizon. Read the introduction to get oriented, or jump straight to the quick start to install @lynx-js/lynx-ui-*.

To see the components in action, grab Lynx Explorer, scan the QR codes in the component demos, and see them running right away. Or bring it into your own Lynx app and try it in a real product flow.

We want lynx-ui to grow from the way real apps are built. If it feels great, gets in your way, or leaves something missing, let us know in the lynx-family/lynx-ui repository. Help shape what comes next.

April 16, 2026

icecreamx10Multiplatform Lead @ Lynx

MoonfaceXComponent Lead @ Lynx

Yiming LiEngineering @ Lynx

The Lynx Teamlynxjs.org

Copy Markdown

Lynx 3.7 is now officially released!

This release brings official desktop platform support for macOS and Windows, introduces the new SVG element, introduces new Agent Skills for better observability, and updates ReactLynx with simpler External Bundle presets and cross-thread shared modules.

#Desktop Support: macOS and Windows

We previously planned to open source desktop support in Lynx 3.5, and later decided to go further and open source the full desktop stack. With Lynx 3.7, that vision is now a reality.

Lynx officially supports macOS and Windows as first-class platforms. You can now build and render Lynx views inside native desktop applications, using the same front-end stack and tooling you already use for mobile and web. We also plan to open source Lynxtron soon, an Electron-like desktop application framework that uses Lynx as its UI renderer. Stay tuned!

desktopsrc/mouse-cursor/App.tsx

Code

Preview

#CSS and Element Coverage on Desktop

The rendering core, which includes the CSS engine, is reused across platforms, so CSS coverage is naturally near-complete. The desktop UI is powered by Lynx's own rendering engine rather than native platform widgets, which means primitive elements need to be reimplemented for this custom backend, and coverage is still growing.

CSS: 97% property coverage. 311 out of 319 supported Lynx CSS properties are now available on desktop, including:

• Layout: Flexbox, Grid, Linear Layout, the full box model, positioning, and relative positioning.
• Styling: typography, borders, shadows, gradients, masks, filters, and CSS custom properties.
• Animation: animation, transition, @keyframes, and the full transform stack.

Elements: 73% attribute coverage. 179 out of 246 element attributes are already available on desktop, with identical support on macOS and Windows. Most built-in elements work directly on desktop today.

In practice, most Lynx pages built for mobile can already render on desktop with minimal or no front-end changes.

Each API page includes a compatibility overview and a detailed compatibility table. For a cross-API view, the API Status Dashboard now includes macOS and Windows columns.

#Desktop-Specific Capabilities

#Mouse Events

<view
  onMouseDown={(e) =>
    console.log(`Button ${e.button} at (${e.clientX}, ${e.clientY})`)
  }
  onMouseMove={(e) => handleHover(e)}
  onMouseLeave={() => resetState()}
/>

#Keyboard Events

<input
  onKeyDown={(e) => console.log(`Key down: ${e.key}`)}
  onKeyUp={(e) => console.log(`Key up: ${e.key}`)}
/>

#Wheel Events

<view onWheel={(e) => console.log(`Wheel delta: ${e.deltaX}, ${e.deltaY}`)} />

#CSS cursor

<view style={{ cursor: 'pointer' }}>
  <text>Hover me</text>
</view>

#Getting Started

For platform-specific integration details, see Integrate with Existing Apps, which now includes desktop guides alongside Android, iOS, HarmonyOS, and Web. A playground app built with Lynxtron will also provide a more direct way to fetch and run Lynx examples on desktop.

#<svg>: Scalable Vector Graphics

<svg> is now available as a standalone Lynx element in 3.7, bringing native vector rendering across platforms for icons, charts, and other resolution-independent graphics.

The <svg> element supports inline vector content:

svgsrc/base/index.tsx

Code

Preview

You can also load external SVG assets directly:

<svg
  style={{ width: '100px', height: '100px' }}
  src="https://example.com/icon.svg"
/>

To maximize performance, <svg> offloads SVG parsing to a dedicated background thread and renders the entire graphic as a single native view rather than creating individual element nodes. This keeps the main thread lightweight in both parsing time and node count, making it ideal for static display of icons, illustrations, and charts. It supports 17 commonly used SVG tags and over 40 attributes, with consistent rendering behavior across Android, iOS, HarmonyOS, macOS, Windows, and Web.

#Agent Skills

As part of the Lynx for AI initiative, six agent skills are now open-sourced. Install any skill with:

npx skills add lynx-community/skills -s <skill-name>

Together with Lynx DevTool MCP, coding agents can now inspect running pages, verify interactions, and debug their own changes with tighter feedback loops.

#ReactLynx

#External Bundle Presets

External Bundle lets you build a Lynx bundle once and load it from multiple Lynx apps at runtime. Use it when you want to share ReactLynx components or common business bundles across apps. Unlike Chunk Splitting which splits code within a single app, External Bundle is designed for cross-application reuse.

Lynx 3.7 adds built-in presets via defineExternalBundleRslibConfig to simplify setup:

import { defineExternalBundleRslibConfig } from '@lynx-js/lynx-bundle-rslib-config';
import { pluginReactLynx } from '@lynx-js/react-rsbuild-plugin';

export default defineExternalBundleRslibConfig({
  id: 'comp-lib',
  source: {
    entry: {
      './App.js': './external-bundle/CompLib.tsx',
    },
  },
  plugins: [pluginReactLynx()],
  output: {
    externalsPresets: {
      reactlynx: true,
    },
  },
});

Then load that bundle in the host app:

#Cross-Thread Shared Modules

By default, main thread functions cannot directly call plain functions that lack the 'main thread' directive, making code reuse difficult. Shared modules solve this by letting you explicitly declare modules as shareable between threads.

Add with { runtime: 'shared' } after an import statement, and the exported functions, classes, and objects in that module become directly callable from main thread functions:

#Upgrade Guide

To upgrade to Lynx 3.7, follow the integration guide and update your Lynx dependency versions accordingly.

April 13, 2026

Shouqun LiuEngineering Manager @ Lynx

Copy Markdown

Last year, we open-sourced the Lynx framework under TikTok's sponsorship. Since then, we've received valuable feedback from developers and the broader community. We also shared our 2025 roadmap, focusing on maintaining a consistent release cadence, expanding multi-platform support, and opening more core capabilities.

With the continuous releases from v3.2 to v3.6, Lynx has delivered several important improvements:

• Full support for the Web and OpenHarmony.
• Expanded lynx-ui coverage and improved native API stability.
• A growing ecosystem of community projects such as miso-lynx, Vue Lynx, and more.

At the same time, we recognize that building a great developer framework is a long-term effort, especially in the rapidly evolving AI era. Today, we're excited to share the Lynx open-source roadmap for 2026.

#1. Faster and More Predictable Release Cadence

Over the past year, Lynx followed a bi-monthly release cycle. With the upcoming v3.7 release wrapping up this cycle, we will move to a monthly release cadence starting in mid-2026.

During development and releases, we will continue improving:

• Release notes and upgrade guides.
• Stability guarantees for core APIs.
• Long-term maintainability across versions.

#2. Embracing AI

AI is fundamentally reshaping how software is built. We believe that building in the open is essential for a framework to keep pace with AI and become truly AI-native.

This year, we will focus on delivering more stable and well-structured APIs, along with high-quality, LLM-friendly documentation in the lynx-website, Agent Skills, tooling, and examples.

We will also explore generative UI with Lynx, as we see this as a key direction for cross-platform frameworks in the AI era. Our goal is to make Lynx one of the most AI-ready cross-platform frameworks.

#3. Committed Multi-Platform, Including Desktop

Multi-platform support remains a core mission, not only in rendering, but also across capabilities, APIs, and the overall developer experience.

We now have official support for Android, iOS, the Web, and OpenHarmony. We also have an open-source rendering engine, Clay, for desktop platforms including macOS and Windows.

This year, we'll continue to improve the production readiness of desktop platforms and deepen integration with industry ecosystems, including Lynxtron (coming soon), which brings Lynx and Electron together for desktop development.

#4. Production-Ready Infrastructure

Following the open-source release, we received extensive feedback from developers who want ready-made solutions for building cross-platform applications with Lynx quickly.

To address these needs, TikTok has open-sourced Sparkling, which provides application scaffolding and native navigation to help developers get started quickly. We will keep adding more native capabilities, including device APIs.

At the framework level, we will deliver more production-ready UI components through lynx-ui, expand animation and CSS capabilities to enable higher-quality UI experiences, and continue to invest in critical features such as Main Thread Scripting and runtime performance improvements across all supported platforms.

On the tooling side, we will release more profiling and diagnostics tools, and enhance Lynx DevTool to provide a one-stop development and debugging experience.

#5. Stronger Community Engagement

Cross-platform frameworks represent a long-term, evolving area driven by the open-source community. Lynx itself has been deeply inspired by this ecosystem.

The Lynx toolchain is built on top of Rspack, and we already collaborate closely with the Rspack community to deliver high-performance Rspeedy toolchains. This partnership with the web tooling ecosystem provides a strong foundation for broader engagement.

Looking ahead, we will deepen engagement with the wider web community, including projects such as React, Vue.js, and Motion, and continue improving MiniApps support to make it a fully production-ready solution.

We are hiring! We welcome you to join us on the Lynx journey. Click here to explore opportunities.

January 30, 2026

Leron LiuPerformance Lead @ Lynx

Guangyu DuDesign Engineering @ Lynx

The Lynx Teamlynxjs.org

Copy Markdown

Lynx 3.6 is now officially released!

This release introduces Lynx for AI to enhance AI-native development capabilities, introduces reactlynx-use for improved developer experience, and enhances CSS capabilities for design expressiveness.

On the native side, Lynx 3.6 improves platform integration with standalone BackgroundRuntime and asynchronous TemplateBundle creation on HarmonyOS, along with Auto Layout support for LynxView on iOS.

Let's take a closer look at what's new in Lynx 3.6.

#Lynx for AI: AGENTS.md and MCPs

AI assistants are quickly becoming part of everyday development. With Lynx 3.6, we’re introducing Lynx for AI—a new section on our website at /ai to help coding agents understand Lynx, follow best practices, and help you ship.

In this release, we’re shipping AGENTS.md and two MCP servers as the first building blocks for agent-friendly Lynx projects (Skills coming soon!).

#Lynx Docs MCP

Lynx Docs MCP connects your coding agent (Gemini, Claude, Cursor, Copilot, etc.) to Lynx documentation via MCP, using llms.txt plus carefully designed prompts so the agent can retrieve the right docs and act on them.

#Lynx DevTool MCP

Lynx DevTool MCP helps coding agents connect to devices and inspect/control Lynx pages like DevTools: read elements/console/source code, perform interactions such as clicks and drags, and capture screenshots for multimodal analysis.

#reactlynx-use: Hooks for ReactLynx

reactlynx-use is a hooks toolkit for ReactLynx projects.

It combines two sets of hooks: community-proven utilities that follow standard React patterns (such as useEffectOnce, useDebounce, etc.), built upon the excellent foundation provided by react-use, and Lynx-specific hooks that expose Lynx capabilities and its dual-thread model through a React-friendly API.

Notable Lynx-specific hooks include:

• useVelocity: Track the velocity and direction of tap events on the main thread.
• useTapLock: Constrain main-thread tap interactions to a specific direction or range.
• useMainThreadImperativeHandle: A main-thread counterpart of useImperativeHandle.
• useEventListener: A flexible event subscription hook supporting exposure, disexposure, and more.

This keeps everyday logic in familiar hooks, while making it straightforward to tap into Lynx’s main-thread input model and runtime events when you need to.

#CSS for Design Engineering

From Lynx 3.6 onward, CSS takes on a more explicit role in design engineering and design systems. As a medium for expressing design intent, CSS describes how decisions are scoped and composed, and how visual structure and perception are formed in the interface.

This release focuses on improving CSS expressiveness through CSS variables, gradients, and filters.

For each capability, we’ve also prepared a polished demo that you can render and interact with on the web.

#Inline CSS Variables for Computable Styling

As of Lynx 3.6, CSS variables can be defined and referenced inline. This allows them to be applied directly at component boundaries (where JS-defined parameters are handed off to CSS), without relying on ancestor class switches (such as theme-light / theme-dark) or imperative JS setProperty calls.

It becomes essential when a component's style is user-selected or computed at runtime, since such continuous values cannot be represented by a finite set of predefined classes and would otherwise require imperative style updates.

style={{
  '--x': pointer.x,  // normalized parameter from JS
  backgroundColor: 'var(--dot-accent-color)', //defer resolution to component CSS
}}

Inline CSS variables provide a direct path for passing design parameters from JS into CSS's inheritance and computation model, so that design intent can be dynamically expressed and resolved while preserving component-level scoping and the declarative styling model.

design-guidesrc/force_field/field.tsx

Code

Preview

#Nested CSS Variables for Token Layering

With Lynx 3.6, CSS variables can be defined in terms of other variables, allowing design tokens to be layered and resolved compositionally.

Design tokens capture high-level design decisions, such as colors, typography, spacing, shadows, and glows. Nested CSS variables enable these tokens to flow down into component-level variables and concrete visual styles.

/* Resolve and compose shadow tokens via nested CSS variables. */
.card {
  --blur: 12px;
  --ambient-shadow: 0 0 var(--blur) var(--color);
  box-shadow: var(--ambient-shadow), var(--rim-shadow);
}

This is especially important for composite declarations like box-shadow. A single box-shadow may contain multiple shadow layers, each combining several interacting dimensions such as offset, blur, spread, and color. With nested CSS variables, shadow layers can now be derived, combined, and adjusted from design tokens, while keeping their structure explicit and traceable in CSS.

design-guidesrc/soft_glow/index.css

Code

Preview

#Conic Gradients as Design Primitives

Lynx 3.6 adds support for the conic-gradient() CSS image function. You can use it in CSS properties that accept <image> values, such as in background-image and mask-image, to create continuous angular color transitions directly in CSS.

.bg {
  background-image: conic-gradient(from 30deg, #ff7385, #fe69a1, #00d0f1);
}

Conic gradients are a natural fit for angular or cyclic representations, including color wheels and hue pickers. In practice, they’re a lightweight design primitive you can compose into interactive controls and visual tools.

design-guidesrc/color_wheels/index.css

Code

Preview

#CSS Filters for Shape Formation

Lynx 3.6 extends CSS filter support with contrast, brightness, and saturate.

With these additions, the CSS filter property becomes a composable tool for shape formation. The newly supported contrast filter, when combined with the existing blur capability, amplifies overlapping regions and allows soft shapes to merge into coherent forms.

Visual structures such as merging, perceptual grouping, and fluid boundaries can be constructed directly in CSS, without relying on bitmap assets or custom rendering pipelines.

design-guidesrc/gooey_effect/index.css

Code

Preview

#Native APIs

#Standalone BackgroundRuntime on HarmonyOS

HarmonyOS now supports standalone BackgroundRuntime, aligning more closely with existing Android and iOS capabilities.

With standalone BackgroundRuntime, developers can run JavaScript tasks independently of rendering, or pre-create background runtimes to reduce LynxView initialization latency.

#Asynchronous TemplateBundle Creation on HarmonyOS

On Android and iOS, TemplateBundle.fromTemplate can be called from any thread. On HarmonyOS, however, ArkTS logic must run on the application's main thread.

To reduce main-thread I/O blocking, Lynx 3.6 introduces asynchronous APIs for creating TemplateBundle instances on HarmonyOS:

• TemplateBundle.fromTemplateAsync
• TemplateBundle.fromTemplateAsyncWithOption

#AutoLayout Support for LynxView on iOS

On iOS, LynxView now supports Auto Layout via [LynxView enableAutoLayout].

When enabled, LynxView can derive layout parameters directly from client-side Auto Layout constraints, eliminating the need to configure layout values manually.

#Upgrade Guide

To upgrade to Lynx 3.6, follow the integration guide and update your Lynx dependency versions accordingly.

November 10, 2025

Leron LiuPerformance Lead @ Lynx

Xuan HuangArchitect @ Lynx

The Lynx Teamlynxjs.org

Copy Markdown

Lynx 3.5 is now officially released!

Following our stable bi-monthly release cadence, Lynx 3.5 brings several key improvements. This release adds experimental support for React Compiler, enhances main thread scripts with stopPropagation for better event bubbling control, enables immediate interactivity after first-frame rendering, and improves cross-thread communication. We've also expanded HarmonyOS platform support and introduced new features like the pointer-events CSS property.

Let's dive in and see what's new!

#React Compiler experimental

React Compiler optimizes components at compile time, so you don't need to manually add useMemo, useCallback, or memo. You can now use React Compiler in ReactLynx to optimize your app's performance.

Learn how to enable React Compiler in ReactLynx.

#Main Thread Script

#Event Stop Propagation Web Friendly

When an event fires, it propagates through event bubbling, allowing different parts of your UI to handle it. Previously, Lynx only supported static event bubbling interception via catch-type event handler attributes, which lacked the flexibility of web standards. With Lynx 3.5, main thread scripts now support event.stopPropagation(), giving you runtime control over event bubbling that matches what you'd expect on the web.

function handleInnerTap(e: MainThread.TouchEvent) {
  'main thread';
  e.stopPropagation(); // ✋ stop event bubbling
  flash('inner');
}

eventsrc/event_stop_propagation/index.tsx

Code

Preview

#Immediate Interactivity After First-Frame

Previously, main thread events had to wait for the background thread to complete hydration before responding, creating a frustrating delay where the page looked ready but wasn't interactive, similar to the uncanny valley effect commonly seen in server-side rendering.

To eliminate this delay, we optimized the hydration process so that main thread events can respond immediately after the first frame is rendered. After the background thread hydrates, it correctly takes over the state from the main thread and replays runOnBackground calls, ensuring proper synchronization between threads while achieving immediate interactivity as soon as the first frame is visible.

function App() {
  const gotoUser = () => {
    'main thread';
    // go to second page
  };
  return (
    <view main-thread:bindtap={gotoUser}>
      <text>goto user</text>
    </view>
  );
}

#Cross-Thread Function Calls Now Return Values

Lynx provides runOnMainThread and runOnBackground for cross-thread function calls. In Lynx 3.5, both APIs now support async return values, making cross-thread communication more flexible and intuitive.

import { runOnMainThread, useMainThreadRef } from '@lynx-js/react';

function App() {
  const countRef = useMainThreadRef(0);

  const addCount = (value) => {
    'main thread';
    countRef.current += value;
    return countRef.current;
  };

  const increaseMainThreadCount = async () => {
    // await for return value from main thread
    const result = await runOnMainThread(addCount)(1);
    console.log(result);
  };
}

#Built-in Animations for <list> Updates

The <list> element now includes default update animations out of the box. When you add, remove, or update list items, smooth transitions are applied automatically—no extra code needed.

<list update-animation="default"></list>

#CSS Property: pointer-events Web Friendly

Lynx 3.5 adds support for the pointer-events CSS property, giving you control over whether an element can receive touch events.

pointer-events: auto;  // Default value. The element can be the target of touch events.
pointer-events: none;  // The element cannot be the target of touch events.

css-apisrc/pointer-events/App.tsx

Code

Preview

#HarmonyOS Improvements

#Fetch API

Lynx provides a Fetch API that follows web standards, so it works just like you'd expect. With Lynx 3.5, Fetch API support extends to HarmonyOS, making cross-platform development even easier.

#accessibilityAnnounce

Lynx 3.5 adds accessibilityAnnounce() support on HarmonyOS, bringing it in line with Android and iOS. This method lets screen readers announce specific text, helping visually impaired users understand interface changes and action results.

lynx.accessibilityAnnounce(
  {
    content: 'hello lynx',
  },
  (res) => {
    console.log('result: ' + JSON.stringify(res));
  },
);

#requestResourcePrefetch

The requestResourcePrefetch API is now available on HarmonyOS, matching Android and iOS support. Use it to prefetch CDN resources like images, videos, and audio files for faster loading.

lynx.requestResourcePrefetch?.(
  {
    data: [
      {
        uri: 'https://demo.org/test.jpg',
        type: 'image',
        params: { priority: 'high', cacheTarget: 'disk' },
      },
    ],
  },
  (res) => {
    console.log(
      'prefetch status of each resource:',
      JSON.stringify(res.details),
    );
  },
);

#Upgrade Guide

To upgrade to Lynx 3.5, follow the integration guide and update your Lynx dependency versions.

#One More Thing: Desktop Support Preview

We previously planned for Lynx 3.5 to introduce desktop support. At the time, our plan was to open source our custom rendering pipeline and low-level integration APIs for desktop. Since then, we've decided to go further and open source the full desktop stack to give you a more battery-included experience. As a result, we would have to adjust our timeline to early 2026.

To get a preview of where we are heading, and how our approach both learns from and differs from prior arts like Electron and Qt, check out the talk "Bringing Lynx to Desktop and Beyond" from our Multi-Platform Lead ZhiXuan Wang at Ubuntu Summit 2025:

September 25, 2025

Qiang BaiSoftware Engineer

Wentao ShiRendering Lead @ Lynx

The Lynx Teamlynxjs.org

Copy Markdown

As introduced in the open-sourcing blog, Lynx's vision continues to be unlocking native for more platforms and more users. With HarmonyOS now adding new platform and device diversity to the market, we want to enable Lynx developers to reach these users with the same ease they already enjoy on Android, iOS, and Web with Lynx.

Today, we are happy to share that Lynx now provides public beta support for HarmonyOS, delivering feature parity in CSS, Elements, and APIs — along with the same level of native performance and user experience.

#Consistent Rendering for HarmonyOS

In Tutorial: Product Gallery we built a complex page using Lynx. Let's see how Lynx performs on Android vs HarmonyOS. As shown below, it achieves pixel-perfect alignment. This allows Lynx developers to write once, run everywhere - one codebase for Android, iOS, Web, and HarmonyOS apps, improving efficiency and maintainability.

The high consistency of Lynx's CSS and native elements across Android, iOS, and HarmonyOS is attributed to our architectural decision: Lynx's rendering pipeline is shared and consistent across multiple platforms. On HarmonyOS, we implement the same set of CSS, animations, and custom component by swapping the paint layer to issue instructions to ArkUI.

#Native Lynx for HarmonyOS

#Native Painting with ArkUI

Lynx on Harmony uses ArkUI components for painting. Lynx with OpenHarmony explored two approaches: ArkTS and C API.

We finally chose C API to directly map Lynx platform-ui-tree to HarmonyOS native UI, combining Lynx performance with ArkTS ecosystem benefits.

• Native UI Rendering: Using ArkUI's C API to convert element-tree operations directly to native UI calls, eliminating data conversion overhead for better performance in complex UI updates.

• Custom Native Element: By utilizing HarmonyOS's BuilderNode and Builder capabilities, developers can dynamically construct ArkTS subtrees and seamlessly embed them into the ArkUI node tree created by Lynx, achieving highly customized component implementations.

#Native Interactions

Lynx designed a complete event system that captures and responds to gestures and events in complex interactions.

Gesture Support	Custom Gesture Control in Hybrid Scenarios

• Custom HitTest: Accurately find the nodes responding to events on the Lynx platform-ui-tree, ensuring precise interactions.
• Gesture Support: Integrates HarmonyOS gesture like tap and longpress, ensuring native-like gesture experience on Lynx.
• Custom Gesture Control in Embedded Scenarios: Offers a comprehensive set of event APIs, including user-interaction-enabled and block-native-event, empowering Lynx developers to manage event propagation and handling logic for efficient processing of nested scrolling scenarios with native pages.

#Native Extensions

• Native Element Customization: Lynx provides rich built-in elements and supports integration of custom HarmonyOS native elements (via ArkTS), enabling developers to extend UI capabilities for highly customized interfaces while preserving native performance. More details: Custom Element.
• Native Modules: Lynx enables developers to call HarmonyOS native APIs from JavaScript, supporting both system services and custom native modules. More detail: Native Modules。

#Create Your First Lynx on HarmonyOS

Lynx's official website offers development documentation and demo code for developers to get started quickly and efficiently.

1. Use the Pre-built Lynx Explorer: For the easiest development setup, follow the Quick Start to install the Lynx Explorer hap package and begin Lynx development.

2. Local Build of Lynx Explorer: Developers interested in exploring the Lynx on HarmonyOS source code can also attempt local builds by following the guide Building Lynx Explorer for Harmony.

3. Integrate with Existing Apps on HarmonyOS: For developers with existing HarmonyOS application projects seeking to integrate Lynx, the official website provides Integrate with Existing Apps.

Welcome to the Lynx community. Let's build outstanding native experiences with Lynx on HarmonyOS!