The chain from your checkout to somebody else's Mac is short, and every link in it is deliberately boring. The Store is a repository, one folder per droplet. You open a merge request that adds yours. A pipeline checks it, a person reads it, and merging is publishing: the same pipeline builds the merged source universal, signs it with Droppy's Developer ID and puts it on the shelf beside your name. Nothing is executed before somebody has read it, and what ships is the source that merged, which is the source anyone can go and read.
droppykit submit. It forks gitlab.com/droppyformac1/droplets, copies your package into droplets/<id>/, pushes a branch and opens the merge request. The pipeline checks it immediately; a maintainer reads the code and merges. Merging publishes it, within minutes, with no Droppy release in between.
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. Your source lives in the Store repository in the open, which is also what makes the published build checkable: the folder that merged is the folder that was built.
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 contribute, and must meet the applicable licenses. Your droplet carries its own licence in droplet.json, the Store credits your name, and CODEOWNERS records the folder as yours, so a change to it asks you first. Read the current terms yourself; opening the merge request is where you accept them.
Validate before you submit
droppykit validate runs the repository's own checks locally and reports problems to fix before the pipeline finds them. 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 locally is the same set of rules the merge request runs, so a green run at your desk is a green pipeline; it is not a promise that review will merge it.
What it does not ask for is screenshots. 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.
Open the merge request
Run droppykit submit. It reads the id from droplet.json, forks the Store repository under your GitLab account the first time, copies the package into droplets/<id>/, pushes a branch and opens the merge request with the checklist filled in. Everything it does by itself you can do by hand: it is a fork, a folder and a merge request, and the repository's CONTRIBUTING.md spells out every rule the pipeline enforces, so nothing comes back for a rule you could not have known.
The merge request is the conversation. The pipeline reports on it within a minute or two, questions arrive as comments, and a new commit on the same branch answers them and re-runs the checks. Nothing is pinned behind your back: what publishes is the branch as it merges, so the last commit you push before the merge is the one that ships.
Two fields in droplet.json are about the repository rather than your code. source.repository points at your folder in the Store, which is what the Source code row in Droppy opens, and creator.gitlab is the account that owns it in CODEOWNERS. Leave out the old source.commit: DroppyKit 1.6.3 dropped it, because a manifest cannot name the commit that contains it.
What review reads for
Review is a person reading your code and running the Droplet. The things that most often send a merge request back are specific, and it is worth writing against the list rather than discovering it in a comment.
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 request for changes is a comment on the merge request; push to the same branch and the pipeline runs again. A question is not a rejection, and most merge requests that get one merge on the next commit.
What merging does
Merging runs the publish job on main: it builds your folder for both Apple silicon and Intel against Droppy's framework, signs the bundle with Droppy's Developer ID, uploads it and writes the catalogue row. Users receive that build through the catalogue, where the installer checks its hash, signature, id and version. A community author never touches Droppy's signing credentials or its publishing infrastructure, and never waits for a Droppy release.
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 on the update check's pass 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 | By default, approval for a build it did not sign, again each launch; can be turned off under Local droplets | 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.
A droplet update is published independently of a Droppy app release: raise version, add the entry to CHANGELOG.md, open another merge request. 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
Opening the merge request means accepting the Droplet developer terms. You stay responsible for your Droplet: its bugs, and how it handles user data. Droppy reads the merge request and signs what it builds from it, 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.