Submitting

The chain is short: you publish an open-source repository, submit its URL and a commit, and a reviewed build is signed and published. Nothing you upload is executed before someone has read it.

Why open source

A droplet is native code in Droppy's process, with Droppy's permissions. There is no sandbox between the two — which is what lets a droplet draw real SwiftUI on the notch instead of shipping a JSON description of a layout.

The price of that is review, and review means readable code. A submission without a public repository is refused at intake.

Your licence is yours. The SDK's licence covers the SDK; it claims nothing over what you build with it.

Before you submit

droppykit validate

This is the same check the intake runs. It verifies:

• droplet.json decodes and satisfies validate(submission:)
• the id is lowercase, valid, and matches id and the Info.plist
• every declared surface has a matching conformance
• every capability is one DroppyKit knows
• the Icon Composer document is present, well formed, and self-contained
• the creator avatar is a square PNG of at least 256×256
• the built bundle links the resilient framework, and carries no direct-access imports — see Add the package

A submission that validates locally validates at intake. If it does not, the message names the field.

Submitting

Push your repository, then go to getdroppy.app/submit-droplet and give:

• the repository URL, reachable without credentials
• the commit SHA you want reviewed
• a contact address for questions

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.

Review

Review reads the code and runs the droplet. What sends a submission back, most often first:

1. Capabilities you do not use. The user sees the list before installing. Ask for what you use and nothing else.
2. Design that ignores the surface. Light backgrounds on dark chrome, Title Case labels, borders, invented spacing. See Design guidelines.
3. Work that does not stop. A timer or observer that survives deactivate(). Swift cannot unload code, so it runs until Droppy relaunches.
4. A live activity that never yields. Holding the compact seat when there is nothing to show.
5. An icon that does not read at 28pt.

None of these are rejections. They come back with the reason, and a new commit usually settles it.

Publishing

Once accepted, the reviewed commit is mirrored, built per-architecture against the framework Droppy actually ships, signed with Droppy's Developer ID, and notarized.

The Store already sorts droplets by maker — All droplets / By Droppy / Community — and every row carries its creator's mark, so a published droplet is listed beside your name and your avatar. What is not built yet is the install button behind that row: today an accepted droplet is delivered as a signed bundle and placed in

~/Library/Application Support/Droppy/Droplets/<your-id>/<YourDroplet>.droplet

which Droppy loads at its next launch, running the same five admission checks described in Host support. One-click install from the Store row, the droppy://extension/<your-id> deep link, and auto-update when the catalogue refreshes are the next piece of host work; nothing about a droplet changes when they land.

Versions

version is major.minor.patch, numeric only. A pre-release tag cannot be published: the fleet's catalogue decode is strict, and one undecodable entry refuses the whole catalogue.

Raise it on every submission. The Store compares versions to decide who needs an update.

See also