Publishing and Updating
Getting a theme or an app reviewed and listed, what the review looks at, and releasing a new version without breaking shops.
Both themes and apps are reviewed before merchants can use them. The review is about security and behaviour, not design or taste.
What the Review Looks At
For a theme: what the templates actually do. Scripts loaded from elsewhere, anything that collects data, anything that calls out to a third party, and whether merchant content is rendered safely.
For an app: the permissions you ask for against what you plausibly need, where your service is hosted, and what happens to shop data once it reaches you.
Asking for permissions you do not use is the most common reason a submission comes back. Narrow them before you submit.
What to Include
A clear description of what it does, in the merchant's language rather than yours. The domains your scripts load from, so merchants with a strict content security policy can allow them. And how to reach you.
A theme needs a screenshot. Name it in the manifest, ship it in the ZIP, and make it a real page rather than a mockup: the chooser is where a merchant decides, and clicking it opens it full size. A homepage at about 1280px wide is the one to take.
A theme is also judged on what a shop gets when it is activated. Ship the pages and the homepage arrangement you designed around, so a merchant installing it sees the shop in your screenshot rather than an empty frame. See Shipping Your Pages and Your Homepage.
Versioning
Use version numbers that mean something. A merchant deciding whether to take an update is reading the number and the notes, and nothing else.
Say plainly in your notes if an update changes behaviour, needs a setting, or replaces template edits.
Updating a Theme Without Breaking Shops
A merchant takes your update with Sync with Platform, which overwrites their copy including any edits they made.
Removing or renaming a setting breaks live shops
A shop holds the settings it saved. If version 2 renames products_per_row to grid_columns, every shop on version 1 loses that value and the page renders at whatever your template defaults to.
Keep old keys working, read the new one with a fallback to the old, and retire it a long time later. Settings are an interface, and this is the part developers treat as though it were not.
Always |default() in the template as well as the manifest, so a setting added in a later version has a value on a shop that has not re-saved.
Updating an App Without Breaking Shops
Your service changes under the merchant's feet, so the rules are stricter.
Add fields rather than renaming them. Keep old behaviour working while you move. If you must break something, version your endpoints and run both for a while.
Remember you are talking to many shops at once: a change you deploy is live everywhere immediately, with no staged rollout.
What Merchants Should Be Told
Anything that changes what they see, anything they need to do, and anything that will look different afterwards.
A silent change that alters their storefront is the thing that loses you trust, even when the change was an improvement.
Support
Say where support goes and answer it. A listing with a dead contact address is reported by merchants and removed.
The common questions are predictable: what permissions you need and why, which domains to allow in the content security policy, what happens on uninstall, and whether you work with their plan. Answer all four in your listing and you will halve the volume.
Keep Your Source
A theme or app that exists only on the platform is one you cannot rebuild.
For themes there is a second reason: a merchant can edit their copy, which forks it without telling you. If they then report a fault, the first question is whether they are running your templates or theirs.