WebKit

A web page doesn’t consist of an image, but of text with instructions. It states, for example, that a heading should be big and bold and that an image should sit next to it on the right. Something has to read these instructions and build a visible page out of them. That something is called a browser engine, and WebKit is one of the three major ones. Apple develops WebKit, and it powers the Safari browser on Mac, iPhone and iPad. The browser around it only supplies the address bar, tabs and bookmarks — the actual work is done by the engine.

Apple’s special path on the iPhone

WebKit is interesting because Apple long made it mandatory on the iPhone. Anyone who installed Chrome or Firefox there didn’t really get Chrome or Firefox. They got a different interface, but underneath it was still WebKit. Apple justified this with security: only this way, it argued, could it control which foreign code runs on the device.

Critics saw in this mainly a competitive advantage for Apple. They accused the company of deliberately expanding WebKit slowly. Features that would turn websites into real competitors to App Store apps arrived late or not at all. Since Apple earns money on every app sale, this is a conflict of interest. The EU’s Digital Markets Act has forced Apple, since 2024, to also allow other engines in Europe.

For developers, WebKit means extra work. A page that looks clean in Chrome can end up misaligned in Safari. Anyone building a website therefore has to test it in both engines. Some compare WebKit’s role today to that of the old Internet Explorer: an engine you have to take into account whether you want to or not.

From source code to the finished image

WebKit receives a text file from the server written in the language HTML. It contains the structure of the page: headings, paragraphs, images, links. The engine reads this text and builds from it a tree of nested elements. A paragraph, for example, sits inside a text area, which in turn sits inside the page body. This tree is the page’s internal map.

After that come the styling rules, written in the language CSS. They determine colors, font sizes and spacing. WebKit now calculates for each element how big it is and where it is positioned. This step is called layout. Only afterward are the pixels actually drawn, usually with the help of the graphics card.

A third part is JavaScript, the programming language of the web. It makes sure pages move and react to clicks. WebKit brings its own translator for this, JavaScriptCore. If a piece of code runs frequently, it translates it into faster machine code. This is why modern web applications run almost as smoothly as installed programs.

Where WebKit runs behind the scenes

You encounter WebKit most obviously in Safari. Less obviously, many apps contain a small browser view. If you open a link in Instagram or in a banking app, the page often stays inside the app. On the iPhone, this embedded view is also rendered by WebKit. The display of PDFs or help pages likewise frequently runs through it.

In news reports, WebKit usually comes up in two contexts. One is security vulnerabilities: because the engine processes foreign code from the internet, it is a popular target for attacks. Apple regularly releases emergency updates for WebKit bugs. The second context is regulation, i.e. the dispute with the EU Commission over Apple’s rules for browsers.

To put it in context, it helps to look at the competition. Blink is the engine of Google Chrome and also powers Edge and Opera. Gecko is the engine of Firefox. Blink, incidentally, once originated from WebKit — Google split it off in 2013. The two are thus distant relatives, but have since developed clearly apart from one another.