• Progress Delayed Is Progress Denied
  • 译 文 : Infrequently Noted
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Reviewer:

Will App Store policy hurt developers? Is the Internet a reliable alternative? Take a look at the data

Update (June 16, 2021) :Developers who are trying to make mobile web games tell me,Fullscreen APIStill not applicableNon-video elements on iOS. This is definitely an easy way to get in the way of web games and immersive media experiences on iOS devices. Speaking of Apple leaving developers limping on iOS, recall that this article initially praised Apple for finally releasing a working implementation of IndexedDBAs if it were too early, there was a Bug with IndexedDB.

Before we start, three facts…

  1. Apple prohibits developers from uploading web apps to the only app store on iOS.[1]
  2. Apple forces browser owners to use Apple’s engine in all browsers on iOS, limiting them from offering better versions of the web platform.
  3. Apple claims that the browser on iOS is a platform that will help developers who oppose the terms of the App Store.

And a proposal:

Apple’s iOS browser (Safari) and engine (WebKit) are underpowered. The constant delay in delivering important features ensures that the web can never be a reliable substitute for its proprietary tools and App Store.

It’s a bold claim, and it takes overwhelming evidence to prove it. This article mined public data on compatibility fixes and speed of feature additions to assess how we could complain to Apple!

Steve and Tim’s “No” magic

Apple’s (misleading) propaganda often undermines the discussion around the browser, the role of the web, and App Store policy on iOS. Classic statements include:

  1. Apple is all about performance!

  2. … This feature appears in the technical preview.

  3. Apple is trying, and they just added long-awaited features.

These points are both valid and serve as a valid alternative to native application development on iOS without really having anything to do with Web suitability.

To understand the gap Apple has created and maintained between Web and native, we should look at trends rather than individual releases. Just like to know if we’re in a drought (a climate), we have to check reservoir levels and seasonal rainfall. Maybe [it’s raining] at this moment, but the weather is not the weather.

Before we start measuring water levels, I want to make a few things unbearably clear.

First of all, the following is not a criticism of the Safari team or individuals in the WebKit project, but rather an offer of help to Apple to help them do their job adequately [2]. They are one of the best engine developers in the world and really want to bring good things to the web. Apple is at fault, not the open source engineers or the managers who support them.

Second, it is natural and healthy to have browser projects with different priorities at the forefront. The same goes for quick resolution and agreement. What’s not healthy is that the engine is years behind, and even worse is that it can’t be fixed by browser choice. Assuming that the “compatible core” of functionality continues to expand at a steady rate, it’s good for teams to take the lead in different areas. We should not expect unity in the short term – it does not leave any room for leadership [3].

Finally, while this article does measure Safari’s lag, don’t mistake it for the core issue: the iOS App Store policy that prevents meaningful browser competition is the issue here.

Safari trails rival MacOS browsers by roughly the same margin, but it’s not a crisis because choosing a real browser offers a meaningful alternative.

Safari for MacOS is actually compelling enough on its own to hold a 40-50% share for years amid intense competition. Safari has a lot of nice features, and in an open market, it makes perfect sense.

The performance parameters

As an engineer on the browser team, I’ve been learning about how various performance projects, benchmarking exercises, and performance marketing affect project priorities.

All modern browsers run fast, including Chromium and Safari/WebKit, but no browser is always the fastest. As reliable as the sun rising in the east, the new benchmark kick-started the project of reconstructing the interior to take the lead, as it should.

Healthy competition is characterized by competitors regularly taking the lead. False reports of performance “10 times worse” are highly suspect.

After 20 years of neck and neck competition, often starting with common code pedigrees, there’s not much left to wring out of the system. Continuous improvement is the theme of the game, and it can still have a positive impact, especially as users become more and more dependent on computers over time.

All browsers are deeply involved in the optimization process, leading to complex trade-offs. Things that improve one type of device or application can bring them back to other types. Significant revenue now tends to come from (subtly) terminating developers’ contracts in the hope that users don’t notice. There is not much difference between engines in the focus on performance engineering.

Frequent transitions between small gaps and leads mean that differences in ability and correctness are not the result of one team focusing on performance while others pursue different goals [4].

Finally, the choice to fund feature and correctness work is not mutually exclusive with improving performance. Many of the delay features in the list below will make web apps run faster on iOS. Internal rearchitecting often results in performance benefits as well as improved correctness.

Compatibility cost

Web developers are passionate people; We don’t give up the first time we find bugs or incompatibilities between engines. The abyss of knowledge and practice centers on the question: “How do we provide a good experience for everyone, even though their browsers support different content?”

Adaptation is a way of life for skilled front end personnel.

The cultural value of adaptation has a huge impact. First, Web developers don’t see a single browser as their development goal. Education, tools, and training all support the premise that more and better browsers are supported (other things being equal), creating a huge incentive to grease the creaking wheels. Narrowing the gap between the leading and the laggard browsers is therefore a focus of the Web development community. Spend a lot of time and effort developing workarounds for lag engines (preferably with low running costs) [5]. In cases where workarounds fail, cutting functionality and UI fidelity is considered the right thing to do.

Cross-engine compatibility is key to developer productivity. If an engine has (or roughly has) more than 10% of the market, developers tend to view its lack of features as “not ready.” Therefore, it is possible to deny Web developers access to these features on a global scale because they cannot be delivered.

An important, lagging engine can make the entire network less competitive in this way.

To judge the impact of iOS on this dimension, we can try to answer a few questions:

  1. How far does Safari lag behind the two competing engines in correctness?
  2. How often does Safari lead when it implements basic features? How often do you fall behind?

Thanks to the Web Platform Test Project and Wpt.fyi, we were able to answer the first question:

Tests that fail only in a given browser. The lower the better.

The yellow Safari line roughly measures how often other browsers are compatible, but Safari’s implementation is wrong. Conversely, the much lower Chrome and Firefox rows indicate that Blink and Gecko are more likely to agree and be correct on core web standards [6].

Wpt.fyi’s new Compat 2021 dashboard Narrows this full testing range down to a subset of choices that represent the most painful compatibility errors:

Stable channel Compat 2021 results over time. The higher the better.

Recent improvements can be seen in WebKit. Sadly, these features will take about a quarter to reach users, as Apple has tied WebKit features to the slow pace of OS releases.

In almost every area, low-quality implementations of Apple’s support for functionality on WebKit require workarounds. Developers need in Firefox (Gecko) or Chrome/Edge/Brave/Samsung (Blink) in the Internet to find and fix the problem. This increases the cost of developing for iOS.

Aggregated view

The Web Confluence Metrics project provides another way to understand this problem.

This dataset is derived by traversing the javascripts exposed Feature tree of the Web platform, an important subset of features. Data can be further traced to provide a more complete trend line for engine integrity.

Engines add features at different rates, and the Confluence chart illustrates the absolute scale of the differences and the speed at which versions add new features. The data is hard to compare between these charts, so I extracted it to generate one chart at a time:

Blue: Chrome, red: Firefox, yellow: Safari Web ConfluenceThe number of apis provided from JavaScript. The higher the better.

According to Web Platform Tests data, Chromium and Firefox have implemented more features and brought them to market more consistently. From this data we can see that iOS is the most incomplete and competitive implementation of the Web platform, and the gap is getting wider. At the last Confluence run, the gap had widened to nearly 1,000 apis, doubling since 2016.

Perhaps computing apis create a distorted view?

Minor additions (such as CSS’s new typed object model) may result in large extensions to the API surface. Similarly, some transformative apis, such as accessing webcams or Media Sessions via getUserMedia(), may just add methods and properties.

To see if the intuition formed by the Web Confluence data is on the right track, we need to take a deeper look at the history of feature development and relate the apis to the types of applications they enable.

A major impact

Browser release notes and caniuse tables have captured the arrival of features in each engine for a longer time than WPT or Confluence datasets since Blink became independent from WebKit in 2013 [7]. This record gives us a deeper understanding of how individual features and groups of features unlock new types of applications.

Browsers sometimes launch new features at the same time (for example, CSS Grid and ES6). More often, there is a lag between the first and the rest. In order to provide a considerable “grace period” and to account for short-term differences in engine priorities, we focused on features of three years or more [8].

What follows is an attempt to put a full tally of the features introduced in this era. A summary of each API and the impact of its absence accompany each project.

Where Chrome falls behind

It is healthy for engines to have different priorities, causing each browser to avoid certain features. Chrome has missed out on several apis for over 3 years:

Storage Access API

Introduced in Safari three years ago, this anti-trace API was not specified, resulting in significant differences in API behavior across implementations. The poor quality of Apple’s initial version of Smart Tracking Prevention created an even worse tracking vector (later fixed) [9].

On the positive side, this has sparked a broader conversation around online privacy, which has led to many new, more explicit proposals and models for proposals.

CSS Snappoints

It’s much smoother and easier to build image rotations and other touch-based UIs with this feature. Disagreements within the Blink team about the correct order to deliver this and the Animation Worklets led to regrettable delays.

CSS Initial Letter

Advanced typography features planned in Blink after the LayoutNG project is completed.

position:sticky

Make it easier to build “fixed” elements in scroll-based UIs. The original implementation was removed from Blink post-fork and re-implemented several years later on a new infrastructure.

CSS color()

Wide gamut colors are important in creative applications. Chrome does not support CSS at this point, but is being developed for Canvas and WebGL.

JPEG 2000

Licensing issues led Chrome to switch to WebP.

HEVC/H.265

Many modern chips support next-generation video codecs, but they are also licensing minefields. An open, royalty-free codec AV1 has been delivered.

Where iOS falls behind

Some of the features in this list are enabled in Safari, but not enabled for other browsers forced to use WebKit on iOS (e.g. Service Workers, getUserMedia). In these cases, only delivery delays in Safari are considered.

getUserMedia()

Providing access to webcams is essential to building a competitive video experience, including messaging and video conferencing.

These categories of apps took five years to appear on the iOS Web.

WebRTC

Real-time network protocol for enabling video conferencing, desktop sharing, and game streaming applications.

Five years of delay.

Gamepad API

Support for game streaming PWA (Stadia, GeForce NOW, Luna, xCloud) is NOW available on iOS.

Five years of delay.

Audio working set

Audio Worklet is the fundamental enabler of rich media and games on the web. Combined with WebGL2/WebGPU and WASM threads (see below), Audio Worklets can free up more of the computing power available on devices to produce consistently good sound without fear of failure.

After years of standards-based discussions and first shipping to other platforms in 2018, iOS 14.5 finally released Audio Worklets this week.

IndexedDB

Safari is a veritable example of tardy and low-quality in the minds of Web developers. IndexedDB is a modern alternative to the traditional WebSQL API. It provides developers with a way to store complex data locally.

After an initial two-year delay, the first version of the feature was severely unusable on iOS, and indie developers started maintaining a list of display errors.

If Apple had released a working version in either of its first two attempts, IndexedDB will not be available three years later – iOS 10 finally provides a working version – and the lag is four years and five years, compared to Chrome and Firefox, respectively.

Pointerlock

The key to playing games with the mouse. Still doesn’t work with iOS or iPadOS.

Media Recorder

Fundamentally supports video authoring applications. Without it, video recording must be logged into memory, causing a crash.

This is Chrome’s most anticipated developer feature ever (in star rating). It was delayed by iOS for five years.

Pointer to the event

A unified API for handling user input, such as mouse movements and screen clicks, is important for adapting content to mobile devices, especially with regard to multi-touch gestures.

It was originally proposed by Microsoft and delayed by Apple for three years [10].

Service Worker

Support for modern, reliable offline Web experiences and key APIS for PWA.

There was a three-year delay (Chrome 40, November 2014 vs. Safari 11.1, April 2018, but it wasn’t available until several versions later).

WebM and VP8 / VP9

Royalty-free codecs and containers; Competitive compression and features free alternatives to H.264/H.265. The lack of support forces developers to spend time and money transcoding and servicing multiple formats in addition to multiple bit rates.

They only support use in WebRTC and do not support the usual methods used for media playback (

CSS type object model

High-performance interface for styling elements. Other “Houdini” features are enabled, such as the base of THE CSS custom drawing feature.

Not available for iOS.

CSS Containment

Enabling consistently high performance features in the rendering UI, as well as new features, can significantly improve the performance of large pages and applications.

Not available for iOS.

CSS Movement path

Enable complex animations without JavaScript.

Not available for iOS.

Media Source API (aka “MSE”)

MSE enables the MPEG-DASH video streaming protocol. Apple provides an implementation of HLS, but prohibits alternatives.

IPadOS only.

element.animate()

Browser support for the full Web Animations API has been patchy, with Chromium, Firefox, and Safari all completing support for the full specification last year.

Element.animate () is a subset of the full API that makes it easier for developers to create high-performance visual effects in Chrome and Firefox since 2014 with less risk of visual lag.

EventTargetThe constructor

It may seem trivial, but it’s basic. It allows developers to integrate with the browser’s internal messaging mechanisms.

It’s been delayed for nearly three years on iOS.

Web performance API

IOS has never been able to provide a modern API to measure Web performance over three years or more. Delayed or missing features are not limited to:

  • navigator.sendBeacon()
  • Paint Timing (delay two to four years)
  • User timing
  • Resource timing
  • Performance observer

The impact of the lack of a Web performance API is largely a matter of scale: the larger the site or service one tries to offer on the Web, the more important the metrics become.

fetch() 和 Streams

Modern asynchronous networking apis that significantly improve performance in some cases.

Two to four years, depending on how you count.

Not every feature blocked or delayed on iOS is transformative, and this list ignores cases in the bubble (e.g., BigInt’s 2.5 year lag). In summary, even for less controversial apis, Apple’s delays make it difficult for enterprises to treat the Web as a serious development platform.

The price

Let’s assume Apple implements the WebRTC and Gamepad apis in time. Who can say that the revolution in game streaming that’s happening right now happened earlier? Amazon Luna, NVIDIA GeForce NOW, Google Stadia and Microsoft xCloud could have been built years earlier.

It’s also possible that apis available on all other platforms but not yet available on any iOS browser (because of Apple) could unlock entire categories of experiences on the web.

While there are dozens of Apple features that are or are expected to be delayed for years, a few big ones deserve special mention:

WebGL2

WebGL2, the first of two modern 3D graphics apis currently held by Apple, significantly improves 3D visual fidelity for applications on the Web, including games. [OpenGL ES 3.0] (developer.apple.com/library/arc…). The bottom of the graphic function [since 20103 available in iOS] (developer.apple.com/library/arc… WebGL 2 is available on Chrome and Firefox for other platforms in 2017. Although WebGL2 is being developed in WebKit, the expected end-to-end latency for these features is approaching five years.

WebGPU

WebGPU is the successor to WebGL and WebGL2, improving graphics performance through better alignment with the next generation of low-level graphics apis (Vulkan, Direct3D 12, and Metal).

WebGPU will also unlock richer GPU computing for the web, accelerating machine learning and media applications. WebGPU is likely to ship in Chrome by late 2021. Although the standards body has been delayed for years at the behest of Apple engineers, the timeline for webGpus on iOS is unclear. Keen observers expect at least a few years of additional delays.

WASM thread 和 Shared array buffer

All browsers now support Web Assembly (” WASM “), but iOS lacks extensions for “threading” (the ability to use multiple processor cores together).

Threading support enables richer, smoother 3D experiences, games, AR/VR applications, creative tools, simulations, and scientific computing. The history of this feature is complicated, but to make a long story short, they are now available for opt-in sites (on every platform except iOS). To make matters worse, iOS has no plans for this project, and there is little hope that they will come out soon.

Combined with the latency of Audio Worklets, modern graphics apis, and Offscreen Canvas, many compelling reasons to own an iOS device are no longer available on the web. [11]

WebXR

Now being developed in WebKit after years of silence, the WebXR API provides augmented reality and virtual reality inputs and scene information to Web applications. Combined with advanced (delayed) graphics apis and threading support, WebXR enables immersive, low-friction commerce and entertainment over the web.

More and more of these features have been supported in leading browsers on other platforms over the years. Apple has no timeline for when Web developers will be able to offer the same experience to iOS users in any browser.

These omissions mean that Web developers can’t compete with native apps on iOS in categories like games, shopping and creative tools.

Developers expect some lag between introducing native features and corresponding browser apis. Apple’s policy against browser engine choice adds years of delay beyond the (expected) delays of design iterations, specification writing, and browser functionality development.

These delays prevent developers from reaching wealthy users with rich web experiences. This gap is created exclusively by Apple’s policies, which almost force businesses off the web and into the App Store, where Apple prevents developers from reaching users through the web experience.

Just out of reach

One might imagine that the five-year delay for 3D, media, and gaming could be the most serious impact of Apple’s policy of preventing browser engine advances. That would be wrong.

The next layer of missing functionality is relatively uncontroversial proposals from the standards body that Apple participates in, or has enough support from Web developers to be “effortless.” Each enables higher quality web applications. Not expected on iOS anytime soon:

Scroll TImelineFor CSS and Web animation

Likely to be released in Chromium later this year, it will support smooth animations based on scrolling and swiping, a key interaction mode on modern mobile devices.

Apple did not say if or when the feature would be available to Web developers on iOS.

content-visibility

CSS extensions that significantly improve rendering performance, suitable for large pages and complex applications.

WASM SIMD

Next month, Chrome supports WASM SIMD to enable high performance vector math and significantly improve performance, suitable for many media, ML and 3D applications.

The Web components associated with forms

Reduce data loss in Web forms and make components easily reusable across projects and sites.

CSS Custom drawing

Effectively enabling new styles of drawing content on the web eliminates many difficult trade-offs between visual richness, accessibility, and performance.

Trusted type

A standard version of the method is shown in Google web applications to significantly improve security.

CSS Container Query

From Web developers and expected later this year in Chrome’s top request, CSS container queries enable content to better adapt to different device form factors.

<dialog>

Built-in mechanisms for common UI patterns for improved performance and consistency.

inertattribute

Improve focus management and accessibility.

Browser-assisted lazy loading

Reduce data usage and improve page loading performance.

Few of these features are basic (for example, SIMD). However, even content that can be emulated in other ways still imposes costs on developers and iOS users to bridge the gap in Apple’s Web platform implementation. This cost can be slow in the user experience on other platforms without being careful as well [12].

What could it be

Beyond these relatively uncontroversial (MIA) features is the possibility of foreclosure. Such a feature would support a whole new category of Web applications if Apple were willing to allow competition from the kind of honest ios-specific browsers that MacOS users love. Maybe that’s the problem.

Apple is blocking some key features that any browser offers to iOS (and all other operating systems), in no particular order:

Push notification

In a stunning display of anti-netgatekeeping, Apple has implemented neither a long-standard Web Push API nor its own for iOS, as well as a completely proprietary MacOS Safari Push notification system

The challenges posed by the lack of push notifications on modern mobile platforms cannot be overstated. Developers across categories report a lack of push notifications as a killer, including:

  • Chat, messaging, and social applications (for obvious reasons)
  • E-commerce (shopping cart alerts, shipping updates, etc.)
  • Press Release (Breaking News Alert)
  • Travel (itinerary updates and at-a-glance information)
  • Cycling sharing and Delivery (Status updates)

This omission has put sand in the network’s water tank — which is good for Apple’s native platform, which has enjoyed push notification support for 12 years.

PWA installation tips

Back on iOS, Apple was the first to release version 1.0 that supported installing certain Web apps onto the device’s home screen, but support for those features has barely improved since 2007.

Apple later added the ability to facilitate native app installs, but did not provide an equivalent “install tips” tool for Web apps.

Meanwhile, browsers on other platforms have developed environmental (browser-provided) promotions and programmatic mechanisms to guide users in saving commonly used Web content to their devices.

Apple maintains this functional gap between native and Web (despite explicit underlying support for this mechanism) and is reluctant to allow other iOS browsers to improve the situation [13], combined with the App Store’s policy of preventing content from being placed on the Web, Great emphasis is placed on discovering content built using Apple’s proprietary apis.

PWA application icon tag

Provides support for “unread message counting”, for example for E-mail and chat programs. Does not apply to Web apps that are added to the iOS home screen.

Media session API

Enables web applications to play media in the background. It also allows developers to insert (and configure) system controls for back/forward/play/pause/etc. And provide track metadata (title, album, cover).

The absence of this feature prevents an entire category of media apps (podcasts and music apps like Spotify) from making sense.

In development, but if it launches this fall (the earliest window), the Web media application will be delayed for more than five years.

Navigation preloading

Can be used with Service Workers to significantly improve page loading performance on sites that provide an offline experience.

Several top 10 web properties reported to Apple that the lack of this feature prevented them from deploying more flexible versions of the experience (including building PWA on iOS) for their users.

Off-screen canvas

Improve the fluency of 3D and media applications by moving rendering work to a separate thread. For delay-sensitive use cases such as XR and games, this feature is necessary to consistently provide a competitive experience.

TextEncoderStream & TextDecoderStream

These TransformStream types help applications efficiently process large amounts of binary data. They may have been released in iOS 14.5 but the release instructions are vague.

requestVideoFrameCallback()

Helps media applications on the network save battery power during video processing.

The compression stream

Allows developers to compress data efficiently without having to download a lot of code to the browser.

Keyboard lock API

An important part of a remote desktop application and some game flow scenarios connected to a keyboard (not uncommon for iPadOS users).

Declarative shadow DOM

A complement to the Web Components system, which supports apps such as YouTube and Apple Music. The declarative Shadow DOM can improve loading performance and help developers provide UI loading for users when scripts are disabled or cannot be loaded.

Reporting API

It is essential to improve the quality of your site and avoid the damage caused by browser obsolescence. Newer versions also let developers know when their applications are crashing, helping them diagnose and fix broken sites.

Access API

Help developers present better, more contextual options and prompts to reduce user annoyance and “prompt spam”.

Wake up the screen

Prevents screen darkening or screen saver taking over. This is important for applications that provide boarding passes and QR codes for scanning, as well as presentation applications such as PowerPoint or Google Slides.

Intersection Observer V2

Reduce AD fraud and enable a one-click registration process to increase business conversion rates.

The content index

An extension for Service Workers that enables the browser to render cached content to the user while offline.

AV1/AVIF

Modern, cost-free video codecs are almost universally supported outside Safari.

PWA application shortcut

Allows developers to configure “long press” or “right click” options for Web applications installed to the home screen or Dock.

Shared Workers 和 Radio channel

Coordination apis allow applications to save memory and processing power (although most commonly in desktop and tablet form factor).

getInstalledRelatedApps()

Helps developers avoid prompting users to enter permissions that might duplicate existing applications on the system. This is especially important for avoiding duplicate push notifications.

Background synchronization

A tool for reliably sending data, such as chat and E-mail messages, when the network connection is intermittent.

Background the fetch API

Allows applications to efficiently upload and download bulk media through progress indicators and controls. This is important for reliably synchronizing music or video playlists for offline or synchronizing photos/media for sharing.

Periodic Background Synchronization

Helps applications ensure that they have fresh content displayed offline in a battery – and bandwidth-sensitive manner.

Network Sharing goals

Allow installed web applications to receive share requests through the system user interface, enabling chat and social media applications to help users publish content more easily.

The list of basic apis missing for media, social, e-commerce, 3D applications, and games is surprising. Basic apps in the App Store’s most popular categories cannot be tried on the web on iOS due to the feature gap created and perpetuated by Apple.

Device apis: The final frontier

Browser makers are strongly against it, but the area where Chromium-based browsers (Chrome, Edge, Samsung Internet, Opera, UC, etc.) are making headway is access to hardware devices. While not essential for most “traditional” web applications, these features are the foundation of vibrant categories such as education and creative music apps. IOS Safari does not currently support these apps, while Chromium browsers on other operating systems can enable these apps on the web:

The bluetooth network

Allows low-power Bluetooth devices to securely communicate with Web applications without downloading heavyweight applications to configure individual IoT devices.

Web MIDI

Enable creative music applications on the web, including synthesizers, mixing kits, drum machines and music recording.

Web USB

Provides secure access to USB devices from the Web, enabling new categories of applications in the browser, from education to software development and debugging.

Network serial

Supports connections to older devices. This is particularly important in industrial, Internet of Things, healthcare, and education scenarios.

Web Serial, Web Bluetooth, and Web USB enable educational programming tools to help students learn to program physical devices, including LEGO.

Indie developer Henrik Jorteg elaborated on the frustration of not being able to access these features on iOS and demonstrated their approach to low-cost development. The lack of Web apis on iOS isn’t just frustrating for developers. It drives up the price of goods and services and reduces the number of organisations that can provide those services.

Web HID

Enabling secure connections to input devices is not traditionally supported as a keyboard, mouse, or gamepad.

The apis provide secure access to proprietary functionality on niche hardware through standard protocols they already support, without the need for proprietary software or insecure native binary downloads.

Web NFC

Let network applications securely read and write NFC labels, for example for click-to-pay applications.

Shape detection

The Unlocks platform and operating system provide high-performance recognition of text in bar codes, faces, images, and videos.

Important in video conferencing, business, and IoT setup scenarios.

Generic Sensor API

A unified API for accessing sensor standards in mobile phones, including gyroscopes, proximity sensors, device orientation, acceleration sensors, gravity sensors, and ambient light detectors.

Each entry in this endless list can prevent an entire category of applications from being credibly possible on the network. The real-world impact is hard to measure. Weighing deadweight losses seems like a good Angle for economists to study. Startups don’t try, services aren’t built, and businesses are forced to develop native apps multiple times at higher prices, perhaps estimable.

Not harmonious

The data consistently confirms that Apple’s Web engine lags behind other engines in terms of compatibility and functionality, leading to a huge and persistent gap with Apple’s native platforms.

Apple wants us to accept:

  • It makes sense to force iOS browsers to use their Web engine, keeping iOS at the back.
  • For developers unhappy with App Store policies, the Web is a viable alternative on iOS.

One of them might be reasonable. Or two? Well…

Parties interested in the health of the digital ecosystem should ignore Apple’s claims and focus on the varying rates of progress.

Full disclosure: I’ve been working on Chromium at Google for the past 12 years, across the pre-fork era, discussing the potential features of Chrome and Safari in the WebKit project, as wellPost-ForkEra. During this time, I led several projects to add functionality to the network, some of which were opposed by Safari engineers.

Today, I leadProject Fugu”, which is a collaboration project within Chromium that is directly responsible for most of the above device apis. Microsoft, Intel, Google, Samsung and others are contributing to this effort and are doing it openly, hoping to standardize, but I have a great interest in its success. My front-row seat allows me to state unequivocally that independent software developers are clamoring for these apis, but are being ignored when they ask Apple for support. I am personally frustrated that these improvements are not available to developers (all developers) who want to reach iOS users. My interests and biases were obvious.

Previously, I helped lead the development of Service Workers, push notifications, and PWA, overcoming frequent and sharp objections from Apple engineers and managers. The design of Service Workers grew out of a collaboration between Google, Mozilla, Samsung, Facebook, Microsoft, and independent developers to create better, more reliable Web applications. Apple joined the group only after other Web engines delivered their work. For iOS users and developers interested in serving them well, the availability delays of Service Workers (and highly demanding follow-on features such as navigation preloading) also impose an undeniable personal memory burden.

  1. IOS is unique in that it does not allow the web to participate in its unique app store. MacOS’s built-in App Store has similar anti-web terminology, but MacOS allows multiple App stores (e.g. Steam and Epic Store), as well as true browser choice.

    Android and Windows include support for Web apps directly in their default stores, allowing for multiple stores and facilitating true browser choice. ↩ ︎

  2. Since the Safari and WebKit teams are not adequately staffed, we must insist that Apple change its iOS policy to allow competitors to safely fill the void created by Apple’s own shallow choices. ↩ ︎

  3. To claim that I (or other Chromium contributors) would be happy to see engine homogeneity is completely wrong.

  4. Some reviewers seem to be confusing the differences between software and hardware. For example, the area where Apple has definitely killed it is CPU design. The resulting Speedometer score difference between flagship Android and iOS devices speaks to Apple’s commanding lead in mobile cpus.

The A-series chips have been running around other ARM components for more than five years, mostly by gobsmacking the number of L2/L3 caches per kernel. Apple’s restrictions on iOS browser engine choices make it difficult to demonstrate software parity. Safari doesn’t work on Android, and Apple doesn’t allow Chromium on iOS.

Thankfully, the advent of the M1 Mac made it possible to eliminate hardware differences from comparisons. For more than a decade, Apple has been making trade-offs and unique decisions about cache hierarchies, branch prediction, instruction sets, and GPU design. Competing browser makers are only now beginning to explore these differences and adapt their engines to take full advantage of them.

As this process progressed, the results were consistent with Intel: Chromium was about as fast as WebKit, and in many cases much faster.

As always, the lesson of performance analysis is that you must always double-check to ensure that you are actually measuring what you are hoping to achieve.

  1. A decade ago, backend browsers were mostly installed pieces that couldn’t (or wouldn’t) upgrade. The relentless march of self-renewal has largely removed this barrier. The remaining set of significant browser differences in 2021 is the result of a combination of the following factors:

    • Market-specific differences in browser update rates; For example, emerging markets have an additional delay of several months between a browser release date and a full replacement
    • Fewer and fewer enterprise scenarios where legacy browsers persist (IE11, for example)
    • Differences in functional support between engines

    As other influences fade away, the last one emerges. Automatic updates didn’t work as well as expected when alternatives to previous versions lacked the features developers needed. Despite the high rate of OS updates, iOS sabotaged the entire web by projecting the flaws of WebKit’s lead onto every browser on every iOS device.

  2. It may go without saying, but Firefox/Gecko’s tendency to implement higher-quality features than Safari/WebKit is a big black eye for Apple.

    An open source project without ~ $200 billion in the bank is doing what the world’s most valuable computing company wouldn’t: investing in browser quality and offering a more compatible engine than Apple ** across more operating systems and platforms **.

    That should be enough for Apple to allow Mozilla to release Gecko on iOS. For its tax on Web developers around the world, their failure to do so is even more untenable.

  3. Data /) captured by the MDN browser compatibility database and caniuse database are often incomplete and sometimes incorrect.

    Where I realized they were inaccurate — usually related to the version with the first feature — or where they disagreed, I have consulted the original sources (browser release notes, contemporaneous blogs) to build the most accurate delay graphs.

    No consideration has been given to the existence of features behind “developer preview”, beta branches, or flags that users must manually flip. This is reasonable based on some obvious concerns: developers can’t count on the feature not being fully released to have any potential impact on the market:

    • Some features exist behind these flags for years (for example, WebGL2 in Safari).
    • Features that are not yet available on the release branch may still change their API shape, meaning developers will face expensive code changes and retests to support them in this state.
    • Browser vendors generally discourage users from manually enabling experimental flags

  4. Due to a lag cutoff of more than 3 years, rival engines are ahead of WebKit on many features not included in this list.

    The data shows that it doesn’t matter which time frame you focus on, since some features are landing ahead and behind. The ratio of leading/lagging features in WebKit has remained relatively stable. One reason for leaving out the shorter time frame was to reduce the impact of Apple’s lackluster feature release schedule.

Even if Apple’s Tech Preview and Edge (www.microsoftedgeinsider.com/en- / us/welcome), Chrome or Firefox Beta version, Because of Apple’s uniquely slow way of introducing new features, they can be delayed in reaching users (and therefore available to developers). Unlike the lead engine, which delivers improvements every six weeks, the speed at which new features are rolled out in Safari is tied to the pace of Apple’s twice-yearly iOS point-to-point releases. Before 2015, the lag was typically as severe as a full year. Referring only to features with long delays helps eliminate the benefits to WebKit of such a release tempo mismatch effect.

The omission of a gap of less than three years is very generous in Cupertino’s case.

  1. One effect of Apple’s imposition of a Web engine monoculture is that, unlike on other platforms, the same issues that affect WebKit also affect all other browsers on iOS.

    When security issues in WebKit expose the entire operating system to problems that can only be fixed at the rate of application OS updates, developers not only suffer from undesirable uniform quality issues, but also have a negative impact on users.

  2. Apple’s three-year delay in implementing Pointer Events for iOS is also due to the licensing drama Apple has created within the W3C regarding standardization of various event models for touchscreen inputs.

  3. During the drafting of this article, iOS 14.5 and Safari 14.1 were released.

In good faith, Apple initially declined to provide release notes for Web platform features in the update.

In the days that followed, the late documentation contained a shocking revelation: to everyone’s surprise, iOS 14.5 had brought WASM threads! The wait is over! The WASM threads in iOS were completely unexpected, as WebKit needed to turn off distance to add true site isolation or new developer opt-in mechanisms to protect sensitive content from the side-channel attacks of modern cpus. This year, WebKit doesn’t seem to make it.

Understandably, the Web Assembly community was excited and started testing the declaration, but it didn’t seem to be able to make the feature work as expected.

Shortly after, Apple updated its documentation and provided details of what was actually added. The infrastructure that will ultimately be critical to the WASM threading solution in WebKit is already available, but it’s a bit like an engine on a test shelf: without the rest of the car, it’s beautiful engineering and won’t get people where they want to go.

IOS WASM threads are already seeing their shadow and expect to wait at least six months. At least we’ll have an overburdened CPU core to keep us warm.

  1. It’s counterintuitive that users and developers around the world are paying taxes for Apple’s underfunding of Safari/WebKit development, effectively subsidizing the richest company in the world.

  2. Safari installs Web applications onto the home screen using proprietary apis not available in other iOS browsers.

Users switching browsers on iOS today, by contrast, are less likely to make the web a more important part of their computing lives, and the inability of other browsers to offer Web app installation presents a challenge for developers who must consider the gap and recommend that users switch to Safari to install their web experience.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.