APPSINITYDeveloper policy
Appsinity publishes on your declaration: that the listing describes the real software, that you have the right to distribute every file and asset in it, and that the contact details players need are accurate. This page states those obligations and what happens when a listing stops meeting them.
Open Appsinity StudioThe baseline every account carries
These come straight from the Terms of Use sections on eligibility, accounts and developer publishing, restated in the language Studio uses on screen.
- The account is owned by the person or organisation actually responsible for the software, and the credentials stay with them. Sharing a live session or an invited login is a violation even when the collaborator is trustworthy.
- All listing metadata is accurate and non-deceptive: title, descriptions, category, tags, icon, screenshots, feature graphic and trailer links.
- Screenshots and icons show real content from the build you distribute. A rendered mock-up is fine only if the shipped product actually looks like that.
- You are fully responsible for the files you distribute, including builds served from a third-party download host that you paste into the listing.
- Public safety and support details are real: the support email, the country, and the individual or company identity you declared during verification.
- Every asset, code and piece of content in the release is owned or properly licensed by you.
What has to stay true over time
| Listing field | What must be true | Who sees it |
|---|---|---|
| Title | The name players actually meet in the build; no competitor names, no version numbers, no keyword stuffing | Search results, listing header, library |
| Short description | A summary of the shipped product in 80 characters or fewer | Browse cards, category pages |
| Long description | Features, modes and limitations of the current build | Listing body |
| Screenshots | Captures of this listing's own build, not another game or a concept render | Gallery, search previews |
| Icon and feature graphic | Your own artwork or licensed artwork at the required size | Tiles, cards, social previews |
| Category and tags | Describes the game that is actually downloadable | Category pages, browse filters |
| Build or web URL | Serves the version the description promises, and nothing else | The download button |
| Data safety and privacy | Matches what the software really collects | The listing Data safety panel |
| Content rating | Matches the shipped content, declared through the rating form | The age badge on the listing |
| Support contact | A monitored address that reaches whoever can fix a report | Listing footer, tickets |
How a policy decision reaches your listing
A listing has one status field. Two of its values exist only because Appsinity set them, and both are policy outcomes. Everything else is yours to control.
| Status | Set by | Visible to players | What it means |
|---|---|---|---|
| draft | You | No | Being built; nothing published |
| unpublished | You | No | Taken down by you, listing data intact |
| published | You | Yes | Listed in the catalogue and downloadable |
| pre_register | You | Yes | Announced before release with a release date |
| closed_testing | You | Yes | Restricted test availability |
| suspended | Appsinity | No | Distribution stopped by an enforcement decision |
| banned | Appsinity | No | Removed for a serious or repeated violation |
How a violation gets noticed
Three paths reach a listing, and only one of them is automated.
- Automated safety scan. Uploaded builds are scanned for malicious file types and suspicious names before publication. See Malware policy for exactly what the scanner looks for.
- Player report or review. Reports and one-star reviews on safety, scam or copyright grounds are read by hand. Review text is also policed under the ratings rules.
- Manual review. A listing whose metadata, artwork or downloads look inconsistent with the build is reviewed directly.
What enforcement can look like
- The listing is restricted, delisted or removed, and can be done so without prior notice.
- Distribution of the affected build stops while the rest of the catalogue continues.
- Repeated, systematic or severe violations escalate to the account: temporary suspension, then permanent termination.
- Rights holders and regulators with a legally valid request are cooperated with.
- Payouts tied to the affected listing are reviewed before any outstanding balance is released.
Where Appsinity's role stops
Downloads are served from Appsinity servers once you submit a build, so the platform is part of the delivery chain, and it is also the party that scans. The Terms are explicit that scanning reduces risk without removing it: automated scanning cannot guarantee every risk will be detected, and developers bear full responsibility for the integrity, safety, legality and authenticity of the files they distribute.
Frequently asked questions
Do you review a listing before it goes live?
No human reads a listing before publication. The automated safety scan runs on uploads, publication is self-service through the checklist, and enforcement follows. That is why the obligations above are standing rather than one-time.
Will I be told before something is removed?
Not always. Listings that violate the content rules may be removed without prior notice. You can appeal any decision, see Appeals.
One of my team members broke a rule. Is my account liable?
Yes. Enforcement works at account level, which is why shared logins are prohibited and why each collaborator should get their own member with a scoped role, see Roles and permissions.
Can I publish a game I do not own?
No. A listing needs the right to distribute every asset and file in it. Licensing arrangements are your evidence to produce if a rights holder complains, see Copyright.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]