What Slowy Was

A tool built for a problem no development machine could simulate on its own

A developer in a well-connected office has a structural problem. The machine they write code on sits on a fast, stable LAN, and the software they ship will run on connections that are slow, intermittent, and unforgiving. The gap between those two environments used to be invisible until a user reported something broken — a spinner that never cleared, a request that hung silently, a retry loop that hammered a server rather than backing off. Slowy was a small macOS utility designed to close that gap by making the developer's own connection behave badly on purpose.

The core idea is not complicated. A network link has several independently adjustable properties: how much data it can carry per second, how long each packet takes to cross it, how often a packet disappears entirely, and how much that delay varies from one packet to the next. A real broadband connection mixes all four in proportions that shift with time of day, distance to the exchange, and what a neighbour happens to be streaming. A development machine on a gigabit LAN exhibits almost none of that texture. Slowy introduced the texture artificially — reducing throughput to something resembling a mobile connection, injecting added latency, adding packet loss at a configurable rate — so the application under development had to cope with the same conditions its eventual users would face.

What distinguished Slowy from simply throttling a Wi-Fi router was its reach and its granularity. It worked at the network-interface level on the Mac itself, which meant it caught all outbound traffic from that machine without requiring any change to the network infrastructure around it. That placement also meant it could be toggled and adjusted without touching a router's configuration page, which made the development feedback loop considerably tighter. A developer could reproduce a support report — "loads forever on 3G" — in seconds rather than reconfiguring hardware.

The machinery underneath, and why the problem is harder than it looks

What Slowy actually manipulated was the kernel's packet-scheduling layer. On macOS, that layer is built on top of dummynet, the traffic-control facility originally written by Luigi Rizzo in Pisa, Italy, and published in the late 1990s. Dummynet handles the queuing, the rate limiting, and the delay injection that a tool like Slowy needs; the utility's job was to provide a front end simple enough that a developer who had never read a traffic-control paper could drag a slider and get a result. The mechanism behind the slider — a token bucket that meters packets into the interface at a fixed rate, a simulated delay pipe that holds packets for a specified duration before releasing them — remained invisible to the user. That invisibility was the point.

The relevance of queue behaviour to perceived application performance is not obvious until you watch it carefully. A congested queue on a slow link is where bufferbloat lives: the buffer fills because the link cannot drain it fast enough, packets sit waiting, and latency rises well beyond what the nominal rate limit would suggest. Slowy did not implement active queue management — it did not drop packets early to signal congestion the way CoDel, developed by Kathleen Nichols and Van Jacobson, does — but for most developer testing purposes it did not need to. Replicating the subjective experience of a bad connection, rather than its precise engineering, was enough to make application faults visible.

The timing of the tool's existence matters. Slowy arrived during the period when mobile web traffic was growing fast enough that developers could no longer assume a user was sitting at a desktop on a cable modem. The iPhone had made real HTTP traffic over cellular networks a normal condition rather than an edge case, and the variance in those networks — high latency, asymmetric capacity, sudden jitter — was genuinely alien to anyone whose test environment was a MacBook on office Wi-Fi. Apple itself acknowledged this class of problem by building the Network Link Conditioner into Xcode's Additional Tools, which did roughly what Slowy did through a preference-pane interface rather than a standalone application. The existence of a first-party option from Apple in the same space is part of why Slowy's own niche narrowed.

What it did that other tools did not, and where it stopped

Slowy's design chose breadth of reach over depth of control. It shaped all traffic through an interface rather than intercepting individual flows at the application layer, which meant anything the machine sent — background sync, telemetry, the application itself — passed through the same conditions. That is either exactly what you want, if you are testing how the whole device behaves under constraint, or a limitation, if you want to degrade only one application while leaving the rest of the system unaffected. A proxy-based approach, routing one application's traffic through an intermediary that applies its own shaping, can achieve that selectivity; Slowy could not.

The tool also could not reach traffic it did not generate. A shaper sitting on a developer's Mac has no visibility into a remote server's send behaviour, the congestion state of intermediate routers, or the fairness between flows that a real access network enforces. The internet's congestion control — the slow-start and additive-increase algorithms that Van Jacobson described in his landmark 1988 paper and that remain the foundation of TCP behaviour — operates between endpoints, not within a single machine's shaping layer. Slowy could simulate a slow pipe; it could not simulate the full dynamic of a network under load, where competing flows negotiate bandwidth in real time.

That limitation is structural, not a failure of ambition. Any shaper running on a single machine faces it. The published literature on active queue management — work that came out of Lawrence Berkeley National Laboratory, later taken up by the Bufferbloat.net community and standardised through the Internet Engineering Task Force — addresses the problem at the network level, where routers can observe and respond to the behaviour of many concurrent flows. A developer tool shapes one machine's view of one link.

Slowy is no longer available. The Mac utility that once occupied that niche is gone, and the space it held has been divided between Apple's own Network Link Conditioner, the kernel-level dummynet interface that remains accessible directly, and proxy tools that intercept at the application layer. None of these is Slowy. Each works at a different layer, catches a different slice of traffic, and requires a different kind of knowledge to operate. What Slowy offered was a simple front end to a real mechanism, aimed at the developer who needed to see the problem rather than understand the plumbing.

The problem it addressed has not gone away. A development environment that is faster and more reliable than production will always produce software with blind spots. The tool that exposed those blind spots on a Mac, simply and without ceremony, is the thing this site is named for.