Laying the Groundwork Beyond WebView: Why Danggeun Chose Lynx

To solve the initial loading issues of WebView screens, Danggeun chose Lynx, which can be incrementally integrated into the existing native app, rather than replacing the entire app with a new framework. While SSR or caching can reduce loading times, the path of fetching web documents and initial data from the network remains, necessitating an execution environment where users do not perceive loading.

The conditions Danggeun required for the new technology were as follows:

• Display actual product UI, not placeholder screens, from the first frame
• Apply at the screen level while maintaining the existing native app
• Deploy frontend bundles independently of the app binary
• Start with approximately one engineer each for frontend, iOS, and Android
• Be able to revert to the existing WebView if issues arise

Danggeun maintained core business experiences like the home feed and chat on the native stack and sought a rendering layer to optimize certain screens previously handled by WebView more quickly. Lynx offers a development model close to React and CSS, allowing selective insertion into the entire app or specific areas of existing native screens.

The most critical judgment criteria were the runtime initialization cost and the first-screen rendering process, rather than the maximum throughput of JavaScript execution performance. Lynx's main thread runtime, PrimJS (QuickJS), is small, easy to embed, and has low initialization costs, making it suitable for mobile environments where the runtime must be prepared and the first UI displayed upon entering a screen.

In Lynx's Dual-Thread Architecture, the main thread handles the first screen and UI changes, while the background thread manages React component lifecycles and side effects. If bundles and initial data are ready, IFR (Instant First-Frame Rendering) can be used to draw the product UI immediately on the main thread without waiting for background tasks to complete.

IFR requires bundles and core data for the first screen to be prepared synchronously. Based on this constraint, Danggeun was able to design bundle pre-downloads, native injection of initial data, and the UI to include in the first frame at both the product and platform levels.

Regarding development and deployment, Rspeedy is used. Based on Rspack and Rsbuild, it supports HMR, allowing the use of existing frontend tools and concepts. Lynx bundles are served via CDN and configured to be fetched by the native app via URL, enabling deployment independent of the app binary.

Additionally, LynxView can be placed as a full screen or inserted into specific areas within the native View Hierarchy. This is a Brownfield approach that introduces necessary areas without rewriting the existing app, and the ability to revert to the existing WebView in case of issues was also a significant factor in the decision.

While React Native and Flutter can also be incrementally introduced into existing native apps, what Danggeun wanted was not a new app development framework but a rendering layer performing a limited role. Lynx was closer to Danggeun's requirements in that it explicitly controls the features and operational responsibilities provided by the host app, rather than broadening the scope of the ecosystem.