Rebuilding Chromium's Windowing for the Arc Browser Sidebar

This article explores the architectural modifications The Browser Company made to the open-source Chromium engine to create the Arc browser's signature vertical sidebar. By stripping away Chromium's default C++ user interface layer and replacing it with a native Swift framework, the engineering team decoupled tab management from web rendering, enabling features like Spaces, Split View, and single-window multi-profile switching.

Bypassing the Chromium Views Framework

In a standard Chromium browser, the entire application window—including the frame, horizontal tab strip, address bar, and viewport—is managed by a cross-platform C++ layout engine called Views.

To build Arc’s vertical sidebar, The Browser Company chose not to modify this existing C++ UI framework. Instead, they bypassed it almost entirely. They treated Chromium not as a complete application, but as a headless rendering and networking library. Arc takes ownership of the top-level operating system window using native platform toolkits (AppKit and SwiftUI on macOS, and WinUI on Windows) and embeds Chromium’s rendering viewports directly into their custom-built native window hierarchy.

Building the Swift-to-C++ Bridge

Because Chromium is written in C++ and Arc’s windowing architecture is written in Swift, the engineering team had to build a massive interoperability layer.

Whenever a user interacts with the vertical sidebar—such as clicking a tab, dragging a folder, or triggering the command bar—those events are handled natively in Swift. The custom bridging layer translates these Swift actions into C++ commands that Chromium can understand, instructing the underlying engine when to navigate, halt network requests, or free up memory. Conversely, when a webpage changes its title, favicon, or audio-playing state, the bridge passes those C++ notifications back up to the Swift layer to update the sidebar UI.

Abstracting the TabStripModel

Chromium’s native windowing architecture relies on a class called TabStripModel, which assumes tabs exist in a flat, linear, horizontal array tied to a specific window. Arc’s vertical sidebar fundamentally breaks this assumption by introducing three distinct tab states within the same view: Favorites (persistent apps), Pinned Tabs (persistent bookmarks per Space), and Today Tabs (ephemeral tabs).

To achieve this, The Browser Company abstracted tab state management away from Chromium’s TabStripModel. Arc maintains its own source-of-truth data model in the native UI layer. Chromium is only used to manage the WebContents (the actual rendered webpage). This decoupling allows Arc to unload a tab's WebContents to save memory while keeping the tab visually present in the sidebar, or move tabs seamlessly between different organizational hierarchies without triggering Chromium's native tab-detachment logic.

Reparenting WebContents for Split View and Peek

Standard Chromium windows are architected to display a single active WebContents view at a time. When you switch tabs in Chrome, the window swaps out one WebContents view for another.

Arc’s workflow relies heavily on viewing multiple web pages at once via Split View, or previewing links in a modal overlay using a feature called Peek. To make this work, The Browser Company modified how WebContents views are hosted. Instead of binding a single viewport to the window frame, Arc’s window manager acts as a flexible compositor. It can instantiate multiple active Chromium RenderWidgetHostView objects simultaneously, placing them side-by-side for Split View or layering them on top of one another for Peek, while handling focus states and keyboard routing independently of Chromium's default window controller.

Breaking the One-Profile-Per-Window Rule

One of the deepest architectural changes made for the Arc sidebar is how it handles Chromium Profile objects. In standard Chromium, a Browser window instance is strictly bound to a single Profile. If a user wants to separate their work cookies and history from their personal ones, Chromium forces them to open two entirely separate operating system windows.

Arc’s sidebar allows users to swipe between different "Spaces" within the exact same window, and each Space can be linked to a completely different Chromium Profile. To accomplish this, The Browser Company decoupled the OS window from the Chromium Browser object. A single Arc window can simultaneously host multiple hidden Chromium Browser instances in the background—each tied to a different profile. When a user swipes to a new Space in the sidebar, Arc’s windowing layer instantly swaps the active rendering viewports on the screen, creating the illusion of a single unified browser window that effortlessly spans multiple isolated Chromium profiles.