Publishing to the marketplace

Publishing puts your widget in the in-app marketplace, where anyone can install it with one click after reviewing its permissions. The pipeline is deliberately simple on your side: zip the folder, fill in a listing, submit, and a human reviews it.

Before you start

Two prerequisites, both one-time:

• A purchased DeskDash account. Submissions are tied to paid accounts.
• A publisher handle, set from your account page on the website: 3 to 30 characters, lowercase letters, digits and dashes, starting with a letter or digit. Choose carefully; the handle is permanent, it becomes part of every widget id you publish, and it is shown as the author on your listings.

What you upload

A zip of the widget folder, from the Submit page on desktop-dashboard.com. Zipping the folder itself or just its contents both work. The caps:

• 3.5 MB for the zip
• 200 files, 5 MB per file, 12 MB total unpacked

OS junk (.DS_Store, Thumbs.db, macOS resource folders) is dropped automatically, and so are the generated .deskdash/ folder and jsconfig.json. Those are development files: your editor reads them, a published widget does not need them (the app serves the dd-tokens.css import path itself, so a scaffolded stylesheet keeps working without the folder). Zip them or leave them out as you like. They never count against the limits above, and they never reach the people who install your widget.

Taskbars

A taskbar (a widget with kind: "bar", see building a taskbar) ships through this same pipeline. Pick Taskbar at the top of the submit page before you upload: the zip's manifest must declare kind: "bar" with its bar block and a minAppVersion of at least 0.3.0, and the choice is checked against the zip, so a mix-up gets a clear error instead of a mislabeled listing. Taskbars have no store categories. Screenshots show the bar on a desktop edge, at a size where its icons are readable. Everything else on this page applies as written, and the published taskbar appears on the Taskbars shelf and under Taskbars in the app's marketplace, where installing it offers Use right away.

What validation checks

Upload validation enforces the same manifest rules the app does, strictly. The ones that catch people:

• Unknown manifest fields are errors, not warnings.
• version must be dotted numbers, like 1.2.3.
• Feature floors are enforced: a manifest using the power permission needs "minAppVersion": "0.1.9" or higher, bundled fonts need 0.2.0, a kind: "bar" manifest needs 0.3.0, and so on per the floors table.
• Font files are checked by content, not extension: woff2 only, and every font file must be declared in fonts.bundle.
• settings holds at most 32 entries; a preset name counts as one.

A failed upload returns the full list of problems; nothing is submitted until the zip is clean.

Your widget's public identity

This is the part that surprises people, so read it twice: the store assigns your widget's id. At first publish, the id becomes yourhandle.widget-name, with the second half derived from the manifest's name. Whatever id you used locally is replaced, and the author field is stamped with your handle. Both are outside your control by design; ids carry the publisher's identity, so no one can squat a name or impersonate another author.

Two consequences:

• The id is minted once. Renaming the widget in a later update changes its display name everywhere, but never the id.
• If you publish a second widget whose name slugs to the same id, the upload is rejected and asks you to rename or update the existing widget.

The listing

The listing is filled in on the submit form, not shipped in the zip:

• Category, from the store's fixed set.
• Feature points: 1 to 8 short lines, up to 120 characters each. These render as the listing's bullet list; make them concrete ("Connect and disconnect wifi networks", not "Powerful networking").
• Long description: up to 2000 characters, shown below the features.
• Screenshots: 1 to 5, ordered; the first is the cover shown in the store grid.

The listing title and short description always come from the manifest's name and description, so those two fields are worth polishing before you zip.

Screenshots

Still PNG, JPEG, or WebP images, up to 4 MB each, checked by content. There is no enforced size or aspect ratio; the practical guidance is the form's own: show the widget as it looks on a desktop, at a size where its text is readable. Each screenshot takes optional alt text (up to 160 characters) for accessibility.

One thing to know before you upload: screenshots become reachable at a public URL as soon as they are staged, which is before review. Do not include anything in a screenshot you would not want public.

Review

Every submission goes through automated checks and then a human review of the actual code. The reviewer reads every file, so the bar is legibility:

• Permissions must be justified by what the widget visibly does. The smaller the grant list, the faster the review; http hosts and links prefixes get particular attention.
• No minified or obfuscated code. Widgets ship as plain source with no build step, and the review depends on that.
• Bundled fonts get a licensing check; include the license and make sure the font actually permits redistribution.

You can track the submission on your account's submissions page; it moves through In review to Accepted (or Rejected, and Failed for a pipeline error on the store's side). One submission per widget can be in review at a time.

After acceptance

The version is published and becomes immutable: its exact bytes are what users install, verified against a checksum, and no one, you included, can replace the contents of a published version. Fixes ship as new versions.

Shipping an update

Updates are explicit: on the submit page, choose the widget under "Update an existing widget" and upload the new zip.

• The manifest version must be strictly higher than the published one, and a published version number is never reused. (After a rejection you may resubmit the same number; nothing was published.)
• The listing form prefills from the current listing but is applied wholesale: what the form contains on submit is the whole new listing, so an emptied field disappears from the store page when the update lands.
• The category is fixed on version updates; change it through a listing edit instead.
• If the update adds a permission, users are asked again at install and update time; removed permissions apply silently. Growing the grant list is friction for every existing user, so treat additions deliberately.

Listing-only edits

Screenshots, features, description or category changes without a code change do not need a version bump: your published widgets' pages have an "Edit listing" action that submits just the listing for review, no zip involved.

Removing a widget

There is no self-service unpublish. If you need a widget taken down, contact support. Note that removal from the marketplace never uninstalls copies users already have, and deleting your account does not remove your published widgets either.