Hubbry Logo
WebKitWebKitMain
Open search
WebKit
Community hub
WebKit
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
WebKit
WebKit
WebKit
View on Wikipedia
from Wikipedia

WebKit
Original authorApple Inc.[1][2]
DevelopersApple Inc., Adobe Systems, Sony, KDE, Igalia, and others
Initial releaseNovember 4, 1998; 26 years ago (1998-11-04) (KHTML released)
June 7, 2005; 20 years ago (2005-06-07) (WebKit sourced)
Preview release
Nightly[3]
Repositorygithub.com/WebKit/WebKit
Written inC++[4]
Operating systemmacOS, iOS, Linux,[5] Microsoft Windows[6][7]
TypeBrowser engine
LicenseLGPL (rendering engine, JavaScript engine), BSD 2-Clause (additional contributions from Apple)[8]
Websitewebkit.org

WebKit is a browser engine primarily used in Apple's Safari web browser, as well as all web browsers on iOS and iPadOS. WebKit is also used by the PlayStation consoles starting with the PS3, the Tizen mobile operating systems, the Amazon Kindle e-book reader, Nintendo consoles starting with the 3DS Internet Browser, GNOME Web, and the discontinued BlackBerry Browser.

WebKit started as a fork of the KHTML and KJS libraries from KDE,[1][9] and has since been further developed by KDE contributors, Apple, Google, Nokia,[9] Bitstream, BlackBerry, Sony, Igalia, and others.[10] WebKit supports macOS, Windows, Linux, and various other Unix-like operating systems.[11] On April 3, 2013, Google announced that it had forked WebCore, a component of WebKit, to be used in future versions of Google Chrome under the name Blink.[12][13] On 12 February 2013, Opera Software announced that its Opera web browser will drop its own Presto layout engine in favor of WebKit as implemented by Google in Chromium project.

Its JavaScript engine, JavascriptCore, also powers the Bun server-side JS runtime,[14] as opposed to V8 used by Node.js, Deno, and Blink. WebKit's C++ application programming interface (API) provides a set of classes to display Web content in windows, and implements browser features such as following links when clicked by the user, managing a back-forward list, and managing a history of pages recently visited.

WebKit is open source and available under the BSD 2-Clause license[15][8] with the exception of the WebCore and JavaScriptCore components, which are available under the GNU Lesser General Public License. As of March 7, 2013, WebKit is a trademark of Apple, registered with the United States Patent and Trademark Office.[16]

Origins

[edit]

The code that would become WebKit began in 1998 as the KDE HTML (KHTML) layout engine and KDE JavaScript (KJS) engine. The WebKit project was started within Apple by Lisa Melton[17] on June 25, 2001,[18][19] as a fork of KHTML and KJS. Melton explained in an e-mail to KDE developers[1] that KHTML and KJS allowed easier development than other available technologies by virtue of being small (fewer than 140,000 lines of code), cleanly designed and standards-compliant. KHTML and KJS were ported to macOS with the help of an adapter library and renamed WebCore and JavaScriptCore.[1] JavaScriptCore was announced in an e-mail to a KDE mailing list in June 2002, alongside the first release of Apple's changes.[20]

According to Apple, some changes which called for different development tactics involved macOS-specific features that are absent in KDE's KHTML, such as Objective-C, KWQ (pronounced "quack") an implementation of the subset of Qt required to make KHTML work on macOS written in Objective C++, and macOS calls.[21]

Split development

[edit]

The exchange of code between WebCore and KHTML became increasingly difficult as the code base diverged because both projects had different approaches in coding and code sharing.[22] At one point KHTML developers said they were unlikely to accept Apple's changes and claimed the relationship between the two groups was a "bitter failure".[23] They claimed Apple submitted their changes in large patches containing multiple changes with inadequate documentation, often in relation to future additions to the codebase. Thus, these patches were difficult for the KDE developers to integrate back into KHTML.[24] Also, Apple had demanded that developers sign non-disclosure agreements before looking at Apple's source code and even then they were unable to access Apple's bug database.[25]

During the publicized "divorce" period, KDE developer Kurt Pfeifle (pipitas) posted an article claiming KHTML developers had managed to backport many (but not all) Safari improvements from WebCore to KHTML, and they always appreciated the improvements coming from Apple and still do so. The article also noted Apple had begun to contact KHTML developers about discussing how to improve the mutual relationship and ways of future cooperation.[26] In fact, the KDE project was able to incorporate some of these changes to improve KHTML's rendering speed and add features, including compliance with the Acid2 rendering test.[27]

Following the appearance of a story of the fork in the news, Apple released the source code of the WebKit fork in a public revision-control repository.[28]

The WebKit team had also reversed many Apple-specific changes in the original WebKit code base and implemented platform-specific abstraction layers to make committing the core rendering code to other platforms significantly easier.[29]

In July 2007, Ars Technica reported that the KDE team would move from KHTML to WebKit.[30] Instead, after several years of integration, KDE Development Platform version 4.5.0 was released in August 2010 with support for both WebKit and KHTML, and development of KHTML continued until 2016 before it was officially discontinued in 2023.[31][32]

Open-sourcing

[edit]

On June 7, 2005, Safari developer Dave Hyatt announced on his weblog that Apple was open-sourcing WebKit (formerly, only WebCore and JavaScriptCore were open source) and opening up access to WebKit's revision control tree and the issue tracker.[28]

In mid-December 2005, support for Scalable Vector Graphics (SVG) was merged into the standard build.[33]

WebKit's JavaScriptCore and WebCore components are available under the GNU Lesser General Public License, while the rest of WebKit is available under the BSD 2-Clause license.[8]

Further development

[edit]

Beginning in early 2007, the development team began to implement Cascading Style Sheets (CSS) extensions, including animation, transitions and both 2D and 3D transforms;[34] such extensions were released as working drafts to the World Wide Web Consortium (W3C) in 2009 for standardization.[35]

In November 2007, the project announced that it had added support for media features of the HTML5 draft specification, allowing embedded video to be natively rendered and script-controlled in WebKit.[36]

On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore as "SquirrelFish", a bytecode interpreter.[37][38] The project evolved into SquirrelFish Extreme (abbreviated SFX), announced on September 18, 2008, which compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution.[39] Initially, the only supported processor architecture for SFX was the x86, but at the end of January 2009, SFX was enabled for macOS on x86-64 as it passes all tests on that platform.[40]

WebKit2

[edit]

On April 8, 2010, a project named WebKit2 was announced to redesign WebKit. Its goal was to abstract the components that provide web rendering cleanly from their surrounding interface or application shell, creating a situation where, "web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI". This abstraction was intended to make reuse a more straightforward process for WebKit2 than for WebKit. WebKit2 had "an incompatible API change from the original WebKit", which motivated its name change.[41]

The WebKit2 targets were set to Linux, macOS, Windows, GTK, and MeeGo-Harmattan.[42][43] Safari for macOS switched to the new API with version 5.1.[44] Safari for iOS switched to WebKit2 with iOS 8.[45]

The original WebKit API has been renamed WebKitLegacy API.[46] WebKit2 API has been renamed just plain WebKit API.[47]

Use

[edit]
Usage share of web browsers according to StatCounter

WebKit is used as the rendering engine within Safari and was used by Google's Chrome web browser on Windows, macOS, and Android (before version 4.4 KitKat). Chrome used only WebCore, and included its own JavaScript engine named V8 and a multiprocess system.[48] Chrome for iOS continues to use WebKit because Apple requires that web browsers on that platform must do so.[49] Other applications on macOS and iOS make use of WebKit, such as Apple's e-mail client Mail, App Store, and the 2008 version of Microsoft's Entourage personal information manager, both of which make use of WebKit to render HTML content.

Installed base

[edit]

New web browsers have been built around WebKit such as the S60 browser[50] on Symbian mobile phones, BlackBerry Browser (ver 6.0+), Midori, Chrome browser,[51][52] the Android Web browsers before version 4.4 KitKat, and the browser used in PlayStation 3 system software from version 4.10.[53] KDE's Rekonq web browser and Plasma Workspaces also use it as the native web rendering engine. WebKit has been adopted as the rendering engine in OmniWeb, iCab and Web (formerly named Epiphany) and Sleipnir, replacing their original rendering engines. GNOME's Web supported both Gecko and WebKit for some time, but the team decided that Gecko's release cycle and future development plans would make it too cumbersome to continue supporting it.[54] webOS uses WebKit as the basis of its application runtime.[55] WebKit is used to render HTML and run JavaScript in the Adobe Integrated Runtime application platform. In Adobe Creative Suite CS5, WebKit is used to render some parts of the user interface. As of the first half of 2010, an analyst estimated the cumulative number of mobile handsets shipped with a WebKit-based browser at 350 million.[56] By mid-April 2015, WebKit browser market share was 50.3%.[57]

Ports

[edit]

The week after Hyatt announced WebKit's open-sourcing, Nokia announced that it had ported WebKit to the Symbian operating system and was developing a browser based on WebKit for mobile phones running S60. Named Web Browser for S60, it was used on Nokia, Samsung, LG, and other Symbian S60 mobile phones. Apple has also ported WebKit to iOS to run on the iPhone, iPod Touch, and iPad, where it is used to render content in the device's web browser and e-mail software.[58] The Android mobile phone platform used WebKit (and later versions its Blink fork) as the basis of its web browser[59][60][61] and the Palm Pre, announced January 2009, has an interface based on WebKit.[62] The Amazon Kindle 3 includes an experimental WebKit based browser.[63]

In June 2007, Apple announced that WebKit had been ported to Microsoft Windows as part of Safari. Although Safari for Windows was silently discontinued[64] by the company, WebKit's ports to Microsoft's operating system are still actively maintained.[65][66] The Windows port uses Apple's proprietary libraries to function and is used for iCloud[67] and iTunes[68] for Windows, whereas the "WinCairo" port is a fully open-source and redistributable port.[69][70]

GNOME Web is a web browser on Linux that uses WebKitGTK.

WebKit has also been ported to several toolkits that support multiple platforms, such as the GTK toolkit for Linux, under the name WebKitGTK which is used by Eolie,[71] GNOME Web,[72][73] Adobe Integrated Runtime, Enlightenment Foundation Libraries (EFL), and the Clutter toolkit.[74] Qt Software included a WebKit port in the Qt 4.4 release as a module called QtWebKit[75] (since superseded by Qt WebEngine, which uses Blink instead). The Iris Browser on Qt also used WebKit. The Enlightenment Foundation Libraries (EFL) port – EWebKit – was developed (by Samsung and ProFusion[76]) focusing the embedded and mobile systems, for use as stand alone browser, widgets-gadgets, rich text viewer and composer.[citation needed] The Clutter port is developed by Collabora and sponsored by Robert Bosch GmbH.

There was also a project synchronized with WebKit (sponsored by Pleyo)[77] called Origyn Web Browser, which provided a meta-port to an abstract platform with the aim of making porting to embedded or lightweight systems quicker and easier.[78] This port is used for embedded devices such as set-top boxes, PMP and it has been ported into AmigaOS,[79][80] AROS[81] and MorphOS. MorphOS version 1.7 is the first version of Origyn Web Browser (OWB) supporting HTML5 media tags.[82][83]

Web Platform for Embedded

[edit]

Web Platform for Embedded (WPE) is a WebKit port designed for embedded applications; it further improves the architecture by splitting the basic rendering functional blocks into a general-purpose routines library (libwpe), platform backends, and engine itself (called WPE WebKit). The GTK port, albeit self-contained, can be built to use these base libraries instead of its internal platform support implementation. The WPE port is currently maintained by Igalia.

Forking by Google

[edit]

On April 3, 2013, Google announced that it would produce a fork of WebKit's WebCore component, to be named Blink. Chrome's developers decided on the fork to allow greater freedom in implementing WebCore's features in the browser without causing conflicts upstream, and to allow simplifying its codebase by removing code for WebCore components unused by Chrome. In relation to Opera Software's announcement earlier in the year that it would switch to WebKit by means of the Chromium codebase, it was confirmed that the Opera web browser would also switch to Blink.[48] Following the announcement, WebKit developers began discussions on removing Chrome-specific code from the engine to streamline its codebase.[84] WebKit no longer has any Chrome specific code (e.g., buildsystem, V8 JavaScript engine hooks, platform code, etc.).[citation needed]

Components

[edit]

WebCore

[edit]

WebCore is a layout, rendering, and Document Object Model (DOM) library for HTML and Scalable Vector Graphics (SVG), developed by the WebKit project. Its full source code is licensed under the GNU Lesser General Public License (LGPL). The WebKit framework wraps WebCore and JavaScriptCore, providing an Objective-C application programming interface to the C++-based WebCore rendering engine and JavaScriptCore script engine, allowing it to be easily referenced by applications based on the Cocoa API; later versions also include a cross-platform C++ platform abstraction, and various ports provide more APIs.[citation needed]

WebKit passes the Acid2 and Acid3 tests, with pixel-perfect rendering and no timing or smoothness issues on reference hardware.[85]

JavaScriptCore

[edit]

JavaScriptCore is a framework that provides a JavaScript engine for WebKit implementations, and provides this type of scripting in other contexts within macOS.[20][86] JavaScriptCore is originally derived from KDE's JavaScript engine (KJS) library (which is part of the KDE project) and the PCRE regular expression library. Since forking from KJS and PCRE, JavaScriptCore has been improved with many new features[example needed] and greatly improved performance.[87]

On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore as "SquirrelFish",[37][38], a register-based bytecode interpreter replacing original AST-walking interpreter. The project later evolved into SquirrelFish Extreme (abbreviated SFX, marketed as Nitro), announced on September 18, 2008, further speeding up JavaScript execution by introducing Just-in-time compilation.[39]

An optimizing just-in-time (JIT) compiler named FTL was announced on May 13, 2014.[88] It uses LLVM to generate optimized machine code. "FTL" stands for "Fourth-Tier-LLVM", and unofficially for faster-than-light, alluding to its speed.[89] As of February 15, 2016, the backend of FTL JIT is replaced by "Bare Bones Backend" (or B3 for short).[90]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

WebKit

View on Grokipedia
from Grokipedia
WebKit is a cross-platform, open-source web rendering engine that displays web content, including , CSS, and , across various applications and operating systems. Originating as a of KDE's and KJS libraries in June 2001 by Apple engineers to power the browser, it has evolved into a high-performance engine emphasizing standards compliance, real-world web compatibility, reliability, and hackability. Developed primarily by Apple with contributions from companies like Google (until 2013), KDE, Igalia, and others, WebKit supports modern web technologies such as HTML5, CSS3, and Web APIs, making it integral to web development and browsing experiences. Its architecture separates the rendering engine from user interface components, allowing flexible integration into diverse software, from desktop browsers to embedded systems. On macOS and iOS, WebKit powers not only Safari but also native apps like Mail, App Store, Apple Books, and third-party applications, while on Linux it supports browsers such as GNOME Web (Epiphany) and Midori. Due to Apple's policies outside the , and with limited practical implementation in the EU under the since March 2024, iOS browsers—including versions of Chrome and —continue to predominantly use WebKit as their rendering engine, ensuring consistent performance and security but historically limiting engine diversity on the platform. Historically, WebKit influenced other major browsers: adopted it for Chrome from 2008 to 2013 before forking it into Blink, and planned to adopt WebKit in 2013 but instead switched directly to Blink. Today, WebKit continues active development, with recent releases like those in 18 incorporating features such as improved CSS Grid support, View Transitions , and enhanced privacy protections against tracking. Its open-source nature under a BSD-like license fosters community contributions and ports to platforms like Windows and Android, though adoption outside Apple ecosystems remains niche.

History

Early Development and Origins

In 2001, Apple initiated the WebKit project as a of the rendering engine and KJS JavaScript engine developed by the project, aiming to accelerate innovation in web rendering technology for a new browser tailored to macOS. The decision to fork these libraries stemmed from their compact codebases, , and relative simplicity compared to alternatives like the larger engine used in and browsers, which allowed Apple's engineers to iterate more rapidly without starting from scratch. Don Melton, a former engineer, led the effort after joining Apple on June 25, 2001, assembling a small team including Maciej Stachowiak and Darin Adler to build what would become the core of . The first code check-in to the WebKit repository occurred on August 24, 2001, marking the beginning of active development. The primary motivations for WebKit's creation were to deliver superior rendering speed and enhanced adherence to web standards, surpassing the performance and compliance limitations observed in contemporary engines such as . Early priorities included optimizing execution through enhancements to KJS, which was renamed JavaScriptCore, and bolstering support for CSS features like positioning and box models to reduce common layout discrepancies. This focus addressed pain points in existing Mac browsers, where lagged in standards support and speed. By December 2001, the team had established WebCore as the renamed and modified version of , enabling faster prototyping and testing of rendering improvements. Development proceeded under a split model, with Apple maintaining a private internal branch of the forked code to support rapid, proprietary advancements for while selectively contributing compatible patches back to the upstream project to benefit the community. This approach allowed Apple to prioritize Mac-specific optimizations without immediate public disclosure, fostering innovations like accelerated rendering pipelines. The project culminated in the release of 's first public beta on , 2003, at Macworld Expo, which quickly garnered over a million downloads and demonstrated WebKit's speed advantages through benchmarks showing up to twice the performance of competitors.

Open-Sourcing and Community Adoption

On June 7, 2005, Apple announced the release of WebKit as an open-source under a BSD license, making the full publicly available through a CVS repository and establishing the WebKit.org domain to host the . This move also included the launch of a public bug tracker using , enabling community reporting and tracking of issues. The open-sourcing prompted rapid adoption by external developers and organizations. KDE contributors, building on their prior work with the KHTML engine from which WebKit was forked, began integrating WebKit enhancements back into KHTML and contributed directly to WebKit, fostering bidirectional improvements. In 2006, released the source code for its S60 WebKit implementation for mobile devices, while KDE announced a port of WebKit to the Qt 4 framework, forming the basis of QtWebKit for cross-platform applications. Early community contributions included patches for rendering features and platform ports, expanding WebKit's reach beyond macOS. Key milestones in early adoption highlighted WebKit's growing ecosystem. The WebKit bug tracker quickly amassed reports and fixes from non-Apple developers, streamlining issue resolution. In 2007, Midori emerged as one of the first non-Apple browsers fully built on WebKit, using the GTK+ toolkit for desktops and demonstrating its viability for lightweight, independent implementations. Open-sourcing accelerated bug fixes through collective efforts, with community patches addressing cross-platform inconsistencies and enabling faster iteration on standards compliance. This led to improved feature parity across operating systems, such as enhanced support via KDE's KSVG2 engine, which was integrated into WebKit's core rendering pipeline in late 2005.

Evolution Including WebKit2

Following the open-sourcing of WebKit in 2005, the project underwent significant architectural evolution to address the increasing complexity of web applications and the need for enhanced security and stability. In April 2010, WebKit2 was announced as a major redesign, aiming to abstract the web rendering components from the surrounding application interface or shell, thereby enabling a multi-process model that isolates web content from the user interface. This shift was motivated by the limitations of the single-process architecture in handling modern web pages, which often included resource-intensive features like dynamic and multimedia, leading to potential crashes or security exposures in the main application process. The core innovation of WebKit2 was its split-process , which separated responsibilities across distinct processes to improve isolation and reliability. The UIProcess handles the application's logic and interacts with the embedder's code, while the WebProcess contains WebCore, the JavaScript engine, and all rendering, layout, and scripting activities, running in a sandboxed environment. This separation ensures that failures in , such as malicious scripts or rendering errors, do not propagate to the UI, enhancing overall stability; additionally, it facilitates better across multicore processors. Subsequent refinements introduced a dedicated NetworkProcess to manage all networking operations, including resource loading and caching, further isolating potentially vulnerable network code from both the UI and processes. WebKit2 also overhauled the APIs available to embedders, replacing the original WebKit API (later renamed WebKit1) with a new, process-aware interface designed for asynchronous operation. Key components include WKContextRef for managing browsing sessions and WKPageRef for individual web views, which use callbacks for non-blocking communication across process boundaries and allow embedders to enforce security policies, such as content restrictions. Ports like the Mac and GTK+ implementations provided language-specific bindings, such as classes and the WebKit2GTK library, enabling developers to integrate the multi-process model without managing directly. Parallel to WebKit2's development, WebKit advanced its rendering capabilities with the introduction of accelerated compositing in 2010, which maps CSS elements to GPU-accelerated layers for efficient handling of animations, transforms, and 3D effects, reducing CPU load on complex pages. These enhancements were crucial for supporting the burgeoning ecosystem of web applications, with iterative improvements in elements like WebKit2's source code became available shortly after its 2010 announcement, with initial implementations for Mac and Windows platforms. It was first integrated into production with 5.1, released on July 20, 2011, as part of Mac OS X Lion, marking a milestone in Apple's adoption of the multi-process model for its browser. Early community ports followed, including support in GNOME's Epiphany browser via WebKitGTK 2.0, released in 2013, which allowed applications to leverage WebKit2's architecture for improved performance and security in embedded web views. By 2015, WebKit2 had matured into a production-ready framework, widely used across desktop and embedded environments while maintaining through the dual-API structure.

Recent Developments (2015–2025)

In 2017, WebKit introduced Intelligent Tracking Prevention (ITP), a machine learning-based feature designed to detect and limit cross-site tracking by restricting the storage and access of and other website data associated with known trackers. This initial rollout in 11 focused on classifying domains as trackers based on user behavior across sites, preventing them from persisting data beyond a single session. By 2020, ITP had evolved through versions 2.0 to 2.3, with ITP 2.3 imposing a seven-day limit on all first- and third-party used for tracking, further blocking cross-site identifiers to enhance user without requiring manual intervention. WebKit's performance advancements during this period included the full implementation of in 2017, enabling high-performance execution of code from languages like C++ and directly in the browser, which complemented for compute-intensive tasks such as gaming and data processing. In 2022, WebKit added support for CSS container queries in Safari 16, allowing developers to style elements based on their container's size rather than the viewport, improving responsive design efficiency on diverse devices. Hardware acceleration enhancements continued iteratively, with improvements to GPU-accelerated compositing for smoother rendering of complex animations and video, culminating in the integration of APIs by 2025 for general-purpose GPU computing on the web. The 2020s saw WebKit addressing the ongoing divergence from Google's Blink engine, which had forked from WebKit in 2013 and developed distinct rendering behaviors over time, by prioritizing cross-engine compatibility through the Interop initiative launched in 2021. This collaborative effort among browser vendors, including Apple, , and , focused annually on aligning implementations of web standards; for instance, Interop 2023 targeted container queries and CSS pseudo-classes, while Interop 2025 emphasized and custom properties to reduce fragmentation and ensure consistent web experiences. Safari 18.4, released in 2025, introduced declarative web push notifications, allowing sites to deliver updates without requiring a service worker or open tab, alongside deprecations of legacy non-standard Web APIs such as certain WebKit-specific notification names to streamline the platform. In 2025, WebKit advanced native integration with through new WebPage APIs announced at WWDC, enabling developers to embed and control seamlessly within SwiftUI apps for loading pages, handling navigation, and bidirectional communication between native and web views. Security remained a priority, with patches for vulnerabilities like CVE-2025-24201, an out-of-bounds write flaw exploited in the wild, addressed in 18.3.2 and related updates via improved bounds checking. Additionally, WebKit intensified focus on , incorporating Interop 2025 priorities such as better support for attributes and enhancements in 26, ensuring more inclusive rendering for users with disabilities.

Technical Architecture

WebCore: Rendering and Layout Engine

WebCore originated as Apple's fork of the KHTML layout engine from the KDE project in 2001, incorporating an adapter layer called KWQ to integrate it with macOS frameworks while preserving the core rendering logic. Over the subsequent years, it evolved into a robust implementation handling the Document Object Model (DOM) for structured content representation, the CSS Object Model (CSSOM) for styling, and layout algorithms to compute visual geometry. This development culminated in full compliance with the Acid3 test suite in March 2008, achieving a perfect 100/100 score that validated its adherence to web standards for DOM manipulation, SVG, and JavaScript integration. The rendering pipeline in WebCore consists of several key subsystems that transform markup and styles into visual output. Style resolution begins by matching CSS rules to DOM nodes, producing a render tree of styled objects that represent visual elements. Layout follows, employing block and inline flow models to calculate positions, sizes, and overflow for render objects, ensuring content fits within constraints while respecting properties like margins and floats. Painting then rasterizes the render tree into pixel data, drawing text, images, and borders onto backing stores, often optimized for and . Finally, assembles these layers using , promoting elements to separate layers for efficient animations and scrolling without full repaints. WebCore supports a range of modern web standards to enable flexible and accessible layouts. It implemented in 2017, providing tools like display: grid, track definitions via grid-template-rows and grid-template-columns, and item placement with grid-area for complex two-dimensional arrangements. Flexbox support, aligned with the 2012 specification, arrived with Safari 6.1 in 2013, facilitating one-dimensional distribution of space among items using properties such as flex-direction, justify-content, and align-items. For accessibility, WebCore constructs an accessibility tree from the render tree post-layout, exposing semantic roles, states, and relationships to platform APIs for screen readers and other assistive technologies. It also handles , introduced in Safari 3.1 in 2008 to adapt styles based on device characteristics like screen width, and , supported since Safari 4 in 2009 for smooth transitions and keyframe sequences without JavaScript. WebCore's evolution includes integration with platform-specific graphics backends to leverage native rendering capabilities. On macOS, it utilizes Core Animation for composited layers, enabling GPU-accelerated transformations and opacity changes. For Linux-based systems, particularly in ports, it employs the Cairo library as a 2D vector graphics backend to handle drawing operations across diverse surfaces like X11 or Wayland. WebCore interacts with JavaScriptCore to process dynamic DOM modifications that may invalidate and trigger re-runs of the rendering pipeline.

JavaScriptCore: JavaScript Engine

JavaScriptCore, commonly abbreviated as JSC, serves as the JavaScript engine powering WebKit-based browsers such as . Originally forked from KDE's KJS engine in 2001 as part of the initial WebKit project, it has evolved into a high-performance implementation of standards. Development of JavaScriptCore began with basic interpretation capabilities derived from KJS, but significant advancements came in with the introduction of just-in-time () compilation. The SquirrelFish Extreme engine, announced in September , marked the first major JIT implementation, replacing the earlier interpretive approach and delivering substantial speed improvements through native code generation. By 2014, JavaScriptCore adopted a multi-tiered compilation architecture, incorporating the Low Level Interpreter (LLInt), Baseline JIT, Data Flow Graph (DFG) JIT, and (FTL) JIT, with the FTL leveraging for aggressive optimizations; this tiered system, fully operational by 2015, balances rapid startup with peak execution performance. In 2016, the B3 backend replaced LLVM in the FTL for better JIT efficiency, reducing compilation overhead while maintaining high optimization levels. At its core, JavaScriptCore features a that generates an from , followed by bytecode generation for initial execution. The tiered JIT system then progressively optimizes hot code paths: the Baseline JIT provides quick templated , the DFG JIT applies for mid-level optimizations, and the FTL JIT performs advanced speculative optimizations using intermediate representations similar to V8's , such as sea-of-nodes and global value numbering. The engine's garbage collector, which became incremental in design around 2012 and fully concurrent by the mid-2010s, employs a mark-sweep with generational separation to minimize pause times, supporting parallel marking and sweeping for better responsiveness in long-running applications. Key innovations in JavaScriptCore include comprehensive support for 2015 (ES6) and later standards, with full ES6 compliance achieved by 2017, enabling features like arrow functions, classes, and modules without performance penalties. Integration with arrived in 2017 alongside 11, allowing bytecode execution within the same sandbox as JavaScript via a dedicated validating parser and linear memory model, enhancing cross-language performance. These optimizations, including TurboFan-inspired techniques in the FTL/B3 pipeline, focus on speculative inlining and to rival V8's throughput. In benchmarks, JavaScriptCore demonstrates advantages in startup time and memory efficiency within . For instance, on 3.1 (a real-world web app simulation), achieves scores around 46.1 runs per minute on macOS as of November 2025, with Chrome at 46.6, showing competitive performance in dynamic scenarios. Compared to V8 in Blink-based browsers, JavaScriptCore exhibits 20-30% faster cold startup times due to its LLInt and Baseline tiers, and lower —often 15-25% less in serverless contexts—while maintaining competitive peak speeds in JetStream 2.2, where scores approximately 394 versus Chrome's 354 as of 2025. These traits make it particularly effective for mobile and battery-constrained environments.

Supporting Components and APIs

WebKit's networking stack, centered on the URL loading system, manages resource fetching across protocols and integrates with the Fetch API for modern asynchronous requests. The system supports , introduced in with and in 2015, enabling multiplexing and header compression to improve performance over HTTP/1.1. Support for , the transport protocol underlying , was added in 16.4 in 2023, reducing connection establishment latency and enhancing reliability on unreliable networks. The Fetch API implementation in WebKit allows to perform network requests with Promise-based handling, replacing older patterns and supporting features like streaming responses. Security in WebKit emphasizes and policy enforcement, particularly through WebKit2's multi-process architecture. Sandboxing confines web content processes, limiting access to system resources and mitigating exploits by isolating rendering and scripting from the UI process. (CSP) enforcement blocks unauthorized resource loading, such as inline scripts or cross-origin fetches, with refinements in 2016 to better handle nonce and hash-based allowances while preventing XSS attacks. Certificate handling occurs within the networking stack, validating TLS connections and supporting public key pinning for apps to restrict trusted certificates, thereby defending against man-in-the-middle attacks. Platform integrations in WebKit facilitate embedding via the Ports API, enabling developers to incorporate web views into native applications. On and macOS, WKWebView serves as the primary embedding component, providing a secure, performant way to load and interact with while leveraging the device's and process model. Media playback integrates with AVFoundation on Apple platforms, handling video and audio rendering through hardware-accelerated pipelines that support formats like HLS and spatial audio via W3C Media APIs. Stable support for , available since Safari 26 in June 2025, allows high-performance graphics and compute operations directly in , bridging web standards with native GPU access via Metal. WebKit's debugging facilities include the Web Inspector, which uses a JSON-based protocol for remote inspection, console logging, and performance profiling across processes. Unique to WebKit, it offers tabs for auditing , network traces, and layers, with wireless debugging enabled in 18.0 for devices.

Adoption and Implementations

Use in Web Browsers

WebKit serves as the core rendering engine for Apple's browser, which was first released in January 2003 as part of macOS and has since powered web browsing on macOS, , and devices. Safari's integration with Apple's ecosystem, including default status on devices, contributes significantly to WebKit's reach, with Safari holding approximately 15% of the global browser as of Q3 2025. Beyond Safari, WebKit has been adopted by various third-party browsers, both historically and in modern contexts. Early adopters include , which transitioned to WebKit starting with version 5.5 in 2006, enhancing its rendering capabilities on macOS until its decline in the 2010s. Similarly, Shiira, a discontinued open-source browser developed in for macOS, relied on WebKit to provide an alternative interface to Safari's rendering engine from its initial release in 2004. In contemporary use, (also known as Epiphany) employs the WebKitGTK port as its rendering engine, offering a lightweight, standards-focused browser for environments within the GNOME desktop. On macOS, Orion provides a privacy-oriented alternative built directly on WebKit, supporting extensions from other ecosystems while leveraging native Apple integrations. Platform-specific constraints have shaped WebKit's browser implementations. On and , App Store guidelines mandate that all web-browsing apps use the WebKit framework and its JavaScript engine, a requirement in place since the platform's early App Store era in the late ; this has resulted in many third-party browsers functioning primarily as customized "Safari wrappers" around WebKit's components. Prior to Google's 2013 fork of WebKit into Blink, Android's default browser and early versions of Chrome on Android utilized WebKit for rendering, supporting the platform's initial web experiences before the shift to Blink for greater customization. These integrations introduce challenges for web developers, as WebKit's feature implementations can diverge from those in other engines like Blink and , leading to inconsistencies in areas such as CSS vendor prefixes (e.g., -webkit-) and experimental APIs that require targeted testing for cross-browser compatibility.

Applications Beyond Browsers

WebKit has found extensive use in desktop applications for rendering web content within non-browser environments. , the default on macOS, relies on WebKit to render emails and web-based content, providing a seamless integration of web technologies into email viewing. Similarly, earlier versions of utilized WebKit's rendering engine in its Live View mode to preview web pages accurately during development. Cross-platform toolkits like QtWebKit, a of WebKit integrated with the Qt framework, enabled developers to embed web views in desktop applications on , Windows, and macOS before the shift to Blink-based alternatives. In mobile and embedded systems, WebKit powers web views within native applications, facilitating hybrid app development. On iOS, WKWebView—introduced in 2014 with —serves as the primary component for embedding web content in apps, offering improved performance and security over its predecessor, UIWebView. Older Android ports of WebKit were used in applications prior to the platform's transition to Chromium-based WebView in 2013, allowing developers to incorporate web elements into mobile apps during that era. For (IoT) devices, WebKit's lightweight nature supports resource-constrained environments, enabling web-based interfaces in smart home gadgets and sensors. A notable specialized port is the Web Platform for Embedded (WPE) WebKit, released in 2017 as an optimized variant for Linux-based embedded devices, emphasizing low memory footprint and . WPE has been adopted in automotive systems, including those compliant with the GENIVI alliance standards for in-vehicle entertainment. It also powers web rendering in smart TVs and set-top boxes, where its efficiency supports multimedia streaming and user interfaces on resource-limited hardware. WebKit's advantages in these contexts stem from its , which allows lightweight embedding without the overhead of a full browser, making it ideal for hybrid applications that blend native and . For instance, frameworks like leverage WebKit-based web views on macOS as alternatives to , enabling cross-platform desktop apps with reduced resource consumption. This embeddability, inherited from its browser heritage in , promotes rapid development of feature-rich apps while maintaining compatibility with web standards.

Usage Statistics and Market Share

WebKit maintains a significant presence in the browser engine landscape, with an estimated global market share of approximately 15% as of Q3 2025, primarily driven by its exclusive use in Apple's Safari browser on iOS and macOS platforms. On mobile devices, Safari—powered by WebKit—holds about 19% of the worldwide browser market share, reflecting the substantial iOS user base, while its desktop share is lower at around 6-8%. This positions WebKit as the second most widely used rendering engine after Blink, which dominates with over 70%. Historically, WebKit's adoption grew steadily in the , peaking at around 19-20% on desktop platforms by the mid-decade before stabilizing following the 2013 fork that led to Blink's emergence in Chromium-based browsers. Data from sources like StatCounter indicate that Safari's global share reached highs of 19-20% around 2019-2020, buoyed by growth, but has since hovered in the 13-18% range amid rising Android and Chrome dominance. Post-fork trends show WebKit's share consolidating within the rather than expanding broadly. The installed base of WebKit-enabled devices exceeds 2 billion active units worldwide, largely through the iOS ecosystem, where over 1.5 billion active iPhones contribute to its reach. Version distribution data highlights strong adoption of recent releases, with 18 and later versions powering a majority of active sessions, aligned with 18's uptake exceeding 70% by mid-2025. Regulatory developments, such as the European Union's (DMA) implemented in 2024, have prompted scrutiny of Apple's browser policies by mandating support for alternative engines in the . However, as of July 2025, no third-party browsers have implemented alternative engines on due to effective barriers, and WebKit remains the required engine for browsers in practice, limiting diversification and sustaining its market position despite these pressures.

Forks and Derivatives

In April 2013, Google announced its decision to fork the WebKit project, creating a new rendering engine named Blink to power -based browsers. The primary motivations stemmed from the growing complexity of WebKit's codebase, exacerbated by the need to support divergent architectures across projects; Google's employed a unique multi-process model for tabs and rendering that conflicted with Apple's WebKit 2 architecture, which emphasized a different approach to sandboxing and . This divergence slowed innovation for both teams, as maintaining compatibility required retaining unused code—such as over 7,000 files and 4.5 million lines in WebCore—that Google deemed unnecessary for its goals. Blink's initial focus was on streamlining the codebase by removing redundant build systems and infrastructure tailored to other WebKit ports. Blink debuted in the stable release of Google Chrome version 28 in July 2013, marking the first production use of the engine. Key technical differences from WebKit include Blink's integration of Google's V8 JavaScript engine, which replaced WebKit's default JavaScriptCore for optimized performance in dynamic web applications, and its reliance on the Skia 2D graphics library for cross-platform rendering, enabling more efficient hardware acceleration compared to WebKit's varied graphics backends like Cairo. Additionally, Blink adopted Chromium's rapid release cadence of major updates every six weeks (shortened to four weeks starting in 2021), allowing for quicker iteration on features and security fixes than WebKit's port-dependent schedules. The fork has profoundly shaped the browser landscape, with Blink now powering —holder of over 65% global browser market share as of late 2025—along with and , collectively commanding approximately 75-80% of the engine market. This dominance has led to a noticeable split in standards compliance testing outcomes; while both engines aim for web interoperability, independent development has resulted in divergences in areas like CSS layout and HTML , as evidenced by varying pass rates in web-platform-tests suites where Blink and WebKit implementations occasionally differ. Post-fork, direct code sharing between WebKit and Blink ceased after , ending the mutual bug fixes that characterized their pre-split relationship, though both projects continue to collaborate indirectly through standards bodies such as the and W3C to advance web specifications and ensure broad compatibility.

Other Notable Forks and Ports

QtWebKit emerged as a significant port of WebKit tailored for the Qt framework, initially developed by Trolltech starting in and later supported by after its 2008 acquisition of the company, with additional contributions from . This port enabled web rendering capabilities within Qt-based applications, facilitating cross-platform development for desktop and mobile environments. However, QtWebKit was deprecated in Qt 5.5 and fully removed in Qt 5.6 in 2016, as maintenance became unsustainable due to evolving web standards and resource constraints. It was succeeded by QtWebEngine, a new module based on the project's Blink engine rather than WebKit. Despite its deprecation, QtWebKit persists in some legacy Qt applications that require older web integration without upgrading to Blink-based alternatives, and community-maintained forks continue development for specific use cases. Other notable forks include platform-specific adaptations such as the WebKit integration in Nintendo's console browser, released in 2012 and built on Browser NX, which leverages WebKit for HTML5 rendering and supports features like tabbed browsing but lacks Flash. Prior to 2013, Android's default browser and WebView components relied on a customized WebKit build, handling rendering for versions up to Android 4.3, after which transitioned to Blink in Android 4.4 KitKat. Community-driven ports, such as the JSCOnly build, provide a minimal configuration for compiling just the JavaScriptCore engine with reduced dependencies, aiding developers in testing JavaScript features independently of full WebKit rendering. In modern contexts, WPE WebKit serves as an active port optimized for embedded systems since its upstream integration in 2017 by , emphasizing low resource usage, via 3D APIs, and compatibility with protocols like Wayland for devices such as smart TVs and IoT hardware. It powers web applications in environments like , where WebKit-based rendering supports execution in resource-constrained setups. Experimental and development-oriented ports continue for platforms like Windows, utilizing for graphics and supporting 64-bit builds primarily for testing WebKit features without full browser integration. Following Google's 2013 fork of WebKit into Blink, many derivative ports faced or reduced viability as development resources shifted toward the more widely adopted Blink ecosystem, leading to stalled updates in several legacy implementations. Nonetheless, WebKit remains maintained in specialized niches, including security-focused applications; for instance, Brave browser incorporates WebKit components on to comply with Apple's rendering engine requirements, while using Blink on other platforms.

Standards Compliance and Innovations

Interoperability Initiatives

WebKit has participated in the Interop initiative, an annual cross-browser collaboration launched in 2021 to enhance web platform consistency by addressing key compatibility pain points. Initially known as Compat 2021, the effort involved major vendors including Apple (representing WebKit), Google (Blink), Microsoft (EdgeHTML/Chromium), and Mozilla (Gecko), along with contributors like Bocoup and Igalia, focusing on areas such as CSS Flexbox, Grid, and sticky positioning. This evolved into Interop 2022, committing to 15 priority areas like text layout and web animations, with subsequent years building on these foundations through coordinated implementation and testing. By 2025, the initiative continued as a structured annual program, emphasizing standardized adoption to reduce developer friction in building cross-browser experiences. Interop 2025 specifically targeted 19 focus areas, including CSS nesting for more modular stylesheet organization, anchor positioning for dynamic element placement, and layout improvements encompassing features like CSS subgrid to align nested grids seamlessly across engines. Additional priorities involved API harmonization efforts, such as refining Core Web Vitals metrics and module loading behaviors, to ensure uniform performance and functionality. WebKit's involvement has driven progress in these domains, with Safari implementations aligning closely with peers to support emerging standards like the popover API and relative color syntax. A cornerstone of these efforts is WebKit's contributions to the web-platform-tests (WPT) framework, a shared repository of over 200,000 tests used to benchmark across engines. WebKit engineers have submitted tests and fixes to WPT, particularly for CSS and layout modules, helping validate compliance in real-time during Interop cycles. By the end of 2024, WebKit achieved 98% pass rates on Interop tests in 18.2, rising to 99% in the Safari Technology Preview, reflecting robust alignment with WPT standards; early 2025 results show continued gains, with cross-browser reaching 95% across Chrome, Edge, , and . These initiatives have tackled persistent challenges, including divergences between WebKit and Blink in API behaviors like permissions handling—where collaborative work on standards such as the Digital Credentials has fostered shared verification mechanisms—and media support, promoting broader adoption of versatile formats via WebCodecs to minimize playback inconsistencies. Outcomes include a markedly improved developer experience, evidenced by shared implementations of the View Transitions , which WebKit integrated in 18.0 for same-document transitions in 2024, extending to classes and types in 18.2 for reusable animation patterns across browsers. This has resulted in smoother multi-page animations and reduced need for vendor-specific workarounds, advancing a more unified web ecosystem.

Key Technical Contributions and Features

WebKit has made significant pioneering contributions to web standards compliance and graphics rendering. In 2005, WebKit became the first to fully pass the Acid2 test, a benchmark developed by the Web Standards Project to verify adherence to HTML and CSS specifications, demonstrating early leadership in rendering accuracy. This achievement highlighted WebKit's robust implementation of CSS 2.1 features, setting a precedent for other engines. Building on this, WebKit introduced experimental support for in Safari 5.1 in 2011, enabling hardware-accelerated 3D graphics in the browser without plugins, which accelerated the adoption of interactive web applications. Additionally, WebKit contributed to the Service Workers specification through active participation in W3C discussions starting in 2015, laying the groundwork for offline-capable web apps by enabling background script execution for caching and push notifications. In the realm of privacy, WebKit has introduced innovative mechanisms to combat cross-site tracking and fingerprinting. Intelligent Tracking Prevention (ITP) saw key expansions in the , including ITP 2.3 in 2020, which limited stateful tracking to one week and blocked more sophisticated trackers using on-device, and further refinements in ITP 2.4 (2021) that reduced cookie lifetimes for embedded domains. Private Click Measurement (PCM), launched in 2021, provides a privacy-preserving method for attributing ad conversions across sites and apps by encrypting click data and limiting reporting to aggregate signals, preventing individual user identification. To resist fingerprinting, WebKit implements hidden state protections, such as partitioning storage and randomizing certain responses in private browsing mode, which obscure unique browser characteristics like rendering or sensor data without impacting functionality. WebKit's performance innovations focus on efficient rendering and scripting tailored to modern hardware. For Apple Silicon devices introduced in 2020, WebKit optimized its rendering pipeline with native ARM64 compilation and Metal API integration, achieving faster page loads and lower latency in graphics-intensive tasks compared to x86 emulation. JavaScriptCore, WebKit's JS engine, incorporates energy-efficient execution through techniques like tiered compilation and idle-time garbage collection, minimizing CPU cycles and power draw during script evaluation, as evidenced by reduced energy impact in Web Inspector profiling tools. As of 2025, WebKit continues advancing web capabilities with targeted updates in 18.4 (released March 2025). New CSS features include the shape() function, enabling responsive SVG-style paths with CSS units in properties like clip-path. This release also includes 13 deprecations of older features to promote migration to modern alternatives for better security and performance.

References

  1. https://webkit.org/
  2. https://docs.webkit.org/
  3. https://developer.mozilla.org/en-US/docs/Glossary/WebKit
  4. https://webkit.org/blog/6888/celebrating-15-years-of-webkit/
  5. https://webkit.org/project/
  6. https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/
  7. https://www.osnews.com/story/26921/google-forks-webkit-unveils-blink/
  8. https://webkit.org/blog/16574/webkit-features-in-safari-18-4/
  9. https://webkit.org/blog/15865/webkit-features-in-safari-18-0/
  10. https://assets.publishing.service.gov.uk/media/61b86737e90e07043c35f5be/Appendix_F_-_Understanding_the_role_of_browser_engines.pdf
  11. https://www.apple.com/newsroom/2003/01/20Safari-Downloads-Top-1-Million/
  12. https://dot.kde.org/2003/01/08/apple-announces-new-safari-browser/
  13. https://www.cnet.com/tech/services-and-software/apple-opens-up-open-source-effort/
  14. https://dot.kde.org/2005/06/07/apple-opens-webkit-cvs-and-bug-database/
  15. https://arstechnica.com/information-technology/2007/07/the-unforking-of-kdes-khtml-and-webkit/
  16. https://www.ra.ethz.ch/CDStore/www2008/www.research.att.com/~rjana/MobEA-IV/PPT/Nokia-Open-Source-Browser-for-S60-v05.pdf
  17. https://dot.kde.org/2006/07/12/webkit-ported-qt-4/
  18. https://webkit.org/blog/5718/10-years-of-web-inspector/
  19. https://trac.webkit.org/wiki/WebKit2
  20. https://webkit.org/blog/140/html5-media-support/
  21. https://webkit.org/blog/7675/intelligent-tracking-prevention/
  22. https://www.adpushup.com/blog/safari-itp-intelligent-tracking-prevention/
  23. https://webkit.org/blog/7691/webassembly/
  24. https://webkit.org/blog/12824/news-from-wwdc-webkit-features-in-safari-16-beta/
  25. https://news.ycombinator.com/item?id=29086121
  26. https://webkit.org/blog/13706/interop-2023/
  27. https://webkit.org/blog/16458/announcing-interop-2025/
  28. https://developer.apple.com/videos/play/wwdc2025/231/
  29. https://nvd.nist.gov/vuln/detail/CVE-2025-24201
  30. https://webkit.org/blog/17541/webkit-features-for-safari-26-1/
  31. https://webkit.org/blog/114/webcore-rendering-i-the-basics/
  32. https://www.engadget.com/2008-03-27-webkit-gets-a-perfect-100-on-acid3.html
  33. https://webkit.org/blog/116/webcore-rendering-iii-layout-basics/
  34. https://webkit.org/blog/7434/css-grid-layout-a-new-layout-module-for-the-web/
  35. https://caniuse.com/flexbox
  36. https://trac.webkit.org/wiki/WebKitAccessibilityPerformance
  37. https://caniuse.com/css-mediaqueries
  38. https://caniuse.com/css-animation
  39. https://www.cairographics.org/backends/
  40. https://trac.webkit.org/wiki/QtWebKit
  41. https://webkit.org/blog/214/introducing-squirrelfish-extreme/
  42. https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
  43. https://webkit.org/docs/b3/
  44. https://webkit.org/blog/12967/understanding-gc-in-jsc-from-scratch/
  45. https://webkit.org/blog/10308/speculation-in-javascriptcore/
  46. https://webkit.org/blog/7536/jsc-loves-es6/
  47. https://developer.mozilla.org/en-US/docs/WebAssembly
  48. https://www.browserating.com/
  49. https://www.magiclasso.co/insights/best-web-browser-2025/
  50. https://smart.dhgate.com/safari-vs-chrome-in-2025-is-apples-browser-finally-better-than-googles/
  51. https://webkit.org/blog/8569/removing-legacy-spdy-protocol-support/
  52. https://caniuse.com/http3
  53. https://webkit.org/blog/7521/a-few-words-on-fetching-bytes/
  54. https://webkit.org/blog/6830/a-refined-content-security-policy/
  55. https://developer.apple.com/news/?id=g9ejcf8y
  56. https://developer.apple.com/documentation/webkit/wkwebview
  57. https://developer.apple.com/videos/play/wwdc2021/10265/
  58. https://webkit.org/web-inspector/
  59. https://gs.statcounter.com/browser-market-share
  60. https://ppc.land/chrome-reaches-66-3-market-share-as-safari-grows-to-15-1-in-q3-2025/
  61. https://www.omnigroup.com/blog/entry/OmniWeb_5.5_released
  62. https://download.cnet.com/shiira/3000-2356_4-50282.html
  63. https://kagi.com/orion/
  64. https://developer.apple.com/app-store/review/guidelines/
  65. https://developers.googleblog.com/en/blink-a-rendering-engine-for-the-chromium-project/
  66. https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Webkit_extensions
  67. https://github.com/WebKit/WebKit
  68. https://www.agitraining.com/adobe/dreamweaver/tutorials/live-view-in-dreamweaver
  69. https://xdaforums.com/t/chromium-webview-in-4-4-breaks-the-aosp-browser.2510920/
  70. https://wpewebkit.org/
  71. https://wiki.covesa.global/download/attachments/364316/GENIVI-open-source-browser-space.pdf?api=v2
  72. https://docs.digi.com/resources/documentation/digidocs/embedded/dey/3.0/cc6/yocto_c_webkit-about
  73. https://dl.acm.org/doi/fullHtml/10.5555/1388219.1388221
  74. https://www.statista.com/statistics/263517/market-share-held-by-mobile-internet-browsers-worldwide/
  75. https://backlinko.com/browser-market-share
  76. https://www.plusqa.com/post/top-web-browsers-for-testing-in-2025
  77. https://indulge.digital/blog/behind-browsers-rendering-engines-power-your-web-experience
  78. https://gs.statcounter.com/browser-market-share/all/worldwide/2019
  79. https://gs.statcounter.com/browser-market-share/all/worldwide/2020
  80. https://www.demandsage.com/browser-market-share/
  81. https://www.macrumors.com/2025/01/30/apple-active-devices-worldwide-record/
  82. https://backlinko.com/iphone-users
  83. https://telemetrydeck.com/survey/apple/iOS/majorSystemVersions/
  84. https://techcrunch.com/2025/01/24/ios-18-hits-68-adoption-across-iphones-per-new-apple-figures/
  85. https://appleinsider.com/articles/25/07/14/apple-still-effectively-blocks-rival-browser-engines-on-ios-despite-eu-order
  86. https://techcrunch.com/2024/01/26/apple-dma-webkit/
  87. https://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html
  88. https://arstechnica.com/information-technology/2013/04/google-going-its-own-way-forking-webkit-rendering-engine/
  89. https://www.cnet.com/tech/services-and-software/google-parts-ways-with-apple-over-webkit-launches-blink/
  90. https://www.cnet.com/tech/services-and-software/blink-googles-new-chrome-browser-engine-comes-to-life/
  91. https://developer.chrome.com/docs/web-platform/blink
  92. https://www.chromium.org/developers/release-process/
  93. https://www.chromium.org/blink/developer-faq/
  94. https://liquidat.wordpress.com/2008/05/27/arora-a-webkit-browser-in-qt/
  95. https://wiki.qt.io/Qt_version_history
  96. https://www.qt.io/blog/2013/09/12/introducing-the-qt-webengine
  97. https://wkhtmltopdf.org/status.html
  98. https://github.com/qtwebkit/qtwebkit
  99. https://wiiubrew.org/wiki/Internet_Browser
  100. http://www.nintendoworldreport.com/news/31760/wii-u-browser-has-tabbed-browsing-screenshots-html5-but-no-flash
  101. https://docs.webkit.org/Ports/Introduction.html
  102. https://trac.webkit.org/wiki/JSCOnly
  103. https://wpewebkit.org/about/faq.html
  104. https://www.igalia.com/project/wpe
  105. https://download.tizen.org/misc/media/conference2013/slides/TDC2013-Webkit_for_Tizen.pdf
  106. https://docs.webkit.org/Ports/WindowsPort.html
  107. https://www.reddit.com/r/brave_browser/comments/1kgrudw/what_are_the_main_limitations_of_webkit_being/
  108. https://web.dev/blog/compat2021
  109. https://webkit.org/blog/12288/working-together-on-interop-2022/
  110. https://hacks.mozilla.org/2022/03/interop-2022/
  111. https://web.dev/blog/interop-2025
  112. https://webkit.org/blog/16413/the-success-of-interop-2024/
  113. https://webkit.org/blog/16301/webkit-features-in-safari-18-2/
  114. https://developer.chrome.com/blog/view-transitions-update-io24
  115. https://www.w3.org/TR/2015/WD-service-workers-20150625/
  116. https://webkit.org/tracking-prevention/
  117. https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/
  118. https://trac.webkit.org/wiki/Fingerprinting
  119. https://webkit.org/blog/8970/how-web-content-can-affect-power-usage/
  120. https://developer.apple.com/documentation/safari-release-notes/safari-18_4-release-notes
Add your contribution
Related Hubs
User Avatar
No comments yet.