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 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.
• minAppVersion, if you write one, must be a plain x.y.z. You do not need one: see the app version below.
• 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.

The app version

You do not pick which DeskDash release your widget needs. The store works it out from the manifest and stamps it as minAppVersion on every new version: each permission, setting type, preset and manifest field you use has a release it last changed in, and so does the SDK itself, and the stamp is the newest of those. The upload's success screen and your submissions page show the result ("needs DeskDash 0.3.9 or newer").

A minAppVersion you write yourself only counts when it is higher, for the rare widget that depends on an app fix. A published version keeps the value it shipped with. People on an older app see "Needs app update" on your listing.

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.

Your submissions page on the website shows each submission's status, and you get an email at each decision:

• In review: waiting for the reviewer.
• Changes requested: the reviewer wants something fixed, and the note on the page (and in the email) says what. Use Upload a fix there: keep the same version, and the fix joins the same review instead of starting a new one.
• Live: accepted and published.
• Not accepted: the note says why. Nothing was published, so you may submit again with the same version number.
• Withdrawn: you took it back. Any open submission has a Withdraw button.
• Failed: a pipeline error on the store's side.

One submission per widget can be open (in review or waiting for a fix) 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 or a withdrawal 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.

Unlisting a widget

Your submissions page has an Unlist button on each live widget. An unlisted widget leaves the marketplace for new users: it drops out of browse, search, its web page and the sitemap. Everyone who already installed it keeps it, still gets the updates you publish, and can reinstall it. Relist puts it back with no new review, since its content was reviewed when it shipped. The widget id stays yours either way.

Unlisting never uninstalls copies people have, and deleting your account does not remove your published widgets either. To have a widget removed for everyone, contact support.