AppKit

Anyone writing a program for Apple's Mac computers has to deal with a lot: a window that can be moved and resized, the menu bar at the top of the screen, buttons, sliders, and text fields. Building all of this by hand every single time would be an enormous amount of work. That’s why Apple provides these building blocks ready-made, in a collection called AppKit. In programming, such a collection of reusable building blocks is called a framework. AppKit, then, is the framework from which the visible interface of Mac programs is assembled. The developer essentially says: I’d like a window with a button in it — and AppKit takes care of the rest.

Why Mac programs all feel similar

The most important effect of AppKit is consistency. A button looks the same in every Mac program because it’s the same button from the same collection everywhere. The keyboard shortcuts match up too: Command plus S saves, Command plus W closes the window. Anyone who can use one Mac program can therefore immediately operate most others as well.

For companies, this is above all a matter of time and money. A team that programs the entire interface itself needs extra months and makes mistakes that others have long since solved. AppKit also brings along things that hardly anyone thinks of on their own: support for screen readers for blind users, translation into dozens of languages, dark mode. These features appear almost automatically when you use the standard building blocks.

A common misconception: AppKit is not the same thing as macOS. The operating system is all of the software that controls the computer, including file management, networking, and storage. AppKit is only the part responsible for the visible interface of programs. It is a toolbox within the system, not the system itself.

Windows, views, and responding to clicks

AppKit consists of many pre-built components that build on one another. A window contains views, and a view can in turn contain further views. This creates a kind of nesting: a window, inside it an area with tools, inside that individual buttons. The developer assembles these pieces instead of drawing pixel by pixel.

Clicks, key presses, and mouse movements travel through a chain of possible recipients. First, the component under the mouse pointer gets the chance to respond. If it doesn’t feel responsible, it passes the event up to the surrounding element and finally to the program itself. You can picture it like a company: a request first goes to the clerk and only moves up to the manager if no one below can answer it.

Today AppKit is mostly programmed in Swift, Apple’s current programming language; previously it was mainly Objective-C. The names of many components begin with the letters NS, such as NSWindow for a window. This stands for NeXTSTEP, the operating system of the company NeXT, which Steve Jobs founded after leaving Apple. Apple bought NeXT back in 1996, and this old toolkit became the foundation of macOS.

Where AppKit still lives today

Practically every classic Mac program uses AppKit, whether directly or indirectly: the Finder, Mail, Safari, but also programs from other makers such as Photoshop or Microsoft Word in their Mac versions. When a program feels typically Mac-like, you’re generally seeing AppKit components.

It’s important to distinguish AppKit from two related names. UIKit is the counterpart for iPhone and iPad, built for fingers instead of a mouse. SwiftUI is Apple’s newer framework from 2019, meant to work across all devices at once. On the Mac, SwiftUI in many cases still relies on AppKit in the background.

In the news, AppKit mostly comes up around Apple’s developer conference WWDC, when new interface features are reported on. A recurring point of contention is the question of whether Apple will eventually abandon this now over 30-year-old framework in favor of SwiftUI. So far, Apple continues to maintain both in parallel, because too many major programs are built on it.