What has changed and what hasn’t changed under mobile cross-platform technology

1. Cross-platform, which platforms do you want to cross?

At present, the cross-platform demand for mobile terminals is mainly concentrated in:

• Cross-PC and mobile: In the early days of the transition from PC to wireless, it is hoped that PC Web and mobile Web can reuse the same set of code
• Cross-Native and Web: Product detail pages require a set of web pages with similar functions that can be accessed outside the client, which requires cross-Native App and Web
• Cross-Native dual-end: For development efficiency and other reasons, it is hoped that Android and iOS dual-ends will reuse a set of business codes
• Cross-app: Some product functions are expected to be launched on multiple channels, mainly for tool-based needs, such as taxi-hailing, ticket purchase, and food ordering.

In the foreseeable future, there may be these cross-platform requirements:

• Cross-light applications: Lightweight applications that can be used and used at the system level, such as Android Quick Apps and iOS App Clips
• Cross-IoT devices: Various devices with display screens will become new “ends”, such as in-vehicle devices, smart homes
• Across all clients: This may be a false demand. The same product has different focuses on different platforms. It may not be necessary to move all functions to a variety of client devices/platform channels. For example, the positioning of quick apps and native apps is obviously different.

In this era, cross-platform development is a strong demand from the perspective of resource cost, development efficiency, product iteration, and technological evolution. Therefore, there are endless cross-platform solutions.

2. The emergence of cross-platform technologies

The mainstream cross-platform mobile solutions in the industry in recent years can be roughly divided into three categories:

• Web is born cross-platform: As long as there is a browser or WebView, you can easily cross platforms by relying on Web technology, such as Web App, PWA (Progressive Web Apps), Hybrid App, PHA (Progress Hybrid App)
• Containerized Native Cross-Device: Transform Native App into a standardized container, allowing a set of code to run across multiple standard containers, such as React Native/Weex, Flutter
• Mini Programs: One code for multiple cross-app delivery: In the domestic market, more and more super apps support mini programs, but their mini program frameworks do not have a unified standard. Therefore, a series of cross-mini program framework solutions such as Taro, kbone, and uni-app have emerged to meet the needs of cross-app delivery of product functions.

Cross-platform: The Web is born with it

Cross-platform is an inherent advantage of the Web. Browsers and WebView are both standardized Web containers under the W3C specification, so Web pages can be easily delivered to browsers outside the terminal, WebViews within the terminal, and WebViews provided by other apps.

From a cost perspective alone, the Web solution is the only cross-platform choice:

• No additional learning cost: a set of basic technologies can be used in both end-to-end and end-to-end, and even PC browsers and TV set-top boxes.
• No reliance on special supporting facilities: all engineering links such as development, debugging, building, publishing, monitoring, and operation and maintenance are universal
• Sitting on a huge existing ecosystem: npm has millions of modules, everything you need
• Web is based on open standards: it is not difficult to go abroad and introduce

Moreover, the Web itself is a platform, which allows for defensiveness and lower technical risks.

But in other aspects, relying on Web technology across terminals also has its limitations:

• Platform capabilities: Limited by the Web standard container, it cannot meet the requirements related to platform capabilities, such as camera, Bluetooth, multimedia, etc.
• Experience: The mobile web experience is far inferior to Native, which is mainly reflected in the slow loading of the first screen, animation freezes, long page scrolling flickering and other scenes.
• Performance: High memory consumption, low GPU utilization

In addition, Web standards are changing slowly, new features have poor compatibility (for example, the Push API has been around for many years but is still not usable with confidence), and Web basic capabilities are difficult to meet the needs of the Native side. Therefore, based on traditional Web Apps, we have conducted more explorations:

• PWA (Progressive Web Apps): Web Apps with Native App-like capabilities such as offline caching, system notifications, and home screen icons, but compatibility is not optimistic
• Hybrid App: A hybrid solution of Web and Native, which injects the platform capabilities implemented by Native (such as scanning QR codes) into the WebView environment for use by Web App to expand the platform capabilities of Web.
• PHA (Progressive Hybrid App): A combination of PWA and Hybrid concepts, using Hybrid methods to bring Web performance and experience close to Native

PWA standardization seems to be unworkable, and even if it is, it may take several years before it can be used with confidence. Hybrid App solves part of the problem (platform capability expansion), but it is not enough. PHA is the continuation of these two ideas, using Native technology to realize the dream of PWA

But whether it is PHA or HA, the introduction of Native dependencies means the loss of Web openness, which in turn brings cross-terminal and cross-App problems.

Cross-end: Containerized Native

In addition to the natural cross-terminal nature of the Web, another way to unify multiple terminals is to customize Native into a standard container and let the same code run in each standard container, for example:

• Android container: Native shell App
• iOS container: Native Shell App
• Web Container: Web Runtime
• React Native supports Android, iOS, Web, and Windows. Weex supports Android, iOS, and Web. Flutter supports Android, iOS, Web, and Linux in a similar way.

From a technical perspective, RN and Weex provide a JavaScript runtime environment and layout engine in the Native container, and both use Native controls for the rendering layer, so there are still system differences in UI interaction. The Flutter solution is more thorough, and even the rendering layer is replaced with a self-drawn UI control based on the graphics engine, thus ensuring cross-end consistency of UI interaction.

However, since the solution of containerized Native is based on Native and has no cross-end capabilities, in addition to finding ways to support the Web, it also faces a more difficult problem to solve - cross-App

Cross-App: One code for multiple investments in mini programs

From a technical perspective, Mini Programs across Native Apps still rely on Web solutions, so why not use Web Apps directly?

Due to commercial competition and other factors, Web Apps that intrude on other people's turf are usually subject to some restrictions, such as security warnings, permission control, or even access prohibition (hence the roundabout methods such as password sharing)

Mini Programs are different. Their original intention was to be open and everyone is welcome to join (of course, they must abide by the rules). Many large domestic apps have also opened up their mini program capabilities, and mini programs have gradually become a formal way to cross apps. However, as the number of mini program platforms increased, the problem of inconsistent framework standards was exposed. They are all called mini programs, but they are all similar. Therefore, how to quickly produce a variety of mini programs has become a technical topic worth exploring.

There are two implementation principles: compilation conversion and runtime adaptation. The former can achieve the same performance as native applets but brings many limitations (writing methods that are difficult for the compiler to recognize are not supported). Existing Web Apps are not so easy to migrate to cross-App applets, such as Taro, uni-app, etc. The latter sacrifices performance in exchange for more possibilities. Existing Web Apps can be migrated relatively easily, such as Taro Next, kbone, etc.

PS Of course, you can also have a combination of dynamic and static ideas. Ideally, most basic services are migrated during runtime, and some parts with high performance requirements are converted by compilation.

3. What is the constant in the midst of all the changes?

Channels/ends/platforms, business codes, and engineering supporting facilities all seem to be changing rapidly, and none of them are stable.

Since everything is changing, let's look at it from another angle. Which part will definitely change?

• Containers: New channels/ends/platforms are all new containers
• Cross-container technology: The emergence of new containers means new cross-container technology requirements

Which part does not need to change?

• Business code: The change of technical solutions and the emergence of new channels/ends/platforms are usually accompanied by the migration of business code, such as Native to React Native to Flutter... However, from a cost perspective, business code does not necessarily and should not change accordingly.
• Engineering supporting facilities: Most of them are strongly related to the technology stack. For example, the development, debugging, construction, release, monitoring, and operation and maintenance of Web Apps are very different from those of Native Apps, but the more basic parts are technology-independent, and process-related parts, such as the build-release process, monitoring and operation and maintenance services, do not need to change accordingly.
• Platform capabilities in containers: Regardless of the cross-container solution, the platform capability expansion requirements are the same, and the corresponding Native module encapsulation should not change accordingly.

The cost of business code migration is very high (even more painful when it involves changes in the technology stack), and the demolition and reconstruction of supporting facilities is definitely a large project. So, is there a way to fix these parts that should not change?

Yes, abstract away the changing parts. Rely on the abstraction instead of the concrete, and the upper layer does not need to change accordingly:

 Standard framework \
 --------- | Supporting Facilities  
 Standard container /

In this abstract model, the upper-level business code relies on the standard business framework instead of directly relying on container capabilities, allowing the parts below the business framework to be replaced. The business framework relies on an abstract standard container instead of being bound to a specific container, and can be replaced with other containers that follow the container standard.

Based on the standard framework, it can provide supporting development tools such as scaffolding, component library, and visual construction. Based on the standard container, it can establish supporting debugging capabilities such as performance diagnosis and event tracking, thus covering the entire engineering link, and the supporting facilities almost do not need to change.

As for platform capability expansion, as an important part of the standard container, a standard API should also be abstracted (similar to the BOM API provided by the browser) for use by upper-level businesses.

4. The future of cross-platform technology

The future is unpredictable, so here are a few possibilities:

• Mobile cross-end only crosses Native ends: For many mobile products, Native App with exquisite experience and excellent performance is still the most important application form, and the functions of both ends are completely consistent and equally important. Therefore, it is a relatively reasonable solution to only cross Android and iOS ends and unify mobile Native development.
• Mini Programs are self-contained across multiple apps: If Mini Programs cannot be truly standardized, a cross-app delivery demand will necessitate the existence of a cross-Mini Program framework solution
• The Web is still the Web, and Hybrid will continue: The Web feature update cycle is too long, and the update of mobile devices is too slow. They cannot wait for the Web to evolve at a rate of years. The hybrid transition solution that relies on Native to enhance the Web is likely to be a long-term "transition".

PS Mini Programs are already in the process of standardization, and it is not impossible for the Mini Program framework to become a standardized container. After all, the Mini Program framework does not have the same slow cycle resistance as WebView and browsers.

I don’t think a one-size-fits-all solution is a good idea, because both universal components and universal APIs are minimal and cannot meet actual needs. In addition, do we really need to run one set of code on all channels, terminals, and platforms?