DroppyKit

Submit a droplet

You build it against the public SDK. Jordy reads the source, signs the bundle, and publishes it to the shop.

How this works

The store is review-and-sign. You never distribute a droplet yourself, and users only ever download bundles Jordy signed.

1. Build in your own repo

GitHub, GitLab, anywhere. You keep ownership and you keep your history. Build against DroppyKit and test in the dev harness, no Droppy needed.

2. Submit a commit, not a branch

Review happens against one exact commit. When it passes, that snapshot is mirrored into a private repo Droppy controls, and that mirror is what gets built and signed. It is the trust anchor: what shipped is provably what was read.

3. Updates are diff reviews

Your second submission is not a re-review. It is read as the range between the last published commit and the new one, so shipping a fix stays cheap.

4. Jordy signs everything

Droplets run in process with no sandbox, and macOS library validation means Droppy only loads code signed with one Team ID. Centralised signing is why review has teeth, and it is also why approval is discretionary: a submission can be well written and still be declined.

submitted → in_review → changes_requested → approved → published

Approved means reviewed, signed and staged. Published only flips when the store manifest actually serves your build, so you will never see “published” while users cannot install.

What review checks

Every item below is something a reviewer goes and looks at in your source. None of it is a formality.

Loading the checklist…

Sign in first

Submitting needs a Droppy license, same sign-in as The Trench. If you are already signed in there, you are already signed in here.

Prefer an email link or Discord? Sign in on The Trench and come back to this page.

Your submissions

New submission

Everything here comes off your bundle’s Info.plist and your repo. Get it right and review starts immediately.

Your DroppyDropletID. Lowercase, dashes, no spaces.
What users see in the shop.
One short, factual line shown below the name.
The category users browse in the Droplets shop.
An https link. Private repos are fine, just grant read access to the reviewer before you submit.
The full 40-character sha. Not a branch, not a tag, not a short sha: review pins to one snapshot and so does the mirror.
The integer from your Info.plist.
The semver from your Info.plist.

These must match your DroppyPermissions array exactly. Review diffs this list against the symbols your bundle actually links: using something you did not declare is a rejection, and declaring something you do not use is a change request. Amber ones need a written justification in your description.

Where review questions go. Not shown publicly.
Be specific about capabilities and about anything that touches the network, the filesystem, or another app. Vague descriptions come straight back as a change request.

Approval is discretionary. Submitting does not guarantee a listing.