A desktop client that wraps a full browser engine routinely crosses nearly 450MB of resident memory before the user has clicked anything. A native companion restricted to its core views holds a baseline between 35MB and 42MB. Session telemetry indicates: across a standard eight-hour workday, people cycle between a maximum of three primary interface states. Three. Everything else in the window is decoration paid for in RAM.
That gap is the whole argument. The restraint visible in 37signals' Mac clients reads as a deliberate interface strategy with a clear thesis behind it, executed by people who understood what a companion app is for. Narrow scope, single-window layouts, and features deliberately left on the web produce a better desktop experience because they respect what the user's attention can actually hold.
The industry has spent a decade treating desktop ports as a completeness problem. Ship everything the web app does, in a frame, with a dock icon. The alternative approach treats the desktop as a different surface with different obligations, and the evidence for that position sits in the memory profiler.
Why 450MB of Chrome Wrapper Buys You Nothing
Consider what the extra 400MB purchases. It buys access to configuration screens the user opens twice a quarter. The footprint also includes a settings hierarchy that duplicates one already living in a browser tab. Finally, it pays for rendering machinery for views that, according to the usage pattern above, sit unvisited for the entire workday.
Meanwhile the cost lands on every single launch, every background hour, every context switch.
The mistake is treating feature count as the unit of value. On a Mac desktop, the unit of value is time-to-useful-state. A client that opens in under a second to the one view a person needs has already outperformed a full-scale port that took five seconds to become interactive, regardless of what else that port could theoretically do.
Footprint Reality Check
Before defending a feature in a Mac companion, check how many of the three daily interface states it appears in. If the answer is zero, its memory cost is being paid by every user, every session, for the benefit of almost none of them.
One Window, Three States: The 400x600 Discipline
Multi-pane desktop environments accumulate structure the way desks accumulate paper. A sidebar for navigation. Then a secondary sidebar for filters. An inspector on the right. A toolbar above, a status bar below, and a content area squeezed into whatever remains. Each pane arrived for a defensible reason, and collectively they produce a surface where the user's eye has no obvious destination.
Restricting an application footprint to a fixed 400x600 pixel canvas eliminates that accumulation by force. There is no room for a secondary navigation sidebar. The decision gets made by geometry rather than by a design review where everyone has a favorite pane to defend.
The constraint has precedent
Early desktop environments operated inside 512x342 pixel boundaries. That hardware limit naturally capped concurrent UI elements to fewer than five interactive targets per screen, and the software that emerged from it remains some of the most legible ever shipped on the platform. Designers of that era were not being minimalist as a style choice. The screen simply refused to hold more.
Modern displays removed the ceiling and, predictably, applications expanded to fill it. Apple's own desktop interface paradigms still emphasize clarity and deference over density, which suggests the original constraint encoded something durable about how people read a screen.
A single-window companion reintroduces that ceiling voluntarily. The result is an application where the primary action is always visible without navigation, and where the user's mental model of the app fits in one glance.
The Admin Dashboard That Never Shipped
One companion client offers an unusually clean case study in deferral. During the initial prototyping phase, the team built a native administrative dashboard containing just about 18 distinct configuration toggles. It worked. The interface looked correct. It also required an additional 12 to 14 days of QA testing per release cycle purely to verify that the native view and the server remained synchronized.
Twelve to fourteen days, every cycle, for eighteen toggles most users would touch during onboarding and then forget.
The team scrapped it. In its place went a single authenticated deep link that routes the user to the web environment, already logged in, on the correct settings page. Removing the native dashboard and its supporting machinery cut roughly 15,000 lines of synchronization logic out of the desktop codebase.
Deferral as a positive decision
Deferred features are chosen, scoped, and documented. The distinction matters because it changes how the roadmap behaves. A team that has decided administration lives on the web stops relitigating that boundary in every planning session, and stops accruing sync logic for views nobody asked for.
The division of labor follows the frequency of the task. Quick-entry actions complete locally in two to four seconds, which is exactly the interaction a desktop client exists to make frictionless. Deep configuration goes to the browser, where a full-width layout and a mature form system already handle it well.
This architecture leans on an assumption worth stating plainly: routing administrative work to the browser presumes a persistent, high-speed connection, which makes the pattern a poor fit for field deployments operating offline or on constrained bandwidth. Teams building for warehouses, vehicles, or remote sites need a different split.
Deferral Ground Rules
Write the deferral boundary into the product brief before the first native view is built. A boundary defined after the code exists becomes a negotiation; a boundary defined before it becomes architecture.
The Cost of Chasing Feature Parity
Over-featured clients fail first at the level of mental models. A user who opens a desktop app expects a desktop app: native window behavior, native shortcuts, a bounded surface. When the client instead presents every route the web application offers, the user is forced to hold two navigation hierarchies simultaneously and reconcile them. Which back button applies here? Does this sidebar mirror the web sidebar or replace it?
Each reconciliation costs a fraction of a second and a small amount of confidence. They compound.
The performance penalty is less subtle. Based on community experience, applications attempting full feature parity commonly show launch delays of 4 to 6 seconds while they initialize redundant rendering engines, spinning up a browser runtime the operating system has already loaded elsewhere. Left running in the background, these clients exhibit steady memory bloat, adding 120MB to 180MB over a 48-hour uptime period.
Users read that as the app being slow. They rarely blame the feature set, because the feature set is invisible from the outside. They blame the platform, the company, and eventually the dock icon they stop clicking.
Toolbars are where it becomes visible
Cluttered toolbars are the surface symptom of an unresolved scope question. Every deferred decision about what belongs in the desktop client eventually manifests as one more icon, sized identically to every other icon, competing for the same glance. A toolbar with fourteen items communicates less than a toolbar with three, because the three are legible and the fourteen are a texture.
Ship Less, Ship Sooner
Development teams have been apologizing for narrow companion apps for years, framing the release notes around what the client can't yet do. That framing should stop. A focused desktop client is the product decision, and it deserves to be announced as one.
The operational case is straightforward. A narrowly scoped companion ships meaningful iterations in 14 to 21 day cycles. The monolithic desktop port, carrying its parity obligations, moves in three to four month intervals. One or two dedicated engineers can maintain the focused client indefinitely; the parity build consumes a standing team that spends most of its capacity keeping two implementations in agreement with each other.
What Narrow Scope Returns
Faster release cadence, a maintenance burden measured in single engineers, and a launch profile users stop noticing. Three outcomes that a parity roadmap will not deliver at any headcount.
So here is the position worth committing to: build the Mac client around the two or three interface states people actually inhabit, put a deep link where the administration screen wanted to be, and defend that boundary in every planning meeting for the life of the product. Do those few things exceptionally, at approximately 40MB, opening instantly, and the app will earn a permanent place in the dock. An unconstrained port will earn a place in the uninstall queue by the second week.
Comments
No comments so far.
Join the Discussion