---
title: "Find, install and update community droplets"
description: "Droppy's Store has tools built in, tools by Droppy, and tools by other makers. What a community Droplet is, what install verifies, and what you are trusting."
canonical: "https://getdroppy.app/blog/community-droplets-mac"
last-updated: "2026-09-19"
---

# Find, install and update community droplets

[All posts](https://getdroppy.app/blog/)

Droppy guides

Jordy Spruit September 19, 2026 8 min read

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.

**Direct answer:** open Settings, Store and look under Community for tools by other makers. Read the description, creator and compatibility requirement, then use the row's install control. Droppy checks a downloaded bundle's published hash, signature and identity before loading it. Before your first droplet from another maker, it also asks you to acknowledge that these tools can be unreliable. The maker remains responsible for the droplet.

**Availability, September 19, 2026:** external droplets were introduced on the [15.2.3 nightly channel](https://getdroppy.app/changelog). They have been part of every public release since Droppy 16.0.0, the current stable included. 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.

![Five cobalt droplet sculptures with leaf, wave, star, ring and stripe patterns on a shelf beside a flowering branch](https://getdroppy.app/assets/images/blog/editorial-20260919/community-droplets-hero.webp?v=1)

Built in, published, or built on your own Mac. The difference is not cosmetic: it decides who signed the build and who answers for it.

## 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. By default, Droppy asks you to approve a build it did not sign before running it, and asks again each launch. A bundle received from another person also follows this policy if Droppy did not sign it. Choose **Don't ask again for local droplets** to stop these questions for all local builds, including new and changed ones, across restarts. They still pass Droppy's bundle checks and run with Droppy's permissions. Turn **Ask before running local droplets** back on in Settings, Store, Local droplets to restore the questions.

|  | 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, plus exact-build approval by default |
| Droppy asks first | No | Once, for the first community droplet | By default, and again every launch; can be turned off |
| 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](https://getdroppy.app/blog/build-your-own-droppy-droplet), then the [submission walkthrough](https://getdroppy.app/blog/publish-a-droplet-to-droppys-store) 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.

## Sources and version scope

**Checked against the current product:** the [Droplet Store](https://getdroppy.app/features#droplets) page lists the Store's filters as All droplets, By Droppy and Community, and describes DroppyKit as the SDK behind every Droplet. The install order, the SHA-256 and Developer ID checks, the identity and version comparison, the admission checks, the session-only question for unsigned builds and the update behaviour are the ones documented for developers in [Submitting](https://getdroppy.app/docs/droppykit/submitting), [Host support](https://getdroppy.app/docs/droppykit/host-support) and [Droppy Playground](https://getdroppy.app/docs/droppykit/playground), including the install path, the six-hourly catalogue refresh and the one-time notice for droplets from other makers. The responsibility wording follows the [Droplet developer terms](https://getdroppy.app/droplet-developer-terms).