The Asset Store submission checklist nobody writes down

The written rules are the easy part

Unity publishes the Asset Store submission guidelines. They tell you the required licenses, the minimum documentation, the forbidden content types, the required import package format. You can read them in an afternoon. Follow them and you'll clear maybe sixty percent of the review bar.

The other forty percent is the unwritten part — the things that get your submission kicked back to "Needs Revision" with a terse note. We've submitted four plugins. Here's everything we've learned that isn't on Unity's official page.

Your demo scene is the first thing the reviewer opens

Reviewers don't read your README first. They open a fresh Unity project, import your package, and look for a demo scene. If there isn't one, or if the one you included throws a MissingReferenceException on open, your review is effectively over.

Our rule: every SyE plugin ships with a scene called Demo_<PluginName> under Assets/<Publisher>/<Plugin>/Demos/. It opens without errors on a vanilla Unity install, with no external dependencies. We test this by cloning the package into a clean project the hour before submission.

The folder layout reviewers expect

Reviewers scan the Assets/ folder with a pattern-matching eye:

Assets/
  <PublisherName>/
    <PluginName>/
      Runtime/
      Editor/
      Demos/
      Documentation/
      README.md
      CHANGELOG.md
      LICENSE.md

Deviations raise questions. Two publishers' names at the same level raises questions. A .cs file at the root raises questions. Matching the pattern lets the reviewer move past structure to the actual code faster.

Do not ship editor-only code inside a runtime assembly

This is the number one cause of revision requests for editor tools. If a script uses anything from UnityEditor, it has to live in an Editor/ folder, and your asmdef has to specify includePlatforms: ["Editor"]. Violating this makes the package fail to build in user projects that target iOS, Android, or any non-editor platform.

Every time you add a new file, ask: does it use UnityEditor? If yes, Editor folder. No exceptions.

Dependencies are suspicious

The reviewer has no opinion on your Newtonsoft.Json dependency being "small" or "standard." A dependency is a liability in review. If you can write 40 lines yourself and avoid pulling in a third-party package, do it.

When you truly need a dependency, declare it unambiguously — as a Unity package via com.unity.nuget.newtonsoft-json or as a clear NPM-style package manifest. Never bundle another library's DLL directly unless you're licensed to redistribute.

The video trailer rule

Short videos get watched. Long videos don't. Under 60 seconds, with the feature visible in the first 5 seconds, beats every "comprehensive walkthrough" we've tried. Unity's own store analytics agree — watch-through rates collapse past the one-minute mark.

The tone of your listing copy matters

Reviewers skim listings too. If your description reads like it was written by a marketing agency, they'll be suspicious of the engineering behind it. Short sentences. Concrete features. One-line tagline. No adjectives like "revolutionary" or "ultimate."

This isn't just about approval — it's the same copy your customers read. The studios that sell best on the Asset Store tend to sound like engineers who built a tool and want you to try it, not marketers who had one commissioned.

The thing that nobody tells you

If your submission is rejected once, it's routine. If it's rejected twice, the same reviewer likely gets routed to it the third time and they already have context. Be extremely explicit about what you changed between submissions. Include a short note at the top of your submission comments: "Addressing revision request — moved GizmoDrawer.cs to Editor/, added demo scene, updated LICENSE.md." Make the reviewer's next pass take two minutes instead of twenty.

Kindness to the person on the other end is not strategy. But it is, always, the thing that speeds things up.