← Work

Submit & Publish Widget

Streamlining app submission for third-party developers

2022 · Developer tools

Developers submitting apps to the Wix App Market had to navigate to a separate page to check submission requirements, disconnected from their workflow, surfacing too few blockers too late in the process. By the time they reached it, most issues were too late to fix without significant rework, and the Developer Relations team was rejecting a large volume of apps that simply weren't ready. I replaced the fragmented checklist with a contextual sidebar widget that also surfaced recommendations: best practices that weren't hard blockers but could meaningfully improve app quality.

What I Did

Replaced the fragmented tab-based submission checklist with a contextual sidebar widget
Designed three adaptive layout states (minimized, widget, expanded) based on developer proximity to submission
Surfaced real-time blockers and recommendations directly in context
Extended the system to support auto-publishing for changes that don't require a full review cycle
Defined the blockers and recommendations themselves - mapping each check to what it validates, who it applies to, and whether it's a hard blocker or a recommendation

The full list of blockers and recommendations — defined collaboratively and mapped to specific app states, audience types, and content checks

Solution

The widget has three states, each designed for a different moment in the developer's journey.

The developer starts from the widget view, which they can minimize at any time.

Minimized state — a low-footprint navigation item for developers not actively preparing a submission

Widget view with active blockers — submission disabled, with a count of issues to resolve

Open panel — blockers tab showing each issue with a direct action to fix it

Open panel — zero blockers state, developer can now submit

Open panel — recommendations tab with optional improvements the developer can act on or dismiss

Recommendations tab after one item is dismissed

Widget view — zero blockers, submission enabled

Edge case — widget inactive when the app is already under review and no new version is pending

Iteration: auto-publishing for published apps

After launch, the Developer Relations team flagged a new bottleneck: published apps making minor market listing changes - like updating copy or screenshots - still had to go through a full submission review. To remove that unnecessary friction, I designed an auto-publish path where small changes go live immediately, while significant changes (new permissions, OAuth, extensions) still require a review.

The widget needed to adapt accordingly. Published apps now see an "Update" widget that routes them based on what they changed.

Decision logic — routes developers to auto-publish or submit for review based on the nature of their changes

Widget states by app type — how the submission, update, and publish widgets adapt for draft, published, Wix, and enterprise apps

Full widget states matrix — all submission, update, and publish widget variations across every app lifecycle stage

Published app — widget default state, no pending changes

Published app — changes saved, no blockers, ready to publish

Published app — changes saved with active blockers, publishing blocked

Impact

The auto-publish feature drove 1.2K publishes across 350 apps in 2024. Data on submission rejection rates prior to the widget redesign is pending.

Bottom line

The most interesting design decision was distinguishing blockers from recommendations: hard requirements that prevent submission versus best practices that improve quality without being mandatory. Getting that taxonomy right, and then deciding what each check actually validates, was more consequential than any of the UI decisions.