A detailed account of the 10 years of coexistence of Web technology and Native App

If the WeChat public account in the past was still a media platform, then the public account in 2016 will have a new form, called application account. Application account indicates more powerful functions, better experience and richer services than public account. The emergence of application account is a major upgrade of WeChat products. Whether it is to reflect user values? Or to pursue product commercialization? As a technician, I don’t want to discuss too much, but I would rather analyze some of the development of Web technology from a technical perspective.

As a super app, WeChat has huge entry traffic and needs to continuously generate dynamic content. Web technology has always played an important role in WeChat. If the official account is still standard Web technology + simple bridge extension, then in the application account, Web technology will rely on a more powerful Web execution container to play a greater role in WeChat. Let's take a look at the combination of Web and Native technologies in WeChat, from the embedded system Webview, to the X5 enhanced browser engine, to the function-expanded JS-SDK, to the newly released weUI, and then to the application account. The WeChat team has been promoting the integration and development of Web technology in Native App.

With the rapid upgrading of mobile devices, Web technologies represented by HTML5 have more and more application scenarios in NativeApp. On the one hand, Native App development teams need to improve development efficiency and reduce operating costs while ensuring functionality and performance; on the other hand, App users need to obtain dynamic content faster while meeting their needs and experience; all of these require Web technologies to play an increasingly important role and value in App development. However, this value cannot be called separation or subversion. Today, it is more about "integration"!

I have been working on browser engines and cross-platform App engines for 10 years since 2006. I have witnessed the continuous application and development of Web technology in Native Apps over the past 10 years. From feature phones to smartphones, from k-java to mobile apps, from WebBrowser to Webkit, we can divide the development of Web technology in Native Apps into five stages: built-in, embedded, bridged, hybrid, and integrated.

1. The era of built-in custom web containers

Before 2010, feature phones were still the mainstream, with low hardware configuration, weak system functions, and built-in mobile applications. However, SP services have made great progress, and users need to dynamically obtain content to meet their information and entertainment needs. During this period, the use of Web technology in Native applications was that Native application developers cooperated with browser manufacturers and built a browser engine of a certain manufacturer into the application as a Web execution container. The application dynamically downloaded web files from the server, decompressed them and handed them over to the Web container for offline operation. The content and functions were very simple, usually just the layout of pictures + text, and key interaction. The forms were books, magazines, small games, and small tools. Such needs also drove some mainstream browser manufacturers at the time to think about the role of browsers beyond traditional values, and actively participated in the formulation of W3C Widget specifications. This period was also the golden age of mobile browser manufacturers.

2. Embedded System Webview Era

In 2010, the Android system became popular in China, and the iPhone gradually became popular. The native application ecosystem dominated by Android and iOS began to continuously cultivate users to download applications from the AppStore and use independent apps as the entry point. During this period, the demand for app development also gradually increased, but the competition was not fierce. Customers could accept the native development cost and cycle. Application developers made huge profits, and developers began to learn Android and iOS app development. The functions and performance of the system's built-in browser had surpassed the third-party browsers at the time. It was common to display local or server-side interfaces in apps by embedding system Webview. During this period, the application of Web technology was mainly content display, and the functions that could be completed were limited to the scope supported by standard browsers. The business model of traditional browser manufacturers relying on Lisence charging ended and gradually faded out of the market.

3. Webview's Bridge Extension Era

In 2011, Android and iOS gradually dominated the mobile phone system. The demand for App development increased rapidly, competition intensified, and native developers were in short supply. Customers began to consider costs and cycles, and developers began to consider efficiency and profits. Developers began to think whether Webview could complete some App functions in addition to displaying content. Since the system is built-in with Webkit engine, it supports standard Web technology and supports open extensions. Domestic and foreign manufacturers represented by Phone Gap began to bridge and extend Webview, and formed a complete calling mechanism, which can call native interfaces arbitrarily in JS.

This type of bridge extension mainly focuses on device functions and provides a capability, but more specific mappings still need to be completed by the developer himself. Since there are no extensions involving window systems, interactive responses, animation effects, event management, and application lifecycle management, although the basic functions of the developed App can meet the needs, the performance and experience are too poor. At this time, through the Webview + bridge extension method, native engineers and Web engineers can work together to complete the development of an App. The trend of using standard Web technologies (HTML, CSS, JS) and bridge extension mechanisms in mobile apps during this period also caused the demise of a number of traditional mobile middleware manufacturers that used non-standard web technologies (custom XML tags and JS syntax).

The Hybrid App Era of Four Mobile Application Development Platforms

Since 2012, App startups have been booming, and App demand has continued to grow, with more application scenarios and industry combinations: LBS, IoT, O2O, social, video, etc. On the one hand, using HTML + CSS for interface layout has performance issues with Dom tree updates and single-layer rendering, and the capabilities supported by standard JavaScript specifications are very limited, requiring a lot of expansion to meet industry needs; on the other hand, the native development model is costly and inefficient, and the industry calls for a more efficient cross-platform development model.

During this period, cross-platform technologies at home and abroad have emerged in an endless stream, and new products have continued to emerge, but we can divide them into two categories:

One is to continue to use HTML + CSS for interface layout, and achieve cross-platform App development by optimizing page rendering and natively extending standard JS.

The other is to abandon the use of HTML + CSS interface layout, and choose a third-party intermediate language (such as JS, C#, etc.) to map to Android and iOS system calls, so as to achieve cross-platform. This method of interface layout needs to be completed by combining system UI components through the intermediate language. At present, the rendering performance is better than the HTML + CSS method, but this also loses the standardization and flexibility of HTML + CSS layout.

This article mainly discusses the development process of Web technology in App, which is impossible without HTML and CSS, so here we will focus on the cross-platform products of the *** category (Web + Native hybrid). For example, although ReactNative chooses JS as the third-party language, it can also choose other languages. Since HTML and CSS are no longer the way to layout its interface, I think it has deviated from the standard Web technology and will not discuss it too much here.

At this time, HTML5 in China was becoming increasingly popular, and a large number of Web programmers were looking forward to entering the field of Native App development. At this time, mobile application development platforms (Web + Native hybrid) for Web engineers began to appear, providing one-stop cross-platform App development and management services, forming a new model combining Web technology with Native App.

HybridApp is a Native App development model based on Web technology. Developers do not need to have any Native skills. They can use standard web technology and call the platform's extended API to develop independent cross-platform apps. And the App's functions, performance and experience can be guaranteed.

The Hybrid App engine needs to provide more functions based on the bridge extension, such as:

1. MVC architecture;

2. Application lifecycle and unified event management;

3. Optimize interactive response, animation effects, data caching, etc.;

4. Mixed rendering of web interface and Native components;

5. Rich independent functional modules and aggregated open platform API;

6. Extend the mainstream HTML editor to support App development;

7. App security mechanism and full encryption of Web code;

During this period, excellent cross-platform App engines emerged, such as APICloud DeepEngine. Deep Engine can reduce development costs, improve development efficiency, and develop commercial Apps that meet customer needs and user experience. Based on APICloud, customers have also developed mainstream high-quality applications with over 10 million installations.

5. The era of integration based on SuperWebview

In 2016, although Hybrid App has been widely recognized by the industry, Native is still the mainstream development model, and most high-quality Apps are native. How can Web technology be used in these Native Apps? How can Web technology be used in these mainstream Apps to complete some functions while ensuring the performance and experience of the App? How can Native engineers and Web engineers collaborate better?

To solve these problems, we cannot just embed a system Webview or introduce a bridge extension mechanism. Instead, we need a powerful and complete super Webview that dynamically generates a dedicated SDK for each application based on the actual configuration. This super Webview should have the following functions:

1. Powerful functions, with MVC architecture and performance optimization;

2. Aggregate API, support extension modules and open platform services;

3. Dynamic generation: dynamically generate a dedicated SDK for each application based on the configuration;

4. Cloud repair, implements in-app update functionality.

Facilitate collaboration, maintain the independence of Web and Native development, reduce integration costs, and improve efficiency.

APICloud launched SuperWebview, a breakthrough product at the beginning of 2016. The emergence of SuperWebview will surely accelerate the integration of Web technology in Native Apps and play a greater role in high-quality Native Apps and even Super Apps. After integrating SuperWebview, any Native App can significantly shorten the iteration cycle and support dynamic addition of functions. Some functional updates implemented by Web technology do not need to be repeatedly submitted to AppStore for review. Users do not need to download and install again.

When developing an App, who should be the protagonist? Native+Web, or Web+Native? It depends on who is more suitable to be the protagonist, and whoever is the protagonist can perform the play well. A good play cannot have only one protagonist, and only when they complement each other can they perform a good play.

Native App was born with mobile devices, and Web technology has been complementary and coexisting with Native App since its birth. APICloud has never thought of "subversion", but only wants to provide a practical and efficient App development method to better integrate Web technology and Native App and give full play to their respective advantages and values.

Transcendence comes from integration!