The chain from your checkout to somebody else's Mac is short, and every link in it is deliberately boring. You publish an open-source repository. You submit its URL and one commit. A person reads that commit and builds it. If it is accepted, the build is signed with Droppy's Developer ID and listed beside your name. Nothing you upload is executed before somebody has read it, and nothing you write afterwards changes what shipped, because a submission names one commit rather than a branch.
droppykit submit. It opens a form with the repository, commit and droplet id filled in. Complete the contact details and read the developer terms before submitting. You receive a DS- reference. Acceptance and publication follow human review; submitting is not an automatic publish button.
Why it has to be open source
A Droplet is native code running inside Droppy's process with Droppy's permissions. There is no sandbox between the two, which is exactly what lets a Droplet draw real SwiftUI on the notch instead of shipping a JSON description of a layout. The price of that arrangement is review, and review means readable code. A submission without a public, credential-free repository is refused at intake.
The developer terms say publication does not transfer ownership of your droplet to Droppy. You still need rights to the code, icon, avatar and name you submit, and must meet the applicable licenses. The Store credits your name and links to your repository. Read the current terms yourself before submitting; the guide here describes the workflow.
Validate before you submit
droppykit validate runs the submission checks locally and reports problems to fix before review. The checklist covers manifest fields, identity, surfaces, declared capabilities, artwork and bundle linkage. Your Icon Composer document must be self-contained, and your creator avatar a square PNG of at least 256×256. Build through droppykit build so the bundle links the resilient host framework correctly. Passing local checks is useful preparation, not a guarantee that a remote build or human review will accept the submission.
What it does not ask for is screenshots. Intake wants a repository, a commit and your name; the Store draws your Droplet from its icon, its summary and its real widget. Ship the icon and the avatar and that part is done.
Submit the exact commit
Push your repository, then run droppykit submit. It reads the id from droplet.json, the repository from origin and the commit from HEAD, opens the form with all three in place, and leaves you a name and an address for replies. It refuses to hand over a commit that cannot be reviewed: uncommitted changes, or a HEAD the remote has not seen, because the intake clones the repository at exactly that SHA and a commit that is not on the remote is a submission of nothing.
The submission is on record the moment you press the button. The page answers with a reference of DS- and six characters, the same reference arrives by email, and replying to that email is how you add anything later. The commit is pinned: a repository that moves after submission does not change what shipped, and an update is a new submission naming a new commit. Sending the same commit twice returns the same reference instead of a second entry.
One thing to leave out of droplet.json is the commit itself. Version 1.6.3 of DroppyKit dropped the old source.commit field, and the reason is circular: a manifest cannot name the commit that contains it, because writing the SHA in changes the tree and the tree is what the SHA is of. Leave it out; an old manifest that still carries one validates and review ignores it.
What review reads for
Review is a person reading your code and running the Droplet. The things that most often send a submission back are specific, and it is worth writing against the list rather than discovering it by email.
Capabilities you do not use. The user sees the list of what a Droplet asks for before installing it, so ask for what you use and nothing else. Design that ignores the surface. Light backgrounds on dark chrome, Title Case labels, borders and invented spacing all read as a guest in Droppy rather than part of it. Work that does not stop. A timer or an observer that survives deactivate() keeps running, and because Swift cannot unload code it runs until Droppy relaunches. A live activity that never yields. Holding the compact seat when there is nothing to show is worse than not being on the notch. An icon that does not read at 28pt.
Review can ask for changes or decline a submission. If you are asked for a revision, reply using the reference in your email and follow the review instructions when sending the new commit. Do not assume that opening a second submission automatically updates the first one.
What happens after acceptance
After acceptance, the publication flow builds the reviewed commit for both Apple silicon and Intel against Droppy's framework and signs the bundle with Droppy's Developer ID. Users receive that build through the catalogue, where the installer checks its hash, signature, id and version. A community author does not need access to Droppy's signing credentials or publishing infrastructure.
On the Store side, droplets are sorted by maker, and the row carries your mark and your name, so the build is listed beside the person behind it. The row's switch is the install. Droppy downloads the signed bundle from the catalogue, checks its hash and its signature, copies it into ~/Library/Application Support/Droppy/Droplets/<your-id>/<YourDroplet>.droplet, and loads it through the same admission checks every Droplet passes. A newer published version is offered as an update when the catalogue refreshes, which happens every six hours and every time the Store opens. Before the first Droplet from another maker is installed, Droppy tells the user once that such droplets can be unreliable.
| The build on your Mac | The build in the Store | |
|---|---|---|
| Signing | A local development build, not signed by Droppy | Droppy's Developer ID |
| Built against | The SDK version pinned by your package | The compatible host framework, universal |
| How it reaches a Mac | You drag the bundle in | Downloaded from the catalogue and verified |
| Does Droppy ask | Approval for a build it did not sign, again each launch | One-time external-droplet notice before the first community install |
| Updates | You rebuild and re-add it | Offered after a newer compatible build is published |
| Your settings | Kept | Kept |
Versions
Use a numeric dotted version such as 1.2.0, following the SDK's major.minor.patch convention. Store versions do not accept suffixes such as -beta.1. An update must have a version greater than the one already published. A new commit alone does not tell an installed Mac that a newer version exists.
An accepted droplet update can be published independently of a Droppy app release. Keep the bundle's minimum app and SDK requirements accurate: the current scaffold targets Droppy 15.3.0, and an older host will refuse it. A Mac that already loaded your previous build may need to restart Droppy before the new code can run. The Store reports that restart requirement; downloading the replacement is not the same as running it.
What you stay responsible for
Submitting means accepting the Droplet developer terms. You stay responsible for your Droplet: its bugs, and how it handles user data. Droppy reviews the submitted commit and signs the accepted build, so somebody has read the code before it ships, and the signature means the build is the one that was read. That review and that signature do not mean Droppy vouches for the Droplet or maintains it. It remains yours, and users are told as much before they install it.