Skip to main content
Ten minutes from an empty directory to a published release. You need tappify installed and a vendor account — start there if tappify extension whoami reports neither.
1

Scaffold

Four questions — id, name, description, category — then the starter is copied and its dependencies installed. Pass --id, --name, --description and --category to skip the questions, or --no-install to skip the install.The starter copies more than this — a build config, a worker, a test setup. These are the files you edit:
2

Run your server locally

The widget’s number comes from a procedure, and a procedure comes from your server. dev:worker runs server/worker.ts on port 8787, and the tunnel gives it a public url — Tappify relays procedures from its own servers, so it needs an address it can reach. The server, the tunnel and the dev session each keep running, so each needs its own terminal. Any tunnel works, and so does a server you have already deployed. See Local server during live preview.
3

Run it on your sandbox project

Two lines come back: the local remote entry being served, and the host URL to open. The URL is your sandbox project’s Analytics page, and the widget is in the KPI row with your vendor tile on it, showing the installs figure your own machine just answered. Edit src/widgets/summary.tsx and it reloads.--server points the relay at your tunnel for the length of the session. Drop it and the card reads “The summary did not load”, because the manifest still holds the starter’s placeholder url.Without --live you get a portal preview URL instead, which needs no install. See The dev server.
4

Watch it follow the page

Change the date picker at the top of Analytics. The number changes, because the widget reads useTapFilters() and passes the range to its procedure — see Follow the page’s filters.
5

Run the checks

The same checks the Tap Store runs at publish, with a fix line under each failure.
6

Deploy your server

The tunnel ends with the session, so the manifest needs an address that outlives it. The starter ships a placeholder, and publish probes <server.baseUrl>/tappify/health for a 200 within three seconds: leave the placeholder and the publish stops there. The starter deploys server/worker.ts with wrangler; anywhere that answers the health route works. See Deploy your server.
7

Publish

Two lines: what was sent and its size, and what happens next. The starter is private, so the release is live the moment it uploads, installable inside your own workspace and nowhere else. Nobody reviews a private release.
8

Check the release

The live release, the release in review, the timeline and the install count.

​
What just happened

The starter’s manifest declares one widget, one settings panel, one hosted-storage collection and one server procedure. dev --live registered a dev install on your sandbox project pointing at your local remote entry, which the host allowlists for that install only, and --server pointed the procedure relay at your tunnel for as long as the session ran. publish built, zipped, ran the checks and uploaded the bundle, then took the route the manifest’s visibility chose for it. Once a release is live, the next one skips review whenever it asks for no new scope, no new contribution kind and no wider visibility — it overwrites the live release where it stands. Ask for any of the three and it goes through review while the live release keeps serving. When it is ready for the Tap Store, complete the listing — the long description, one to six screenshots, and your website, support and privacy urls — and set visibility to public. A public manifest is not valid without all of them, and that publish comes back in review, because an admin reads every extension before owners outside your workspace can install it. See Your listing and Visibility.

Add a widget

The next contribution to add, and where it can render.

Publishing

What publish checks, and when a release goes live without review.