Review and moderation

To keep the platform safe and compliant, Jest reviews apps before they are published and moderates the content they generate afterwards.

These processes enforce the:

• Acceptable Use Policy
• Game Development and Publishing Agreement

You are responsible for keeping your content compliant with both at all times.

The Launch checklist covers what your app has to do to pass. This page covers what happens once you submit it, and how the content your app produces is moderated afterwards.

What Jest moderates

Content	Checked by	When
Your app	A person	When you submit for review
Images in your library	Automated	Shortly after you upload
Notification content	Automated	Shortly after you schedule
Referral share images	Automated	Shortly after they are set

Only app review starts with a person. The rest is automated. We do review Image Library failures and can pass an image that was caught wrongly, but there is no equivalent for notification text or referral share images - if those fail, the automated verdict stands and you change the content.

App review

Before you can submit

Your app needs:

• A build uploaded and activated in the Versions tab.
• A logo and a hero image.
• A support email.
• The Game Development and Publishing Agreement and the Acceptable Use Policy signed by your team, under Team settings.

The Submit for Review button on your app's settings is disabled until the build, the images and the signed documents are in place - hover it to see which are missing. A missing support email does not disable it; that one is caught when you click.

Those get you as far as the Simulator. Submitting from there also requires the automated Basic Launch checks to pass. The Basic Launch requirements a reviewer assesses by hand are not part of that gate - they are judged after you submit.

What you submit

In the Developer Console, submitting goes through the Simulator. You can start from the Submit for Review button at the bottom of your app's settings, which saves your changes and takes you there, or open the Simulator yourself.

Play through your app, then submit. The session goes up with it - the SDK calls your app made, and a screen recording if you choose to record one - so the reviewer can watch the run behind your checks. Sessions are stored against the build rather than the submission, so if you record several runs for the same build the reviewer sees your recent ones, most recent first, rather than only the run you submitted from. You will also answer a few short questions about your app on the way through.

You can apply to the Jest Fund in the same step, once the automated checks are green - every Basic Launch and Fund check the Simulator runs, which is a stricter bar than submitting for review alone. The Fund requirements a reviewer assesses by hand are judged along with the rest of your submission, so applying does not mean you have already cleared them. The application is attached to this submission, so there is no separate process to follow.

A Fund decision can take longer than the review itself. Your app may be approved and published while its application is still open - for some apps we want to see how they do with real users before we decide.

While your app is in review

You can only have one submission in review at a time, and you cannot change which build your app runs until the review finishes.

You do not have to withdraw to correct what is under review. In the Versions tab, select Use in pending submission on the build you want, then submit again from the Simulator - the action there becomes Update pending submission and replaces what is pending.

To stop the review instead, select Withdraw from Review on your app's settings. That returns the submission to a draft you can edit and submit again.

Review outcome

Expect to hear from us within a few business days.

• Approved - your app goes live, provided its visibility is also set to Public. An approved app left Hidden will not appear on Jest.com.
• Rejected - your app stays unpublished and you are given the reason.

Either way, open the Review tab for your app to see what the reviewer found. Every requirement they assessed by hand is listed with a verdict, any comment they left, and any screenshots or recordings they attached. Reviewer notes reach you on an approval too, so it is worth reading even when you pass.

Fix what was raised and submit again. Each submission is assessed fresh, so a requirement that passed last time is judged again on the new build.

Updating a live app

Once your app is approved and live, new builds and property changes go out without waiting for another review.

Image moderation

Images uploaded to your Image Library are moderated automatically before they can be referenced in notifications. Each image is Pending, Pass, or Fail, and only a Pass image can be used.

A failed image comes with an explanation. Upload a replacement and it is moderated automatically.

A failure is not always final. We look at what gets rejected, and if an image was caught wrongly we can pass it ourselves - so if you are confident an image is compliant, it is worth giving us a little time before you replace it.

Archiving an image stops it being used in new notifications, but scheduling does not fail. A notification that references an archived image still goes out, carrying your app's fallback image instead of the one you asked for, and the substitution is logged under Events → Errors. Notifications you already scheduled keep the image they resolved at the time, so archiving does not pull an image out of messages that are already queued.

For the full flow, see the Image approval process.

Notification moderation

Each notification is scanned automatically shortly after you schedule it, and only notifications that pass are delivered. A notification you just scheduled can therefore be blocked a few moments later, rather than at send time.

Blocks usually come from in-game variables reaching the notification body - most often a username or character name the user picked themselves. If your app lets users name themselves or their characters, run those names through a moderation service of your own before you store them.

Blocked notifications appear under Events → Moderation in the Developer Console, with the reason.

One exception: a referral conversion notification built from the notificationTemplates you pass to shareReferralLink() is never blocked. If its text fails, Jest replaces all of its text - title, body and CTA - with pre-approved platform copy and sends it anyway, so the user still hears that their invite converted. Your image is kept - only the text is replaced. This substitution is not reported anywhere in the Developer Console, so test your referral templates rather than relying on being told: a template that fails moderation keeps converting users, just not in your words.

Problems with the assetReference parameter - a reference that does not exist, was not approved, or has been archived - appear under Events → Errors instead. These do not stop the notification: it is sent with your app's fallback image, so a broken reference shows up as the wrong artwork rather than a missing message. Check this view if your notifications are delivering without the image you expected.

For details, see Events.

Referral share images

A shareImage passed to shareReferralLink() is moderated on the same automated path as your library images, and is used optimistically while that runs - so a new image is not held back waiting for a verdict. Changing the image sends the new one back through moderation.

A failed image does not block the share. The link falls back to a card Jest generates for that referrer - their username and avatar alongside your app's logo - or to your app's ordinary preview when any of those are unavailable. So a rejected image costs you your own artwork, not the referral branding.