Why Cross‑Platform Development Keeps Evolving and How to Future‑Proof Your Code

Hello everyone, I am Mo Jue. This year I will be the producer of Alibaba D2 Terminal Technology Conference’s "Cross‑Platform Technology" track, and I use this opportunity to discuss the current state and future of cross‑platform technology, hoping to inspire new ideas.

Since the early 1990s PC era, rapid mobile network adoption led to the mobile and IoT eras around 2010, bringing a flood of devices such as PCs, tablets, smartphones, smart watches, and large‑screen terminals. Device systems and screen sizes have become increasingly fragmented.

Data shows the average user now owns five smart devices; by the end of 2022, China’s IoT connections are expected to exceed 100 billion. The rapid growth of smart devices fuels strong demand for cross‑device integration, driving a surge in cross‑platform development needs.

Historically, hardware development was isolated: phones for phones, computers for computers, iOS for iOS, Android for Android. This resulted in massive duplicated effort; a single development that serves all scenarios is an inevitable trend, prompting numerous cross‑platform solutions.

Cross‑Platform Technology: Changes and Constants

Looking at the evolution of cross‑platform technology—from web containers to generalized web containers and finally self‑rendering—solutions have changed rapidly, incurring significant migration costs. How can business code remain unchanged regardless of the underlying cross‑platform solution? We must revisit the evolution of these technologies.

Evolution of Cross‑Platform Technology

Web Container Solutions

Browsers and WebViews are standardized web containers under W3C specifications, allowing web pages to run easily in any browser or WebView. From the perspective of development cost, standardization, and ecosystem vitality, the web approach is often optimal. However, web suffers from slower page loads, higher memory consumption, and poorer interaction experience. Enhancements such as Hybrid, PWA, and PHA improve performance and experience, yet native performance and experience remain superior.

Web offers efficiency and dynamism that native development cannot match, while native provides performance and experience that web strives for. Is there a way to combine the best of both?

Containerized Native Solutions: RN / Weex

To address the performance and experience gaps of web containers while retaining web‑like development efficiency, containerized native solutions keep a JavaScript engine to integrate with the front‑end ecosystem and reuse native rendering pipelines for performance. Major frameworks like React Native and Weex adopt this model to achieve cross‑platform capabilities.

Although containerized native solutions appear ideal—offering native experience with web ecosystem support—they still face challenges such as consistency issues, limited W3C standard support, development experience gaps, and missing surrounding ecosystems.

Self‑Rendering Solutions: Flutter

Flutter bypasses native rendering pipelines by implementing its own Skia‑based rendering engine, achieving high consistency and strong performance. However, it introduces its own drawbacks: developers must learn Dart instead of JavaScript, and the front‑end ecosystem needs to be rebuilt, requiring substantial effort for CI/CD, tooling, and ecosystem integration.

These hurdles deter many front‑end developers, prompting further exploration of ways to better connect Flutter with existing front‑end ecosystems while retaining its self‑rendering advantages.

One‑Code‑Many‑Targets for Mini‑Programs

Mini‑programs create closed traffic ecosystems and container control, but their dual‑thread model and custom DSL introduce new cross‑platform challenges. As major vendors launch their own mini‑program containers and quick‑apps, fragmentation intensifies.

The implementation approaches fall into two categories: compile‑time and runtime.

Compile‑time: Transform framework business code into the native DSL of the mini‑program during compilation.

Runtime: Use a runtime framework to interact with the mini‑program’s setData mechanism for cross‑platform behavior.

Many frameworks exist; a typical example is shown below.

Mini‑program multi‑target deployment is essentially a commercial compromise and technical trade‑off.

Changes and Constants in Evolution

Regardless of how cross‑platform solutions evolve, the core goals remain unchanged: pursuing performance, delivery efficiency, and multi‑device consistency. The essence of each solution is balancing trade‑offs.

While container capabilities, bridges, and underlying APIs change, business code, infrastructure, and development ecosystems aim to stay stable. By treating the container as the sole variable, we can keep other layers unchanged.

Can a new container run existing business code without modification?

Will surrounding tooling and development ecosystem continue to work with a new container?

Can the required device capabilities remain unchanged when switching containers?

Standardizing a cross‑platform container specification enables seamless switching without affecting business logic, frameworks, or infrastructure—realizing the “write once, run anywhere” vision.

How should we achieve container standardization?

How to Standardize

Considering the browser’s approach makes the answer clear: how does a browser become standardized?

Browsers render via a core engine: the browser engine handles HTML, CSS, and layout, while the JavaScript engine executes JS according to the ECMA‑262 standard. Both engines operate independently yet cooperate closely, and implementations differ across browsers.

The core component is WebCore, which provides the fundamental loading and rendering capabilities shared across browsers. Other components follow the same standards but differ in implementation due to platform variations, third‑party dependencies, and specific requirements.

Applying this thinking to cross‑platform containers, we can adopt common standards to greatly reduce development effort, and leveraging W3C standards eases integration with the front‑end ecosystem—an approach already used internally at Alibaba.

Alibaba’s standardization effort coordinated major business units involved in cross‑platform containers and, referencing W3C/WHATWG standards, defined a subset covering CSS, WebAPI, and bridge mechanisms.

Why implement a subset instead of the full specification? The decision balances performance and efficiency. Implementing the full spec would maximize development experience but introduces challenges such as handling corners, shadows, and other UI details that can severely impact performance on mobile and IoT devices. Moreover, the extensive history of web standards adds considerable overhead.

Is defining subsets of HTML, CSS, and Web API enough to integrate with the front‑end ecosystem? In practice, cross‑platform containers still diverge significantly, requiring custom devtools, component implementations, and other infrastructure. For example, debugging tools differ across containers, and common UI components like List must be re‑implemented for each.

The ultimate goal remains: one development effort for all scenarios. By standardizing containers, we can focus on business logic and optimization rather than reinventing core capabilities, thereby reducing costs and accelerating growth.

At this year’s D2 cross‑platform session, experts will discuss the current state and future of cross‑platform technology, offering insights and practical experiences. The conference also covers topics such as Node.js, Swift, front‑end engineering, Flutter, JS engines, networking, AR/VR/3D, and cloud rendering. Interested readers are invited to register.

Click the original article link to learn more about D2.