The Publisher Submission Checklist: 19 Things to Fix Before You Send

A submission gets rejected for two reasons: the game did not perform, or the submission was incomplete. The second is entirely inside your control. Nineteen checks covering the build, the analytics, the metrics you attach, the creative, and the store basics will remove it as a cause.

Why this matters

Publisher reviewers work through submissions quickly. A build that crashes on launch or arrives without numbers is closed early, and you rarely find out which it was.

Everything on this list takes minutes to hours. The cost of skipping it is a wasted test cycle, which is measured in weeks.

Running the list also makes the feedback you do get useful. A rejection on merit teaches you something. A rejection on packaging teaches you nothing.

Publishers are not looking for reasons to say no. They are looking for reasons to spend money on a test, and missing basics make that harder to justify.

Build requirements

The build is the first thing that gets opened, so it is the first thing to get right.

1. It launches on a mid-tier device, cold, with no crash and no long black screen.
2. First playable action happens within seconds, with no forced tutorial wall in front of it.
3. No placeholder text or debug UI is visible, including build numbers and console overlays.
4. Orientation is locked to whatever the game actually plays in.
5. It runs offline, or fails gracefully with a clear message if it genuinely cannot.
6. The back button behaves on Android, closing what it should rather than exiting the app.

Test each of these on a real device, not in the editor. Cold launch behaviour in particular is different.

Analytics and SDK requirements

Publishers need to see behaviour, and they need it in a form their tooling understands.

• Integrate the analytics events the publisher asks for, exactly as named in their documentation. Renamed events break their dashboards.
• Fire a session start and session end reliably, including when the app is backgrounded.
• Track level start, level complete, and level fail with the level identifier attached.
• Confirm events arrive by checking the live dashboard before you submit, rather than assuming.
• Include the attribution or mediation SDK if their process requires it, at the version they specify.

The most common failure here is events that fire correctly in the editor and never fire in a release build. Verify on the shipped artefact.

The metrics they expect attached

A build with no numbers is a much weaker submission than a build with modest numbers.

Present these honestly, including the weak ones. Reviewers see a great deal of data and are quick to notice a number presented without its qualifiers.

If you have not run a test yet, say so plainly rather than omitting the section.

Video and creative assets

Creative is often what actually gets watched first, because it is faster than installing a build.

1. A short gameplay video with no editing tricks, showing the real loop.
2. The best three seconds identified, since that is what an ad is built from.
3. Portrait format if the game is portrait, rather than a cropped landscape capture.
4. Clean capture with no recording overlays, notifications, or debug information.
5. At least one creative concept cut from the footage, if you have tested any.
6. Screenshots that show the mechanic rather than a menu.

Store and legal basics

These are quick, and their absence reads as inexperience.

1. A working store listing or draft, if the process asks for one.
2. The app identifier is final and not a template default.
3. App icon is original and not placeholder art.
4. Third-party asset licences allow commercial use, and you can show it.
5. No trademarked names, characters, or music anywhere in the build or creative.
6. Privacy policy exists and is linked, particularly if any SDK collects data.
7. You can confirm you own the code, including anything a contractor wrote.

Point 19 catches teams more often than it should. Ownership should be settled in writing before submission, not after interest arrives. We cover it in Who Owns Your Game IP.

What we would do

Run the list twice: once a week before you intend to submit, and once on the actual build you are sending. The first pass finds the work, the second catches what the final build broke.

Keep a submission folder per prototype containing the build, the video, the metrics summary, and the asset licences. Assembling it fresh each time is how details get missed.

Send to one publisher first rather than all of them. Feedback from the first submission usually improves the next one enough to be worth the delay, and it avoids burning several relationships on the same fixable mistake.

The short version

• Rejections split into performance and packaging; packaging is fully in your control.
• Cold launch on a real mid-tier device is the check most worth repeating.
• Use the publisher's exact event names and verify events in a release build.
• Attach metrics with their qualifiers, including the unflattering ones.
• Capture clean portrait footage and identify the best three seconds.
• Settle asset licences and code ownership before you submit, not after.

Run the nineteen checks on your current build before it goes anywhere. If you want a second read on a submission package, send it over.

Related reading: What Voodoo Actually Looks For, Homa, Voodoo, Supersonic, CrazyLabs, and The Pre-Test Checklist Before You Spend a Dollar on UA.