Haiku's Kit-Based API: Application, Interface, Storage, and Media Kits

Haiku’s native API — inherited conceptually from BeOS — is organized into Kits: separately scoped, purpose-specific groups of C++ classes, each owning one concern of application development. Rather than one large, general-purpose framework, a Haiku application is built by combining exactly the Kits it actually needs.

The major Kits, and what each one owns

Application Kit   — BApplication, BLooper, BHandler, BMessage:
                    the message-passing foundation every app is built on
Interface Kit     — BWindow, BView, BButton, and the rest of the
                    GUI widget set
Storage Kit       — BFile, BDirectory, BEntry, BQuery: file access,
                    attributes, and BFS queries as first-class objects
Media Kit         — real-time audio/video capture, processing,
                    and playback (see the dedicated deep-dive)
Support Kit       — general-purpose utility classes (BString,
                    BList, BLocker) used throughout the other Kits

Each Kit is a coherent, independently comprehensible unit — the Storage Kit’s classes only concern themselves with files, directories, and BFS queries; the Interface Kit’s classes only concern themselves with drawing and receiving input. A developer building a simple command-line tool that needs BFS attribute queries can use the Storage Kit’s BQuery directly without pulling in the Interface Kit’s GUI machinery at all.

Why this differs from either a single framework or a pile of unrelated libraries

A single, undifferentiated framework tends to blur unrelated concerns together as it grows — GUI code, file I/O, and networking code often end up more entangled than necessary simply because they live in the same namespace and get developed by the same team over time. A pile of genuinely unrelated third-party libraries, at the opposite extreme, forces a developer to evaluate, integrate, and keep updated several separately-versioned dependencies with inconsistent conventions. The Kit structure sits deliberately between these: one coherent, first-party API, but explicitly partitioned along the same lines a well-organized application’s own internal architecture would naturally follow.

The Application Kit’s role as the connective tissue

Every other Kit assumes the Looper/Handler messaging pattern the Application Kit defines — an Interface Kit BView is a BHandler; a BWindow is a BLooper. This isn’t incidental: the Kit boundaries reflect domains of responsibility (drawing vs. storage vs. media), not a break in the underlying architectural model, which stays consistent across every Kit precisely because they’re all designed together as parts of one coherent system rather than integrated after the fact.

Naming conventions as a form of documentation

Every class across every Kit follows the same B-prefixed naming convention (BWindow, BFile, BMessage) — a small detail, but one that makes it immediately obvious in any piece of Haiku source code which types are part of the native API versus application-specific or third-party code, without needing namespace qualification to tell them apart.

Why this structure has held up since BeOS

The Kit boundaries defined in the 1990s for BeOS have carried forward into Haiku essentially unchanged in spirit — new capability gets added within existing Kits or as genuinely new Kits, rather than requiring the existing structure to be reorganized. That stability is itself evidence the original partitioning was drawn along real, durable boundaries in what an application actually needs to do, rather than an arbitrary organizational scheme that happened to be convenient at the time.