Today, let’s talk about the dynamics of iOS.
The problem
In terms of development mode, web is relatively advanced, with various advantages, including cross-platform /UI development efficiency is high, the most important is to ensure that users can always see the program is the latest, no version concept, the whole system is always kept in control, and the client development mode is a regression to Web development. The client cannot be so dynamic and updated at any time. At present, the cost of updating a client program is very high, and the version needs to be released, and there is no guarantee that all people can update to this version, which is the biggest weakness and a very big demand.
why
The biggest reason for this backsliding is apple’s experience-first rule.
Before the appearance of iPhone, people didn’t care much about the animation experience of a software. A Web application rarely has animation. Click a button to refresh a whole piece of content directly, and then click a link to refresh the whole page white. The PC client software is the same, everyone thought there was no problem and it worked well, but apple changed the situation. When iPhone was first launched, the animation of switching between pages, the silken scrolling of 60fps, and the instant response of clicking, Microsoft people cried it was black magic, making people addicted to using it and never going back. However, the way of Web is not enough to support such fluency as the native client, and it cannot provide good experience and be accepted by people. No matter how many advantages it has in development, it is impossible to run the client. Refer to the disastrous situation of Facebook in the early stage of building app with Web technology, we have no choice but to follow apple’s way. Do a native client.
Of course, there are also reasons for unstable network environment and expensive data, but these can be technically solved by caching, the most important is the experience problem.
Has the experience problem been solved by now? No, even though the performance of mobile phones has reached the sky today, the experience of web is still different from that of the client, and people are already used to the way of APP, but also spoiled by the smooth APP. There are a lot of features in the APP that are implemented on the Web, but everyone knows that it is a trade-off to sacrifice some performance experience for development and release efficiency.
The solution
So how do we solve this problem? There are two solutions in the industry right now.
1. Optimize web performance
Since the disadvantage of developing on the Web is that the performance experience is lagging, optimize the performance. Where are the Web performance bottlenecks? In the old WebKit engine, it has all sorts of historical issues and it’s not easy to improve it. We want the web to be developed and published in a way that doesn’t require the entire web, so can we re-implement a rendering engine that is optimized for native clients, doesn’t need to be compliant with web standards, doesn’t have to be tied to the history of the Web, Hence React Native and Weex solutions. Web development and Native rendering, with excellent web development and distribution methods and excellent performance experience, seem perfect and promising solutions.
Whether a program can be popularized and used by everyone depends mainly on costs and benefits. At present, the access costs of React Native, Weex and other solutions are very high. First, they are large frameworks themselves with high learning costs, as well as maintenance costs and team learning costs. Second, they are not mature enough and are still filling pits. They may need to be filled pits together in the process of use. As far as the current situation is concerned, they can replace those modules that were originally implemented with H5. The performance experience will be better after being implemented in this way, but it cannot be guaranteed to be as good as the original one. Many scenes need to be optimized in the framework. It is not feasible to construct such a scheme for the whole APP, and partial application cannot make the whole APP dynamic. Generally speaking, the benefits have not reached an absolute advantage, and the high cost and low benefits will make it difficult to promote, so we need to look forward to its continued development.
2. Primordial dynamics
Another solution is that I can give up the development mode of Web and the advantages of simple web cross-platform /UI development. I want to continue to develop this APP in the native way, but I also hope that the APP can be updated at any time, so that the program can be kept under my own control and problems can be quickly repaired. Also want to be able to update the version at any time fast iteration, ok? Absolutely. Just use the dynamic library.
The dynamic library
It’s technically much easier to be dynamic natively on iOS than it is on Android, objective-C is dynamic by nature, you can replace methods at run time, and loading dynamic libraries at run time is a very old technology, as long as I package incremental code and resources into a framework, Dynamic delivery run-time loading, bug fixing, functionality added, performance completely unimpaired, and the whole thing is over.
But? Apple has blocked the function of loading dynamic libraries. Dynamic libraries must be signed along with the installation package to be loaded, and cannot be delivered after being signed through other channels.
Why? That brings us to another apple innovation (of which there are an awful lot) : the auditing model. For a piece of software to be distributed on a platform, it has to be manually approved by that platform, and I don’t think apple has ever seen anyone else do that before. Windows is not used, MAC is not used, Unix is not used, web is not used. Apple built this thing in order to have absolute control over their platform. Review mode is in conflict with dynamic. If I have an APP that can continuously add and modify functions to the framework without review, why do I need Apple review?
Because of this limitation, it is impossible to dynamically update the APP in the most convenient way. After the whole APP is sent out, it is out of control. If there are any serious bugs or any functions that need to be added, they will submit the package to Apple for review and wait for the users to update slowly.
A detour
Apple has closed the door of the dynamic library, so we can go around and enter through another door, and the dynamic function can be added slowly. People’s demand is not so urgent, but the need to fix the bug is urgent. The crash rate of many companies’ APPS is KPI. So with waxPatch and JSPatch, the curve saves the country.
JSPatch manually translates OC to JS, and calls and replaces OC methods at run time using the dynamic nature of OC to fix bugs in real time. The need to fix bugs has been basically met. Although it takes a little detour to the next step, the cost is still very low. The engine itself is also very small and light, and the access will not have any negative impact on the APP.
JSPatch can meet the needs of bug fixing, but it still can’t meet all the needs of dynamic. The biggest disadvantage is that handwritten JS is required. Although it has the help of converter, it is not 100% accurate. Learning cost and development efficiency are not enough to add features.
Thus, didi DynamicCocoa came into being. Starting from the compilation stage, OC code was compiled into its own customized JS format through CLang, and then dynamically delivered for execution, so as to achieve native development, dynamic operation and dynamic addition. Of course, the way to fix the bug also to support. Mobile QQ also has a similar solution, but further, they compiled the OC code into their own customized bytecode dynamic delivery through Clang, and then developed a virtual machine to execute (shocked), the same implementation of native development, dynamic operation, are very NB scheme. As long as the underlying processing is good enough, it is also a low cost and high income solution, but it is not open source yet, and we have not seen the actual effect and NB source code, quite looking forward to it.
audit
Is there any problem with this scheme? The problem is that it is awkward for Apple to review. If Apple agrees to this solution, it will allow dynamic libraries to be loaded. If Apple agrees to this solution, it will allow dynamic libraries to be loaded. It is better to open the door and let everyone use dynamic libraries to do this. Dynamic libraries also disallow the use of private apis at signature time, which is not possible with scripting/bytecode delivery.
This is not quite the same as JSPatch, although I also want to promote the use of dynamic add function, JSPatch is mostly used to fix bugs due to the development experience problems. Apple also rejected JSPatch in the beginning, but later it was estimated that people only used it to fix bugs and crash. Improve the quality of the APP and acquiesce. However, DynamicCocoa and Hand Q have the goal and effect of being aligned with the loaded dynamic library from the very beginning, and it is not clear how Apple will react to the massive rollout.
I think apple’s current way of approval is quite problematic. How many apps are approved with one set and then open up some features that don’t meet the rules through some switches in the background? As long as you have an Internet connection, there are tons of ways to change the features in your APP, and Apple can’t stop it. Personally think audit mode should be changed only when released new APP audit, after the release allows dynamic distributed code update, version updates do not need to review, but through the way of reporting and spot check to audit has launched the APP, so can consider development efficiency, convenient and make better APP developers quickly iteration, also can ensure the audit result, It just wasn’t as straightforward as it is now.
The last
This is the end of the story, but one more thing that I find strange is that foreign developers are only interested in the first solution, which is to use web technology and React Native/NativeScript to do things, and are not interested in the second solution. Native hot updates are only popular in China, but not in foreign countries. Rollout hot updates are not popular in foreign countries. Why? Is it that foreign users are more rule-abiding, or that users are more tolerant of online bugs and developers are less anxious about them? Or is Android dead on the Google Play card because iOS, JSPatch and the like aren’t being promoted well? Without the support of foreign developers, it is difficult to make the system native support dynamic.
Personally, I think dynamic system support (allowing dynamic library loading) is the best in the current environment, considering both development efficiency and APP experience. Although it cannot be cross-platform, it is acceptable. Unfortunately, apple has the initiative, and developers are unable to do anything, which leads to so many forced breakthrough schemes. The Web approach may be the future, but its scope is limited at the moment, and it remains to be seen how it develops next.