For most developers, version compatibility is a matter of low presence, because it is a one-line configuration in most cases, with the help of some front-end tool chains (such as Babel, CoreJS, Autoprefixer, etc.) Adapt to the target browser, and only pay attention to this inconspicuous thing under some big break change events (for example, Vue3 must be run under modern browsers that support Proxy).
But when you do a little research, you will find that the content knowledge is very complicated, because the knowledge about version compatibility does not have so much internal logic, and many small knowledge points are scattered in the games and version changes of various commercial companies. . Some time ago, due to work needs, I focused on some language/browser features, and made a record of this article.
This article mainly records the version adaptation problem of the mobile terminal, and does not do more research on the desktop terminal, and may supplement relevant content later.
1.iOS & Safari
Although both iOS and Android update a major version every year, benefiting from the closed nature of the ecology, the update rate of iOS is extremely high . Basically, the latest two versions can cover more than 95% of the population.
For example, according to Apple’s official statistics [1], as of 2022-05-31, among the new models launched by Apple within four years, iOS 15 89% and 10% of the new models have been installed iOS 14 ; and among all historical models, iOS 15 and iOS 14 There is also a 96% installation rate, and the Android next door is crying with envy:
Why so much focus on iOS version numbers? Because the iOS version is basically in one-to-one correspondence with the Safari version , for example, iOS 15.6 installed on the above Safari 15.6, iOS 14.5 installed on the above Safari 14.1, the specific mapping relationship can be found in the mapping table of MDN [2], or you can see core-js: SafariToIOS [3], so we basically Just compare the iOS version number on the Internet.
Another problem is that developers with certain C-side development experience may also pay attention to whether UIWebView or WKWebView is running on iOS. In fact, there is no need to pay attention at this point in 2022, because the Apple Store has already issued an announcement[4] , After December 2020, apps containing UIWebView have been prohibited from being put on the shelves, so the iOS platform only has the WebView of WKWebView, and its compatibility is also good [5], with minimum support iOS 8.
2.Android & Chrome
After talking about iOS, let's talk about Android. Because the development strategies of the two operating systems are different, coupled with the magic changes of major domestic manufacturers, Android has been deeply fragmented from the very beginning. Students with Android development experience must be deeply touched.
The Android system itself is fragmented, and the browser that comes with the Android system is even more fragmented . In the early days of Android, there was a binding relationship between the Android version and the Chrome browser version, so how early is this early? That is Android 4, it was released in 2014 and was bound to several earlier versions of Chrome. Because there is not much data, I will list it directly here:
// https://github.com/zloirock/core-js/blob/master/packages/core-js-compat/src/mapping.mjs
ChromeToAndroid: [
[9, '3.0'],
[12, '4.0'],
[30, '4.4'],
[33, '4.4.3'],
]
Things turned around when Android 5WebView was transplanted into an independent APK in this version [6], which can be updated independently and is no longer deeply bound to the Android system.
Google's original intention is good. With the help of the Google store, decoupling is more conducive to the iteration of browser versions. However, in the domestic multi-manufacturer magic reform and some network problems, it is very likely that such a thing will happen: for a mobile Android 5 phone, users can theoretically install Chrome 36 - Chrome 95 any version !
Therefore, compared with iOS, Android has serious fragmentation problems because of its openness: there are various versions of Android, various versions of Chrome, and various modified kernels. It is really miserable for developers to adapt.
3.Web Browser
After understanding the version history of the operating system, let's look at the most critical JavaScript syntax compatibility on the browser.
JavaScript
In the last ten years, the biggest change in the JS language is the release of ES6 (ES2015), which brings a lot of new features. Below I have made a table, listing the versions of several commonly used JS grammars that are supported:
| Syntax/API | iOS | Chrome |
|---|---|---|
Class |
9 | 49 |
=> |
10 | 45 |
const |
11 | 49 |
let |
11 | 49 |
Proxy |
10 | 49 |
generators |
10 | 39 |
Promise |
8 | 33 |
async await |
11 | 55 |
import export |
10.3 | 61 |
| ... | ... | ... |
We can see that the minimum supported versions of these grammars are concentrated on iOS 10, iOS 11, Chrome 49, Chrome 61 and we list their release times:
| event | release time |
|---|---|
ES5 standard release time |
2009.12 |
ES6 standard release time |
2015.06 |
iOS 10 release time |
2016.06 |
iOS 11 release time |
2017.06 |
Chrome 49 release time |
2016.03 |
Chrome 61 release time |
2017.09 |
After the time is listed, the conclusion is basically ready to come out: In the next year after the release of the ES6 standard, all major browsers will support almost all syntaxes, and basically all of them will be supported two years later . This time point is 2017. Corresponding to iOS 11 and Chrome 61 .
legacy vs modern
After reading the support of ES6, let's understand two concepts, "classic browser" and "modern browser".
These two words correspond to "legacy browser" and "modern browser" in English. If you pay more attention to some relatively cutting-edge front-end projects, such as Vue3, Solidjs, and Vite, these two words are often mentioned on their official websites.
So here comes the problem, since there are two titles, there must be a dividing line in the project to distinguish legacy and modern. This dividing line is iOS10.3 and Chrome 61, that is, the browser supports the version of ES Modules (supports <script type="module"> & import & export).
Does this match the content above? The Babel official website has also made relevant explanations [7], and core-js has also made a special distinction [8]. For a more detailed introduction, you can read the MDN article: JavaScript modules [9], I will not make redundant introductions.
modern feature
After the above exploration, let's go back and look at the support level of some modern browser features:
| invoice browser | iOS | Chrome |
|---|---|---|
| Web Worker | 5 | 4 |
| SubtleCrypto | 7 | 37 |
| Service Worker | 11.3 | 45 |
| WebAssembly | 11 | 57 |
| CSS Grid Layout | 10.3 | 58 |
| WebGPU | not support | not support |
| ... | ... | ... |
Look at the compatibility of each API, combined with the above content, you can find that many people say that "compatibility is not good". That level of complexity requires the use of these advanced features .
4.Open Source Project
In daily development, you must not write a line of code to check the compatibility. These are all smoothed out by community tools.
The source of compatibility data can be traced back to MDN's browser-compat-data[10], which records the compatibility of various APIs. The compatibility of the MDN website is directly read from this repo. Our commonly used caniuse[11] website, part of the data also depends on it.
Next is browserslist[12], which is most relied on in engineering. Construction tools such as babel, eslint, autoprefixer, postcss, and webpack all depend on it. The data of browserslist also depends on caniuse-lite[13], which actually also depends on caniuse[14] ], lite only retains the core data, and cuts some explanatory texts.
Based on the above analysis, we can see that the data accuracy of the browserslist relied on in the project project can still be guaranteed, so there is no need to worry about compatibility.
5.Adaptation Suggestions
Having said all that, any configuration suggestions? Personally, I think there are three main suggestions for reference.
The first one is to refer to the minimum support configuration of the national-level APP .
In China, what can be called a national-level app on Daily Live is WeChat Douyin. Because of the huge size of Daily Live, these two apps have basically covered all Chinese people, so their configuration must be considered, which can reflect the domestic situation. The overall mobile phone version level.
From the App Store/Android App Store/Browser UA, we can draw the following conclusions (as of 2022-8-8):
-
WeChat : The minimum supported to
iOS 12,Android 5, built-in browser version isChrome 86 -
Douyin : The minimum supported version is
iOS 10,Android 5, and the built-in browser version isChrome 75
Of course, you can also refer to other apps, and I won’t expand too much due to limited energy.
According to the iterative speed of the project, iOS can basically be upgraded once a year. For example, iOS 16 after it comes out this year, the minimum adaptation version can basically be upgraded next year iOS 11 . It should still be supported Android 5.
The second suggestion is to directly look at the version data of the current business .
Different companies and different projects have different user scenarios. For example, for third- and fourth-tier C-end users, generally there will be more low-end phones; for store-oriented scenarios, IE browser may have to be adapted; Developer projects within the enterprise can be directly adapted to the latest browsers.
With so many scenarios, it depends on user version data statistics. Generally, large and medium-sized factories have a relatively complete data monitoring platform, and you can get the general situation by directly pulling a piece of data. Small companies with incomplete infrastructure can also open a separate interface to record data, and collect it for a month to make deduplication statistics. get relevant data. After getting the data and making some trade -offs based on the business scenario , you can basically get the minimum adaptation.
The third suggestion is to combine the front-end framework and Chrome version for compatibility.
Combining the front-end framework is actually very easy to understand. For example, if you use Vue3 and the bottom layer depends on Proxy, then the minimum dependency has been locked to and iOS 10 , Chrome 49 then your minimum configuration can only be higher than the above version. If you have no brains set to iOS 9 or Android 4, In addition to not being able to run on the lowest version, there are many syntax conversions and polyfills for no reason, which will cause unnecessary degradation in build speed/runtime performance/product volume .
Compatible with Chrome version is actually the content of the second section of this article. Because Android 5 it will no longer be deeply bound to Chrome in the future, it is meaningless to set the Android version for version compatibility. You should directly set the Chrome version according to the statistical results and make more fine-grained configurations.