Skip to main content

Launch checklist

Before submitting your app for review, make sure it meets the requirements below. They fall into three tracks, each with a different purpose:

  • Basic Launch requirements - the minimum bar for publishing on Jest.com. Missing any of these will fail review.
  • Jest Fund requirements - required only if you are applying to the Jest Fund. Your app can still be approved and published if you don't meet all of these.
  • Recommended - recommended for every app because we believe they make for a better user experience. Passing them will strengthen your Fund application, but they are not required.

Most items are checked automatically. Run your app in the Simulator from the Developer Console and open the Checklist tab, where each automated item below appears as a live pass/fail under its track. Items marked reviewed manually are assessed by a member of the Jest team during review. You cannot action these in the Simulator, so check them against your own app before submitting.

API names below are written in their HTML5 form. Each linked SDK page carries the Unity equivalent in its own tab.

Some checks only apply to certain apps. If your app does not sell products, for example, the purchase checks are skipped and your count reflects only the checks that apply to you.

For legal and content requirements (Acceptable Use Policy, Game Development and Publishing Agreement, and Jest Fund obligations), see Review and moderation.

Basic Launch requirements​

App quality - reviewed manually​

  • Experience is intuitive, coherent, and complete. At least one member of the Jest team will play through your app. It may fail review for obvious bugs, broken or dead-end flows, confusing UI or controls, poor legibility, low-quality or placeholder content, or anything else that makes the experience feel unfinished or hard to use.

Mobile web readiness - reviewed manually​

99% of Jest users are on mobile, so your app must run smoothly in major mobile browsers, primarily iOS Safari and Android Chrome. See also the technical requirements.

  • Loads in under 10 seconds. Time to interactive on a standard mobile connection. Faster is better. Some tips:
    • Target < 5 MB for web-native engines (Pixi, Phaser) and < 20 MB for heavier engines (Unity).
    • Load essential assets first; load the rest progressively or on demand.
    • Minimize runtime. Unity devs: see mobile web optimization and profiling guides.
  • No vibrations or haptics. These are not supported consistently in mobile browsers and can cause unexpected behavior.
  • Stable after extended usage (10+ minutes). Mobile browsers have strict memory limits, so crashes, freezes or heavy overheating will fail review.

Platform requirements - reviewed manually​

These are not allowed, per our Developer Agreement.

  • No CTAs, prompts, or copy that direct users outside Jest. This includes links or references to external websites and apps (Discord, Instagram and similar), app install banners, and external authentication or prompts to sign up with an email outside Jest. External links are blocked by default, so remove any CTAs or copy that rely on them.
  • No in-app ads, and no mechanics that depend on ad revenue. In-app advertising is coming to Jest, so stay tuned.

SDK health​

User management​

  • Call getPlayer() to read the current user, or getPlayerSigned() if your own backend needs to verify them. Either satisfies this check.
  • Save user progress while they are still a guest, keyed on the stable playerId both calls return, so nothing is lost when they register.

Registration and login​

Getting a user registered and logged in as early as possible is critical: it unlocks notifications, which are your most important retention tool. See our User acquisition guide.

Applies only if you replace the platform registration popup with your own overlay

  • Disable the platform's automatic login reminders in your init options so users do not see two prompts. The option is named differently per engine.

Applies only if you customize the registration request message

  • Include the login code placeholder in the message. Without it the user's reply cannot be matched to their session.
  • Keep the message to 140 characters or fewer. The count includes the filled-in login code and the final period the platform adds unless you already end with ., !, or ?. showRegistrationOverlay() rejects anything longer, and emoji or other non-ASCII characters are stripped above 70.
  • Keep the message to one SMS. This check measures the text as the carrier sends it, where ^, {, }, \, [, ], ~, | and € each take two of the 160 characters a single message holds. The SDK counts them as one, so a message it accepts can still split in two and fail here - avoid them, or leave room for them.

Early funnel analytics​

This gives Jest visibility into a first-time user's experience of your app.

Notifications​

We ask that every app schedule a daily notification sequence as soon as the user is detected as registered. For detailed guidance, see the Notifications guide.

If your own backend schedules notifications through the Jest API rather than the SDK, turn on Notifications are sent server-to-server in the Simulator's Checklist tab. Every automated notification check on this page then stops applying, across all three tracks, and your declaration is recorded for the reviewer.

  • Schedule a D1-D7 sequence: at least one notification per day for the next seven days. The Simulator checks these seven days; a same-day D0 notification (scheduledInDays: 0) is recommended on top of them and does not count toward any of the seven.
  • Schedule that sequence as soon as the user is detected as logged in or registered.
note

Notifications scheduled for a guest are discarded by the platform. In the Simulator, trigger registration or login first to get the notification checks to go green.

In-app purchases​

Applies only if your app sells products.

Subscriptions​

Applies only if your app sells subscriptions.

Jest Fund requirements​

These are assessed only if you apply to the Jest Fund. Missing one will make you ineligible for the Fund, however your app can still pass review and be published on Jest.

Registration and login​

  • Registration prompts appear at contextually appropriate moments - after the tutorial, or every few levels, rather than on a timer. Reviewed manually

Notifications​

Notifications are one of the most powerful retention tools on Jest, so we ask Fund applicants to spend extra time on them. See our Notifications guide.

The automated checks here stop applying if you declare server-to-server notifications. The manual one still does.

  • Vary your notification copy, to avoid repetitive messaging. The check passes with at least two different bodies.
  • Every notification includes an image reference.
  • Every referenced image exists in your image library.
  • Every referenced image is approved.
  • Notification bodies are 100 characters or fewer, so the copy does not truncate.
  • Copy is compelling and tied to a callback mechanic - a reward, an emotional hook, a real in-app event, not a generic "we miss you". Reviewed manually

Monetization​

Fund applicants must have monetization enabled in some capacity. Apps without it can still launch on Jest, but cannot be accepted into the Fund.

  • Your app sells at least one product or subscription.
  • All purchase paths work end-to-end. Every path should complete and grant what it promised. Reviewed manually
  • Monetization is compelling and part of the core loop. Purchases should offer meaningful value and fit how the app is used, with a credible path to positive ROAS through Jest Ads. Reviewed manually

Social​

  • Screenshot capture works properly on all key screens. Most apps work with no code, since the SDK captures the main canvas automatically. If captures come out blank or wrong, HTML5 apps can register a screenshot provider to control what is captured. That override is not in the Unity SDK yet, so Unity apps depend on the automatic capture - check it on each key screen. Reviewed manually

None of these block a launch or a Fund application. We recommend them to every app because we believe they make for a better user experience, and passing them strengthens your Fund application.

User management​

  • Call getPlayerSigned() if your app has its own backend that owns identity or progress, so your server can verify who the user is.

Notifications​

Does not apply if you declare server-to-server notifications.

  • Reschedule notifications dynamically based on user progress, by scheduling again with an identifier you have already used.

Registration overlay​

Applies only if you replace the platform registration popup with your own overlay.

Social​

  • Implement an outside-network virality feature - encourage a user to invite someone who has not used the app before. This could involve a referral reward ("play through my link and we both get 100 gems") or a social mechanic like "join my squad" or "join my leaderboard" via a share link. In the Simulator, reach the point where the referrer taps the share link to open the share sheet to get this check to fire. See the Virality guide.
  • Pass shareImage to shareReferralLink() to personalize the referral preview instead of falling back to the generic one.
  • The virality feature works and gives a real reason to invite someone new. The invite should reward the referrer as advertised and give a genuine reason to bring in someone who has not used the app. Reviewed manually