APPSINITYBest practices
Everything that goes wrong on Appsinity traces back to the same three habits: publishing a partial listing, shipping an unversioned build, and letting a declaration drift from the software. This page is the operating discipline that avoids all three.
Open Appsinity StudioThe order that works
- Create the listing first, publish last. A draft row can hold every field. Do not open a listing to players until the checklist section for it reports done.
- Name and slug before artwork. The slug becomes the object-key prefix and the URL. Changing it later breaks every link you already shared.
- Write the descriptions, then the artwork. Screenshots should illustrate the text. Doing artwork first is how you end up selling a game you did not describe.
- Upload a build, then sign it, then test the URL. Confirm the public URL resolves with
/public/in the path before you point the listing at it. - Complete privacy and content rating. Both have hard completion rules and both are visible on the listing, see Data safety and Content ratings.
- Publish, then read your own page as a player. Open the live listing in a private window and check the badge, the gallery and the download button.
What completeness means
Studio computes section completion from the fields that exist, and the store section is only done when every one of them is present. A missing field is not a soft warning; it holds the section at incomplete.
| Section | Fields required for done | Common gap |
|---|---|---|
| Store | name, description, icon or logo, feature graphic, at least one screenshot | No feature graphic |
| Privacy | submitted, a policy URL, and both attestations ticked | One unticked attestation |
| Contact | a monitored support email | An address nobody reads |
| Build | an uploaded object and a resolvable URL | URL missing the bucket segment |
| Rating | a submitted content declaration | Left at nothing ticked, which displays 3+ |
Version deliberately
- Every upload takes a version segment in its object key. If you omit one, the platform uses a timestamp, so two uploads of the same file become two build directories.
- For Android, the version name and version code are read from the binary by the extract step; treat them as the source of truth rather than retyping them.
- Publish AAB where you can, APK where you must, and keep the pair consistent for one version, see APK vs AAB.
- Never reuse a version number for different bytes. Players on the old one cannot tell what they got.
- Windows releases ship as a ZIP; name the archive with the version inside it, not just in the path.
Metadata discipline
| Practice | Why it pays |
|---|---|
| One specific title, no keyword list | Search ranks relevance; a stuffed title reads as spam |
| Short description inside 80 characters | It truncates in cards rather than in your head |
| Screenshots in the order a player experiences the game | The first image is the ad |
| Category that matches the loop, not the aspiration | Wrong category means wrong audience and bad reviews |
| Long description with a known-issues line | Honesty about limits deflects the one-star complaint |
| Update the description with the build | Drift is a policy violation, not a typo |
| Keep the support email human | It is the only channel a safety report reaches you on |
Measure what exists
You get lifetime totals, top sources and top countries. There is no time series and no export, so keep your own record if you want a trend.
// a daily snapshot is the whole workaround
curl -4 -s -H "Authorization: Bearer $TOKEN" \
'https://api.appsinity.com/api/listing-analytics?collection=games&listingId=my-game' \
| jq '{d:.downloads, v:.visits, r:.reviewsSummary.ratingAvg, n:.reviewsSummary.ratingCount}' \
>> history.jsonlAnti-patterns
- Publishing the same game twice to own two slots in a category.
- Retitling a live listing every week to chase a search term.
- Pasting a token into a script and committing it.
- Shipping a web build that contains an API key.
- Advising players to buy elsewhere while the listing says free.
- Leaving a pre-registration row published after launch day.
- Treating the automated scan as an approval, see Malware policy.
Frequently asked questions
Should I publish before the checklist is complete?
You can, and you should not. Status is a switch you control, so there is no reason to expose a listing with no privacy section or no feature graphic.
Do I need an AAB and an APK?
One Android artefact per version is enough. Pick by how players install: an APK is directly installable, an AAB needs the extraction path, see App bundle (AAB).
How often should I update the listing?
Whenever the product changes materially. Metadata drift is the violation; frequent honest updates are not penalised.
Can I schedule a release?
There is no scheduler. Publish manually, or use pre-registration to announce a date in advance.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]