The word extension hides a fact worth being blunt about. A Droppy Droplet is not a JSON description of a layout and it is not a mini app in its own box. It is compiled native code that runs inside Droppy, in Droppy's process, with Droppy's permissions. That is exactly what lets a Droplet draw real SwiftUI on the notch, use the shelf, and read the pieces of macOS Droppy was allowed to read. It is also why installing one deserves a sentence of explanation rather than a spinner.
Availability, September 19, 2026: external droplets were introduced on the 15.2.3 nightly channel. They are not a feature of the older public stable release. Individual droplets can require an even newer host: the current SDK scaffold targets 15.3.0. Check the requirement shown on a listing instead of assuming every droplet runs on every Droppy version. This guide describes the current Store implementation.
Built in, published, or built on your Mac
Three kinds of Droplet reach Droppy, and they arrive by three different doors. The Store's own filter says it plainly: All droplets, By Droppy, Community.
Built-in tools ship inside the app. There is nothing to download, no row to install and no bundle in your Application Support folder. They are part of the release you already have, switched on in Settings like any other feature, and they update when Droppy updates. Some of them fetch an optional signed helper of their own when you ask for the work that needs it, which is a runtime component for that tool rather than a second app.
Droplets from the Store are published builds. Droppy downloads a zipped, signed bundle from the catalogue, verifies it, and copies it to disk before loading it. That covers Droppy's own extra tools and everything listed under Community, which is where a Droplet made by somebody outside Droppy lives.
Local droplets are the builds you make yourself. Running droppykit build writes an unsigned .droplet bundle into .build/, and Droppy will run that too: on Droppy's Store page, under Local droplets, drop the bundle or the droplet's folder, or click to choose either. Droppy did not sign that build, so it asks you to approve it before running it. A bundle received from another person also follows this approval policy if Droppy did not sign it.
| Built in | Store Droplet | Local droplet | |
|---|---|---|---|
| Where it comes from | Inside the app | The Store catalogue | Your .build/, or a file someone sent you |
| Signing | Covered by the app signature | Droppy's Developer ID | Not necessarily signed by Droppy |
| Install step | None, switch on in Settings | Install from the Store row | Add from disk under Local droplets |
| Checked before loading | With the app | Download hash, signature, identity and compatibility | Admission checks and approval of the exact bundle digest |
| Droppy asks first | No | Once, for the first community droplet | Yes, and again every launch |
| Who answers for it | Droppy | The maker named on the row | You |
What install actually does
The install control starts a download and a set of checks. If a check fails, the bundle does not get a special exception just because it appeared in the Store. The practical result is that a listing must match the file that reaches your Mac.
Droppy first checks that the download succeeded, then compares the archive's SHA-256 hash with the catalogue. It unpacks the archive, checks the bundle's Developer ID signature against Droppy's signing team, and compares its own id and version with the listing. These checks establish that the downloaded bytes match the offered build; they do not establish that its behavior is harmless or bug-free.
Then the loader takes over and runs the same admission checks again on the installed copy, in order of cost: is it a loadable bundle with the keys Droppy requires; do the bundle id, the plist id and the folder name agree; is its ABI in range and its API no newer than this Droppy; does it link the framework Droppy ships rather than reaching past it; did it take the app down on its last launches, in which case it is held back until you ask again; and finally, whose code is it. The loader performs its trust check immediately before loading the bundle's code. Nothing about the Store's checks replaces the loader's, and that is on purpose: the loader reads the binary, while the Store reads a row about it.
The signature is not a vouch
This is the part that is easy to misread. A community Droplet is signed with Droppy's Developer ID, but Droppy did not write it. Droppy signs the reviewed commit so that what lands on your Mac is the build that was reviewed and not something swapped in afterwards. The review reads the submitted source, and the signature makes that read meaningful. Neither one is Droppy promising the Droplet is good.
The Store is built to say so rather than imply otherwise. A community row carries its maker's name and mark and links to the repository it was built from, so the person to look up is right there. The Droplet developer terms are explicit that a maker stays responsible for their Droplet after publication, including its bugs and how it handles user data. When you install a Droplet from another maker for the first time, Droppy tells you once, in the same words, that such droplets can be unreliable.
Updates, and the restart in the middle of them
The Store refreshes its catalogue when opened if its five-minute cache is stale, and the app's six-hourly update check also refreshes it. Droplet auto-update is enabled by default. You can change Update droplets automatically in Settings, Software update if you prefer to choose when installed droplets update.
Two details are worth knowing because they are the honest edges of the model. An update this Mac could not run is not offered: if a new build needs a newer Droppy or a newer DroppyKit than yours, it stays on the version that runs, and updating the app is what unlocks it. And macOS cannot replace code that is already mapped in a running process. If the Droplet had already run this session, its new build lands on disk but the old one keeps running until Droppy relaunches, and Droppy says so rather than reporting a version you are not running.
Switching one off is not removing it
A Droplet you switch off is still installed. It is listed in the Store, its settings survive and its place on the shelf is kept; it simply does not run. Removal is the bigger step: Droppy deactivates the Droplet and deletes its bundle. What it does not delete is your configuration or the Droplet's own container of files, so removing and reinstalling finds your setup intact rather than silently wiped. The one thing removal cannot do is take the code back out of Droppy: Swift cannot unload a bundle, so a removed Droplet's code stays in the process until Droppy quits. A well-behaved droplet stops its work during deactivation. If a faulty droplet leaves work running, restarting Droppy clears the process.
If you want to build one
You can also make a tool of your own. DroppyKit is the public SDK for external droplets, and an accepted submission is listed beside its creator's name. Start with the guide to building a droplet, then the submission walkthrough when it is ready to share. Publishing an accepted Store update does not require a new Droppy app release, although the new bundle still has to meet each Mac's compatibility requirements.