Deviceone: Standing at the crossroads of the mobile Internet era

Recently, I often see articles like "App is dead, service is immortal", "App must die, web is immortal", "App is dead, WeChat website building is born". I don't know whether these online writers want to represent the position of certain companies or express some complex. The tone of the articles is so affirmative, as if everyone really has some hatred or grudge.

Looking back at the history of software development, when C++ became popular, some people predicted that C was dead because of its excellent object-oriented capabilities; when Java became popular, some people predicted that C++ was dead because of its excellent cross-platform capabilities and complete memory management mechanism; in the era of web popularity, some people predicted that native applications were dead because they were optimistic about this lightweight B/S interaction mode. But in fact: after so many years, according to the programming language ranking results released by TIOBE (February 2015 version), the two ancient languages ​​​​C and C++ are both in the top 3; native applications have also returned to the mainstream in the era of smartphones. The development of science and technology is like the evolution of nature, which is an extremely complex process. If we insist on trying to explain or predict this process evolution from a simple perspective, the results are often relatively one-sided. From the T/S architecture of the mainframe era, to the C/S architecture of the PC era, the B/S architecture of the Internet era, and the IaaS, PaaS, SaaS and BaaS architectures proposed in the mobile Internet and big data era; all software architectures serve specific technology eras and application environments. Just like the discussion of "Java is better or .net is better", which has never stopped in recent years, and people are almost tired of hearing it. But in the end, what does it matter? Both Java and .net have developed well. Will the development of science and technology be affected by the subjective inclination of some people? Technology itself is neither good nor bad. At most, we can only say which technology is more suitable for you. So when we discuss propositions such as which technology is better and which technology is not, we should first clarify a major premise: what exactly do we want to do?

Service or App?

The services we are talking about should usually be understood as BAAS services in the mobile Internet era, that is, cloud services provided for mobile Internet application development. Its main contents include: data storage, data push, version management, data statistics and other major services. It can be seen that services and apps are two different things, and they should not be compared with each other, let alone one can replace the other. Some people have changed the concept and even used WeChat service accounts as services in the article. Although this statement is not up to standard, it is ulterior motives and is not worth our excessive discussion.

Web or App?

In October last year, the HTML Working Group of W3C officially released the official recommendation standard of HTML5 (W3C Recommendation). This news made many people full of encouragement, and some people concluded that the web would return and apps would die. But when we carefully read the official HTML5 development plan of W3C, we may find that the reality is not as optimistic as we thought:

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

The official W3C announcement said: "Modularity has always played an important role in the standards-making process. In order to achieve independent and rapid evolution of functions, the working group will use so-called 'extension specifications'. Some will eventually be published as independent documents and become part of the HTML specification family, while others will be integrated into the HTML5 specification and become the basis."

At present, HTML5.1 is the real HTML5, and HTML5 is just a compromise. Just like Microsoft's upgrade from Windows 8 to Windows 8.1, the timely launch of Windows 8 is entirely a marketing strategy, and although Windows 8.1 is only a minor version change, it has made huge adjustments at the system architecture level. After HTML5.1 is expected to be released in the fourth quarter of 2016, the working group will repeat the above steps to create a new HTML5.2 to continue to improve and enrich the functions. The specific time is not mentioned, but it is estimated to be in 2018. From the announcement of each HTML5 solution to the stable support of several major manufacturers' browsers, it usually takes at least more than one year to wait. Even if we wait for the arrival of HTML5.1 or HTML5.2, will it be able to fully solve our mobile application development problems?

HTML5 standard has already been a real-time standard a few years before it was officially adopted. Whether it is the Webkit kernel, Firefox kernel, or IE kernel (version 9.0 and later), they have all achieved full compatibility with it. Mobile middleware based on HTML5 technology, led by PhoneGap products, appeared as early as 2008. In fact, our own middleware products were also based on HTML5 technology before 3.0. However, over the past few years, this type of middleware technology has not achieved a large-scale replacement for native App development, but has been increasingly forgotten by developers. It is no wonder that it is really difficult for us to find an application that is completely based on HTML5 technology and is considered to be excellent in the AppStore. Although the model of HTML5 technology combined with native App development is relatively mature, if we want HTML5 technology to completely replace native App development, its feasibility should still remain on the road of practice for so many years...

The draft of HTML5 was first accepted by W3C in 2007, and the first generation of iPhone was released in September of the same year. To be precise, the original design of HTML5 did not take into account the architecture of existing smartphones at all, and was not born for the smartphone era. I think the improvement of mainstream mobile application development technology in the future will first be reflected in the following three aspects: the labeling of UI views, the scripting of logical languages, and the openness of underlying technologies. At first glance, HTML/HTML5 technology has naturally met the first two, but in fact it is not. There is an essential difference between the implementation process of browser DOM and the implementation process of native UI, which determines that there is no smooth transition from web pages to native pages. For the openness of underlying technologies, we should not only stay at the simple API expansion capability, but also support the expansion of UI tags. Perhaps we can look forward to the arrival of HTML6 standards in the future, or perhaps HTML standards are not necessary at all on mobile terminals, and we can find better alternatives.

Facebook's technology development route on the mobile side is a good verification of the above technology development trends. Facebook has previously launched the react framework. Although it adopts a new idea based on the front-end UI framework of the browser DOM, it also completely takes over the most complex local update part in UI development, and is good at ensuring high performance in complex scenarios. Although the react framework is already very good in the web system, the web is the web after all. No matter how it is improved, it still cannot achieve the effect of native applications. Facebook finally gave up the HTML5 solution and switched to a pure native development mode on the mobile side. Recently, Facebook officially announced that they will launch the react-native plan. React Native does not use DOM at all. Developers can use <View> instead of <div>, use <Image> instead of <img>, etc., can expand custom tags and realize native docking, and can use JavaScript to write high-quality applications. In my opinion, although react-native has not yet been officially launched, its technical structure is already the most advanced and most representative of future development trends among known middleware products. The labeling of UI views, scripting of logical languages, and open capabilities of underlying technologies that it advocates have a tacit understanding with the ZBuilder4.0 product.

Why do we have to separate the Web model and the native App model? The two have their own advantages. The Web has become a part of the App, and it is integrated with the App components to complete its own work. Therefore, we need both the Web and the App, and we should combine them to complement each other.

WeChat or App?

When it comes to WeChat applications, I admire them from the bottom of my heart. It is really impressive that domestic App products can achieve such an excellent level. Today, the number of registered users of WeChat applications has grown to more than 600 million, and its market development positioning is far more than the simple voice communication and instant messaging when it started. The sharing module of Moments has allowed WeChat to occupy the high ground of mobile social networks; the public account and open platform have made WeChat an information portal for smartphones; the scan function has made WeChat a standard entrance for mobile terminals to access web pages or download applications; now WeChat has opened up device access capabilities, not only preparing for the development of the O2O market, but also starting to get involved in the field of personal health devices. In addition to the heavyweight giant functions such as WeChat Wallet, WeChat Payment, WeChat Mall, and WeChat Games, WeChat really has its tentacles everywhere. A detailed analysis of these functions of WeChat actually involves the core service scope of many Internet giants such as Yahoo, Google, Facebook, Alibaba and Apple. Some time ago, WeChat released a new function and launched a pilot in Guangzhou, Shenzhen and Foshan to start a new field of urban services. Tencent's overall layout is so large that it seems that it really wants WeChat to be the "only application entrance" for mobile Internet. Its ambition is already very obvious.

We don’t need to be frightened by the surging offensive of WeChat. If we think calmly, WeChat’s rapid expansion and rapid expansion strategy is not that scary. Each vertically segmented industry has its own value measurement standard. Short-term traffic is futile without long-term high-quality services as a basis. Only by insisting on quality and value can we achieve the right path. Just like QQ back then, the large amount of traffic brought by instant messaging can indeed drive a huge eyeball economy, such as the rapid development of Tencent Games. However, Tencent has also invested heavily in trying to build search engines, news information, and online shopping, but ultimately failed.

Everything goes to the extreme and then turns to the opposite. Today, WeChat is indeed too strong and too big. It is so strong that people worry whether it has already touched the natural development law of "decentralization". What people really cannot do without is "point-to-point" communication (instant messaging), not point-to-many communication (social network). WeChat's biggest weakness should be people's desire for "private small circles", which is precisely the reason why WeChat was successful in the early days. So far, WeChat users have been increasing. Each of us can see our relatives, colleagues, leaders, various types of customers, and a large number of people who sell things (to put it nicely, people who do WeChat marketing) on ​​WeChat, causing the original private space to become less and less private. If this continues, WeChat may also face a situation similar to "a large number of users fleeing Facebook". Similar situations have also occurred in China. At the beginning, everyone flocked to Kaixin.com. They had never played this kind of thing before. After the enthusiasm, they all fled!

Even ordinary web pages opened in WeChat will make people feel sparkling at first glance. However, mobile terminals are different from PC terminals after all, and the user experience of various subdivided functions is still crucial in the long run. WeChat also has its own technical shortcomings, for example: WeChat's web extension application must be opened in a network environment; WeChat's own "Back" key and the "Back" key in the web application will interfere with each other, etc. But there is no way, the expansion capabilities supported by WeChat are limited to the Web. The installation package of WeChat's latest version is already more than 55M. Unlimited addition of functions will only make WeChat more and more bloated and accelerate its destruction. If you want to expect to expand real-time navigation, virtual reality, document parsing, facial recognition, 3D control, offline maps and other functions in WeChat, I'm sorry, these functions cannot be done in WeChat.

Today, WeChat has become one of the important channels for the release of mobile applications, with a trend of "Apple, Android, and WeChat are all indispensable". Whether it is smart city applications or industry solution applications, we must maintain the synchronous development of several platforms such as Apple, Android, and WeChat (including Windows Phone in the future), and control risks. Don't invest all resources in one channel, especially don't easily bet all on the WeChat platform, and fully consider future risks. Just like in the crazy era of "pagers, mobile phones, and business communication are all indispensable", those agents who invested heavily in pagers or business communication, the end of the world is almost the same as pagers or business communication, all disappeared.

It is still very difficult for WeChat to become the only entrance to mobile terminals. WeChat is just an ordinary application. No matter how powerful it is, it must run on Apple and Android systems. In particular, Apple has been constantly adjusting its policy requirements for online apps every year, while WeChat is still opening and expanding third-party applications. Who can guarantee that Apple will not turn against WeChat one day? In the Android system system, companies such as Alibaba, Baidu, Xiaomi, and Meizu are all making their own cloud operating systems based on the Android kernel, and these systems have a very high market share in China. The balanced development of the IT ecosystem, with both mutual dependence and mutual restraint between upstream and downstream, in the long run, it is impossible for WeChat to have the final say in the dominant position. As Ma Huateng himself said, "It will definitely not be WeChat that defeats WeChat, but something else that is more fun." The development of science and technology is constantly moving forward at all times, and this may not be alarmist.

So, we want native apps and WeChat, but not just WeChat.

The confusion of native development

When we say that Apps will never die, does that not mean that Apps are good? In fact, developing Apps is an extremely painful process. There are always people who find some reasons to say that Apps are dead, and some people even express hostility towards the native App development model. These also have their practical reasons, which I can fully understand. The era of smartphones has indeed developed too rapidly. In addition to causing a strong impact on traditional industries, it has also caused a significant imbalance of some resources within the IT industry. Objectively speaking, for most mobile application projects, the native development process is definitely an expensive trap. At present, the salary level of native developers (especially IOS developers) is indeed too high: fresh graduates can get a monthly salary of 10K after 2-3 months of training. Those with 2-3 years of development experience and some experience dare to ask for a monthly salary of 20K. The explosive growth of App application demand has led to the current situation of market supply and demand, which has made IOS native developers increasingly scarce. The competition is not only irrational, but has even begun to be a little crazy. On Lagou.com, there are many people who can offer a monthly salary of 50K for engineers with more than 3-5 years of native development experience. The most unacceptable thing is that such high salaries are always in short supply. How can most companies in the market tolerate this, and how can those experienced programmers feel?

This reminds me of the situation when the Internet was just emerging in 2000. Before the dot-com bubble burst, freshly graduated students who worked on web pages could get a salary of 10K, which is very similar to the current situation.

Every native application development project is a huge pitfall. Either wait for competitors to defeat you through mobile Internet technology, or jump into the pit and hire people to develop mobile applications yourself. Especially for Internet-oriented 2C applications or BYOD applications within the enterprise, it is necessary to recruit at least two native development teams for IOS and Android, and the development cost will double. The most terrifying thing is that you need to face a large number of underlying technical traps such as black screen, flash back, screen adaptation, etc. In addition, the frequency of technical personnel loss and replacement is high, the maintenance cycle of business systems is long, and there are compatibility issues after the upgrade of the operating system platform (such as the forced adjustment of the IOS7 UI layout structure and the forced upgrade of the 64-bit kernel of IOS8). There are technical traps everywhere, how can the cost of each small project be borne?

Therefore, many developers will naturally think of Web technology and WeChat platform. For some apps with small user range and low requirements, it may not matter. But for some important mobile applications, reducing quality and user experience will often directly lead to the failure of the application.

Native apps do not necessarily have to be developed by pure native developers. In recent years, we have been exploring cross-platform middleware technology for mobile terminals, hoping to significantly reduce the cost of mobile application development.

Where is the way out?

Developing high-quality apps shouldn't be a difficult task. We have always hoped that through the mobile middleware technology platform, ordinary rookies can easily stand on the shoulders of giants. Your application logic is written and run in a unified scripting language, and your application user interface is completely native. It's cool to think about it! The development of science and technology requires more professional division of labor and cooperation: if someone makes a mobile phone, someone will make a CPU module and a camera module; if someone makes an App application, there should be someone who makes the underlying UI components and API components. An excellent mobile middleware product should be able to "allow native developers of expensive projects to focus more on underlying technology innovation and component encapsulation, and allow application developers to focus more on the business needs of specific projects, and achieve the perfect separation of native development and application development!"

The existing mobile middleware development technologies mainly include: pure native development of IOS, Android or Windows Phone; middleware development with Html5 technology as the core (such as PhoneGap, HBuilder, AppCan, ApiCloud), middleware development with OpenGL technology as the core (such as CrossApp), middleware development with code conversion and native reflection technology as the core (such as Titanium, Xamarin, React Native), and middleware development with virtual UI, abstract SDK, and dynamic components as the core (such as DeviceOne).

Although using pure native code to develop apps is the most powerful and flexible, it often faces the following problems: multiple platforms, long development period, and high development cost; native code is too flexible and has too many technical traps, and the uneven level of developers makes it difficult to control the quality of the app; there are too many device models to consider in the project, and the workload of screen adaptation is huge; app upgrades are cumbersome, and even small bug fixes must be approved by the AppStore, and may often be rejected...

When we consider cross-platform requirements, we naturally think of Html5 technology. If it is just a demo or an app with low experience requirements, it is barely acceptable. However, when we really try to use Html5 to make a real App project, we will find that it lacks not only the problem of operating efficiency, but also the gap with the native interactive experience in many aspects. So far, it is difficult for us to find an application made with Html5 framework and with a good experience in the Apple Store. How can we ignore this fact when we are still painfully trying Html5 technology in mobile projects?

Middleware products based on OpenGL technology and code conversion and native reflection technology do not actually have complete cross-platform capabilities. As Facebook officials said, their goal is just to "learn once, write anywhere", not "write once, run anywhere". Using Javascript syntax is just a simple call to the existing iOS library, and the difficulty of development is imaginable.

Middleware with virtual UI, abstract SDK and dynamic components as the core is the most advanced middleware technology. At present, the technical advantages of this type of product are still relatively obvious. However, since the launch time of this type of product is too short and the market has not had enough time to test it, we can only take a wait-and-see and try attitude towards it. Whether it can really become the first mobile middleware platform worthy of our support in the future remains to be seen.

The trend of diversity is a characteristic of the development of the mobile Internet era. Whether it is on the smart device side, the IoT sensor side, or the applications on various terminals, they will become rich and colorful. However, the development of diversity does not mean that the problem of fragmentation cannot be solved. I believe that in the future, everyone’s most commonly used apps should not be too many. Including entertainment applications such as listening to music, watching videos, and playing games, as well as instant messaging applications, city service applications, office management applications, health management applications, personal information management applications, etc. In each vertical segmentation direction, only 1~2 applications may survive in the end. Whether the development cost can be reduced is a matter of life and death for development, but high-quality applications are also crucial for excellent mobile application products. We look forward to the arrival of mobile middleware products that can truly solve the problem one day earlier.