APPSINITYSigning and releases
Release management
Appsinity gives you one switch — the publishing status — and a live catalogue that changes when you save. Release discipline therefore has to live on your side.
Open Appsinity StudioOn this pageWhat the platform providesVersioning that works hereA defensible release processWhen a release is wrongFrequently asked questions
What the platform provides
Every one of the "No" rows has to be handled by your own process. That is not a criticism of the platform; it is the reason this page exists.
| Control | Exists? |
|---|---|
| Publish / unpublish | Yes — the status field |
| Pre-registration with a target date | Yes |
| A closed-testing status plus a link | Yes |
| Release tracks (internal, beta, production) | No |
| Percentage rollout | No |
| Review states or a submission queue | No |
| Server-side rollback | No |
| Release notes shown to users | No |
| Automatic update to installed copies | No |
Versioning that works here
- Increment the manifest version code monotonically for Android. It is the only version the store respects.
- Keep a human version — SemVer or date-based — inside your own release notes and in the description if it matters to players.
- Record which object key each release produced. The store path already contains a version segment, so write down
games/{id}/builds/{version}/{file}per release. - Never ship a build whose displayed version differs from its manifest. The Last updated row is the only release signal on the listing.
Watch out: Two builds with the same manifest code can sit in storage under different paths, and the store will happily serve either. The listing's download chain decides. Keep the chain pointed at the release you intend.
A defensible release process
- Freeze. Build the candidate from a tagged commit and keep the artefact; the store is not your archive.
- Install over the live version. This is the only real test of upgrade safety, and nothing on Appsinity does it for you.
- Publish to a hidden state first. Set
closed_testingand send the link to a handful of people. It is the closest thing to staging. - Flip to
published. Then immediately load the listing in a private window and download the file once. - Watch the first 24 hours. Visits with no installs means the listing changed meaning; installs with no opens means the build is broken.
- Read reviews. The review stream is the fastest regression signal available.
When a release is wrong
- Unpublish. Set
unpublished. That stops new installs within the catalog's next fetch — the fastest kill switch you have. - Repoint. Save the build section against the previous known-good URL.
- Republish. Set
publishedagain. - Tell people. Installed copies are not updated and cannot be notified. A review reply is the only channel to players who already downloaded.
Frequently asked questions
Is there an approval step?
No. The status field takes effect on save, so a mistaken release is instantly public.
Can I schedule a release?
Only through pre-registration, and autoPublishAt is a hint you should verify rather than a guarantee.
How do I announce a release?
There is no changelog field shown to users. Update the description, answer reviews, and use your own channels.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]