mrkeyoor.com_
Thu 24 Sept 08:48 UTC
Open Source6 min read

Search Reached 745 Stars in Four Days With a 3MB Mac Browser

Search uses Apple's WebKit to fit a Mac browser into 3MB. Its quick rise is already testing how far Chrome-extension compatibility can stretch.

MrKeyoor's tracker caught Search at 745 GitHub stars on September 24, four days after its repository was created. Those stars gathered around a Mac browser published as a 3.2MB download. It ships no Chromium bundle, account system or sync service. Search is a bet that Apple's built-in web engine can support a useful browser without turning the browser itself into a platform.

That bet met ordinary browser reality almost at once. Version 1.0 shipped on September 23. Version 1.0.1 followed less than nine hours later. It restored startup on macOS 14 and stopped iCloud Passwords from repeatedly reloading Google sign-in pages. The 1.0.1 release notes also record fixes for tab controls, private browsing and video playback. Search's fast start matters because the project makes its trade-offs unusually easy to inspect.

Office Commun made the app and released its code under the MIT license. The download is free. The release build currently targets Apple silicon and macOS 14 or later. Chrome extensions need macOS 15.4 or later because they run through WebKit's extension system. Windows and Linux are not on the roadmap for now.

The Mac already contains the heavy part

Search stays small by treating WebKit as operating-system infrastructure. Its interface is SwiftUI, with AppKit used where the window needs lower-level control, and each page runs in a WKWebView. The project's README puts the source at about 12,700 lines of Swift. Its package manifest declares one executable target and no package dependencies.

That choice of WebKit removes the largest component bundled with many desktop browsers: another web engine. It also hands rendering and process isolation to the version shipped with macOS, along with much of the work of web compatibility. Search can change its own tabs and controls quickly, but it cannot patch WebKit for every machine in the way a browser vendor shipping its own engine can. The 3MB figure therefore describes the application around the engine, not the total code required to display the web.

The same approach shapes tab recovery. Search restores a tab's title and address after launch but creates its web view only when the user opens it. A restored row of 20 tabs does not immediately create 20 active page processes, according to the architecture notes. This is a concrete use of the project's narrow scope rather than a generic speed claim. MrKeyoor inspected the source and release records, but did not independently benchmark the Mac-only binary.

Its blocker is similarly modest. The implementation compiles a short list of ad and analytics domains into a WebKit content-rule list, then adds a small set of cosmetic selectors. It runs before matching requests are made and can be disabled per site. That is useful default protection, though it is a much smaller ruleset than a dedicated blocker with maintained filter subscriptions.

Chrome extensions are where the size advantage gets expensive

The feature that separates Search from a thin WebKit demo is its attempt to install extensions directly from the Chrome Web Store. On macOS 15.4 and later, the app downloads a CRX3 package, checks that the signing key matches the requested extension ID and verifies the package signature before unpacking it. Those steps are visible in Crx.swift, rather than hidden in a closed installer.

Installation is only the first half. Chrome extensions expect browser APIs and worker behavior that WebKit does not always provide. Search injects compatibility code for session and privacy APIs, among other functions, while native Swift code answers some calls. Extension pages keep their chrome-extension:// addresses so sites recognize them. This is substantial work inside an app whose appeal begins with having very little inside it.

The gaps are already visible. Search's roadmap lists a blank Bitwarden view after sign-in, a Vimium C background that fails to start and passkey suggestions that do not yet appear beneath sign-in fields. Side-panel support and the proxy API needed by VPN extensions sit in the later queue. A browser may be able to install a Chrome extension without being able to reproduce every assumption that extension makes about Chrome.

Version 1.0.1 shows how quickly those assumptions surface. The update fixed 1Password's sign-in button, iCloud Passwords triggering repeated Google page reloads, extension panels causing page reloads and several passkey failures. The current changelog records further unreleased work on 1Password, Bitwarden and Proton Pass. Password managers are a demanding test because they touch background workers, page injection, passkeys, local storage and secure handoffs at the same time.

Local storage is a boundary you can read

Search has no user account or cloud service. The README's privacy table says passwords go into the macOS login keychain. History, bookmarks, tabs and hidden-element rules live as JSON under the user's Library folder. Cookies remain in WebKit's store. Private tabs use a separate cookie jar and are meant to leave no local record after closing. These are the maintainer's claims, but the open repository gives users and reviewers something more specific to check than a privacy slogan.

There is still network behavior beyond the pages a user opens. Search fetches site icons and checks Office Commun's update feed. The updater source limits production downloads to HTTPS, can check an optional SHA-256 value, verifies the replacement bundle and requires the signing identity to match before swapping it in for the next launch. Extensions bring their own network permissions, just as they do in other browsers. Open code makes those boundaries inspectable. It does not turn every installed extension into trusted code.

The lack of telemetry also has a cost. The project does not receive automatic crash reports, according to its contribution guide. A crash log stays on the Mac unless the user chooses to paste it into an issue. That fits the local-first design, while making bug reports and reproducible steps more important during a launch spike.

A small browser still needs a firm product line

Search's most interesting constraint may be organizational rather than technical. The contribution rules welcome patches, yet new interface features must be optional and off by default. The maintainer rejects new dependencies, analytics and any proposal to vendor another engine. Bigger requests are supposed to begin as issues so the app does not grow through duplicate or incompatible pull requests.

The line has already moved a little. Version 1.0.1 added Spaces, custom search engines, a hiding sidebar and Web Inspector support. Each addition answers a real browser need, and most stay behind settings, but they show why minimal software rarely remains frozen after users arrive. A browser that handles passwords, downloads, extensions and updates cannot stay simple merely by drawing fewer buttons. Its complexity moves into policy, compatibility work and defaults.

Developers can inspect the project without accepting the signed download. The documented build requires macOS 14, Xcode 16 and the Swift 6 toolchain:

git clone https://github.com/driceroland/Search.git
cd Search
swift build

A self-built copy is not notarized and keeps its keychain entries separate from Office Commun's signed build. That separation is an operating-system consequence of the different signatures, and it matters if someone expects saved passwords to appear in both copies. The repository also includes a shell-driven test interface that opens pages, waits for loads, extracts text, takes screenshots and clicks selectors through a Unix socket. An MCP server for that interface is on the later roadmap, not in the released product.

The next useful signal will come from the update after 1.0.1. Watch whether the listed password-manager and extension failures close without weakening the no-dependency rule, and whether the issue queue produces a repeatable compatibility list instead of one fix per popular extension. Search needed only four days to collect 745 stars. Keeping the app near 3MB while making everyday logins boring again will tell us far more about the project than the next thousand.

We reviewed this

  1. browser — our honest review
  2. swift — our honest review
  3. WebKit — our honest review

Sources

  1. Search repository and technical README
  2. Search 1.0.1 release notes
  3. Search roadmap
  4. Search changelog
  5. Search contribution guide