Changes and Invariants Under Mobile Cross-Platform Technology

1. Cross-Platform, Which Platforms to Cross?

Currently (2020/7/18), mobile cross-platform requirements are mainly concentrated in:

• Cross PC and mobile: In early transition from PC to wireless, hoped PC Web and mobile Web could reuse the same codebase

• Cross Native and Web: Product detail pages etc. require a set of Web pages with similar functionality accessible outside the app, need to cross Native App and Web

• Cross Native dual platforms: For development efficiency reasons, hope Android and iOS dual platforms can reuse one business codebase

• Cross App: Some product features expected to be deployed on multiple channels, mainly tool-type requirements, such as ride-hailing, ticket purchasing, food ordering

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

• Cross lightweight apps: System-level instant-use lightweight applications, such as Android Quick Apps, iOS App Clips

• Cross IoT devices: Various devices with displays will become new "terminals", such as in-vehicle devices, smart homes

• Cross all clients: May be a pseudo-requirement, same product has different focuses on different platforms, perhaps doesn't need to move all features completely to various client devices/platform channels, for example Quick Apps and Native App positioning is obviously different

Under such era background, whether from resource cost, development efficiency, or from product iteration, technology evolution perspective, cross-platform development is a strong requirement, hence the endless exploration of various cross-platform solutions

2. Endless Cross-Platform Technologies

Counting mainstream mobile cross-platform solutions in recent years, can be roughly divided into 3 categories:

• Web born cross-platform: As long as there's browser or WebView, relying on Web technology can easily cross platforms, such as Web App, PWA (Progressive Web Apps), Hybrid App, PHA (Progress Hybrid App)

• Containerized Native cross-end: Transform Native App into standardized container, then allow one codebase to run across multiple end standard containers, such as React Native/Weex, Flutter

• Mini program one code multiple deployments cross App: In domestic market, more and more super Apps support mini programs, but each mini program framework doesn't have unified standard, so there are Taro, kbone, uni-app and other series of cross mini program framework solutions to meet cross App deployment product feature requirements

Cross-Platform: Web's Innate Advantage

Cross-platform is Web's innate advantage, browsers and WebViews are all standardized Web containers under W3C specification, therefore Web pages can be easily deployed to external browsers, internal WebViews, and WebViews provided by other Apps

From cost perspective alone, Web solution is the best choice for cross-platform:

• No additional learning cost: One basic technology works across internal, external, even PC browsers, TV set-top boxes

• Doesn't rely on special supporting facilities: Development, debugging, building, publishing, monitoring, operations etc. all engineering links are universal

• Possesses huge existing ecosystem: npm millions of modules, has everything

• Web based on open standards: Going out and bringing in are both not difficult

Moreover, Web itself is a platform, can retreat and defend, technology risk is lower

But in some other aspects, relying on Web technology for cross-end also has its limitations:

• Platform capabilities: Limited by Web standard container, cannot meet platform capability related requirements, such as camera, Bluetooth, multimedia etc.

• Experience: Mobile Web experience far inferior to Native, mainly reflected in first screen loading slow, animation stuttering, long page scrolling flickering etc. scenarios

• Performance: High memory consumption, low GPU utilization

Plus Web standard updates slowly, new feature compatibility is poor (such as Push API has been many years, still cannot use with confidence), Web basic capabilities difficult to meet Native end requirements. Therefore, on basis of traditional Web App, expanded more exploration:

• PWA (Progressive Web Apps): Web App with offline caching, system notifications, home screen icons etc. Native App-like capabilities, but compatibility is not optimistic

• Hybrid App: Web and Native mixed solution, platform capabilities implemented by Native (such as scanning QR codes) injected into WebView environment for Web App use, to extend Web's platform capabilities

• PHA (Progressive Hybrid App): Combination of PWA and Hybrid thinking, using Hybrid means to make Web performance and experience close to Native

PWA standardization seems not working, even if it works, may take years to truly use with confidence. Hybrid App solved some problems (platform capability extension), but not enough. PHA is continuation of these two ideas, using Native technology to realize PWA's dream

But whether PHA or HA, introducing Native dependency means loss of Web openness, subsequently bringing cross-end, cross App problems

Cross-End: Containerized Native

Besides Web's natural cross-end, another unified multi-end thinking is to customize Native into standard container, let same code run in standard containers, for example:

• Android container: Native shell App

• iOS container: Native shell App

• Web container: Web Runtime

React Native crosses Android, iOS, Web, Windows four ends, Weex crosses Android, iOS, Web three ends, Flutter similarly crosses Android, iOS, Web, Linux four ends

From technology perspective, RN and Weex provide JavaScript runtime environment, and layout engine in Native container, rendering layer all uses Native controls, therefore UI interaction still has system differences. While Flutter solution is more thorough, even rendering layer changed to self-drawn UI controls based on graphics engine, thus ensuring UI interaction cross-end consistency

However, because containerized Native solution starts from Native, has no cross-end talent, besides figuring out how to support Web, also faces a more difficult problem—cross App

Cross App: Mini Program One Code Multiple Deployments

From technology perspective, mini program cross Native App still relies on Web solution, then, why not directly use Web App?

Due to commercial competition etc. factors, Web Apps breaking into others' territory usually encounter some restrictions, such as security warnings, permission control, or even outright access prohibition (hence the convoluted ways like password sharing)

Mini programs are different, their original intention is open, welcome everyone to settle in (of course, must follow rules), and many large domestic Apps have also opened mini program capabilities, mini programs gradually becoming formal way for cross App. But after mini program platforms multiplied, framework standard unification problem also exposed, all called mini programs, but all similar yet different, so, how to quickly produce multiple mini programs became a technical topic worth exploring

Implementation principles divided into two, compilation conversion and runtime adaptation, former can achieve performance equal to native mini programs but brings many restrictions (writing styles difficult to identify at compile time are not supported), existing Web Apps not so easy to migrate to cross App mini programs, such as Taro, uni-app etc. Latter sacrifices performance for more possibilities, existing Web Apps can relatively easily migrate over, such as Taro Next, kbone etc.

P.S. Of course, can also have dynamic-static combination thinking, ideally, vast majority of basic business goes runtime flat migration, individual high-performance requirements parts go compilation conversion

3. Amidst All Changes, What Remains Invariant?

Channels/ends/platforms, business code, engineering supporting facilities all seem to be changing rapidly, none is stable and unchanging

Since everything is changing, change perspective, which part will definitely change?

• Container: New channels/ends/platforms are all new containers

• Cross-container technology: Emergence of new containers means new cross-container technology requirements

Which part is unnecessary to change along with?

• Business code: Technology solution iterations, emergence of new channels/ends/platforms, usually accompanied by business code migration, Native switch React Native switch Flutter... endlessly, but from cost perspective, business code doesn't necessarily and shouldn't change along

• Engineering supporting facilities: Mostly strongly related to technology stack, for example Web App development, debugging, building, publishing, monitoring, operations has many differences from Native App, but more basic parts are technology-independent, and process-related, such as build-publish processes, monitoring operations services don't need to change along

• Platform capabilities in container: Regardless of what cross-container solution, platform capability extension requirements are consistent, corresponding Native module encapsulation shouldn't change along

Business code migration cost is very high (more painful when involving technology stack changes), supporting facilities teardown and rebuild is definitely major project, then, is there a way to fix these parts that shouldn't change along?

Yes, abstract away the changing parts. Depend on abstraction not concrete, upper layer doesn't need to change along:

Standard Framework   \
---------  |  Supporting Facilities
Standard Container   /

Under such abstraction model, upper business code depends on standard business framework, not directly on container capabilities, thus allowing parts below business framework to be replaceable. Business framework depends on abstract standard container, not bound to specific particular container, replaceable with other containers following container standard

Based on standard framework, can provide supporting development tools like scaffolding, component libraries, visual building etc. Based on standard container, can establish supporting debugging capabilities like performance diagnosis, event tracking etc., thus covering entire engineering chain, supporting facilities also almost don't need to change along

As for platform capability extension, as important part of standard container, should also abstract standard API (analogous to BOM series API provided by browsers), for upper business use

4. Future of Cross-Platform Technology

Cannot predict future, so here throw out several possibilities:

• Mobile cross-end only crosses Native dual ends: For many mobile products, delicate experience, excellent performance Native App is still currently most important application form, and dual end features completely consistent, equally important, so only cross Android, iOS two ends, unifying mobile Native development is relatively reasonable solution

• Mini program cross App self-contained: If mini programs cannot truly standardize, cross App deployment requirements spawned cross mini program framework solutions have necessity to exist

• Web still Web, Hybrid will continue: Web feature iteration cycle too long, mobile device iteration too slow, can't wait for Web's year-unit evolution speed, relying on Native to enhance Web's Hybrid transition solution likely long-term "transition"

P.S. Mini programs already in standardization process, mini program framework becoming standardized container is also not impossible, after all mini program framework doesn't have WebView, browser-like slow cycle resistance

Not optimistic about one trick eats all cross-all-ends solution, because whether universal components or universal API are all minimum intersection, cannot meet actual needs. Moreover, really need to let one codebase run on all channels, ends, platforms?

Same product has different focuses on different platforms, perhaps doesn't need to move all features completely to various client devices/platform channels, for example Quick Apps and Native App positioning is obviously different

Reference Materials

• Why Rax?