Native by design: why Droppy is a small, fast Mac app, Droppy blog

Droppy is written in Swift and SwiftUI. On its own that is a dull sentence, so let me translate it into things you can feel. The app you download is small. It opens the instant you click it. It sits at the top of your screen from login to shutdown without ever showing up as a problem in Activity Monitor. None of that is luck. It follows from the app being native, built with the same tools Apple uses to build the Mac, rather than a web page dressed up to look like one.

I know that framing can sound like a fight between programmers, and it usually is one. So I want to keep this concrete and fair. Native has real costs. Web technology has real strengths, and for plenty of software it is the correct choice. But an app that lives in your notch all day is close to the worst place to hide a whole browser engine, and I want to walk through why, including the parts where the other side is right.

What native actually buys you

Native is not a badge to wear, it is a set of specific savings. A native Mac app carries almost nothing of its own. It leans on frameworks that already ship inside macOS, so the download stays small and the copy on your disk stays small. It starts quickly because there is no engine to boot before your code runs, only the system that is already running. And because it speaks the machine's own language, it is light on memory and easy on the battery, which matters for something that never quits.

The clearest place to see the gap is memory. A web-wrapped app brings its own copy of an entire browser engine, the same machinery that renders a full website, loaded into memory every time it opens. One app built that way can hold hundreds of megabytes just to draw a small window. A native utility doing the identical job holds a fraction of that, because the drawing is handled by code already resident in the system.

Both bars stand for the same job: holding a small window open while you do something else. The native utility borrows frameworks already in macOS, so it stays short. The web-wrapped app carries its own browser engine and pays for it in memory every time it runs. Real figures vary between apps and machines, so treat the lengths as illustrative. With Reduce Motion on, the bars hold still.

The reach that only native has

Size and launch speed are the easy half of the argument. The half I care about more is that some of what Droppy does is not reachable from inside a web page at all, at any price.

Droppy's glass is real system material, sampled live from whatever sits behind it. Its notch integration talks to the display at a level a browser is never handed the keys to. The system HUDs it can replace, the volume and brightness overlays, come from private corners of macOS that only native code can call. And when it moves, it goes through the system's own animation tools, which is why it can honor Reduce Motion the moment you turn it on, a discipline I wrote about in how Droppy animates. A web wrapper can imitate a little of this from the outside. It cannot plug into the machine the way native code does.

Native code can reach parts of macOS a web page never sees: the live glass material, the notch, the system volume and brightness HUDs, and accessibility settings like Reduce Motion. A web-wrapped app runs inside its own bundled browser, which keeps it portable, but also keeps it walled off from most of the machine.

Tap an approach

Built with the frameworks already inside macOS, so it travels light.

Memory: borrows drawing code from the system, so it holds a fraction of the load.
Launch: no engine to boot first, so it opens the instant you click.
Battery: speaks the machine's own language, so it stays easy on power all day.

Portable and quick to build, but it carries a whole browser engine wherever it runs.

Memory: bundles its own engine, so a small window can hold hundreds of megabytes.
Launch: boots that engine before it appears, so it arrives later.
Battery: heavier to keep running, though one codebase can ship to every platform.

The same job, two ways to pay for it. Real figures vary between apps and machines.

Where the web approach is the right call

Now the honest other half, because it is true and I do not want to wave it away. Web technology has advantages that are not small. One codebase can run on a Mac, a Windows PC, and a browser tab at the same time, which for a small team is often the difference between shipping and never shipping. Far more developers know the tools. Iteration is quick. And a lot of software is a thin layer over a web service anyway, so wrapping the web there is not a compromise, it is an accurate description of what the app already is.

The web approach earns its place when:

The app is really a web service, and the desktop version is a convenience around it.
It has to behave identically across several operating systems.
A small team cannot maintain separate native apps and would rather ship one good thing everywhere.
It opens for a focused task now and then, and closes again.

I mean every word of that. If Droppy were a cross-platform service with an account and a dashboard, I would likely have wrapped the web and been glad of the time it saved.

The wrong place for a browser engine

So the case against is narrow. It is not that web is bad. It is that an always-on utility living in your notch is the one situation where every cost of a bundled engine lands on you and almost none of the benefits do. Droppy opens and closes dozens of times an hour. It is meant to disappear when idle. It has no second platform to serve, because the notch is a Mac idea to begin with. Every megabyte it holds and every second it takes to appear is paid over and over, behind the work you are actually doing.

Two apps launching. The native dot is at the finish line almost immediately, because there is nothing to load before your code but the system itself. The web-wrapped dot has to start its bundled browser engine first, so it arrives late. For an app you open dozens of times a day, that wait is not one wait, it is all of them added up. With Reduce Motion on, both dots sit at the start.

Check it on your own Mac. Open Activity Monitor, sort by Memory, and look at what your menu bar and always-on utilities are holding while you are not even using them. The ones built on a bundled browser engine tend to stand out at once, sometimes heavier than the apps you have open and actively working in. A small utility belongs near the bottom of that list, not fighting for the top.

Respect for the machine you already own

So Droppy is native because of where it lives, not because native is a trophy. It is one of the quieter principles behind the app, and it rhymes with the case for making your Mac feel fast again: your computer's memory and battery are finite and already spoken for, and a tool that asks to run all day owes it to you to ask for as little as it can. Choosing native is how I keep that promise. It is more work, and it ties Droppy to one platform for good, and for a permanent spot at the top of your screen that is the right trade. It tries to be the kind of guest you forget is in the room, which only works if it travels light.