APPSINITYPublish an update
An update on Appsinity is a new upload plus a saved listing. There is no submission, no review state and no staged rollout — the change is live when the record saves.
Open Appsinity StudioThe update sequence
- Bump the manifest version code. Studio has no version field, so the number inside the package is the only one that exists.
- Upload the new build. It lands in a fresh
…/builds/{version}/…path. It does not overwrite the previous file. - Sign it. Android builds need a fresh signature:
POST /api/apps/:appId/builds/sign, or simply let the background signer pick it up. - Repoint the listing. Save the build section so the download chain resolves to the new URL. Until you do, players still receive the old file.
- Verify in a private window. Load the listing, check the Size and Last updated rows, and download it once.
What changes for players
So an update is only delivered to someone who downloads again. Say so in the listing text if the fix matters: "re-download to get version 1.2" is the honest instruction.
| Signal | Behaviour |
|---|---|
| Last updated meta row | Updates from the record |
| Installed copies | Nothing. There is no auto-update and no in-app updater |
| Desktop client library | No update check; the installed folder is not re-validated |
| Licence-protected titles | The licence is unchanged; a new download issues a new ticket |
| Reviews | Old reviews stay attached to the listing |
Breaking changes
- A different signing key makes the update uninstallable over the old one. On Appsinity the key is constant, so this is only a risk if a previous copy came from elsewhere.
- Save-data format changes need a migration inside the build; nothing on the store side helps you.
- Deleting the app to replace it destroys reviews and traffic history. Never do it to change a slug — see Visibility and status.
Rolling back
There is no rollback control. The previous object still exists in storage, so reverting means repointing the listing at the earlier URL. Keep your own copy of every released build; the store is not your artifact archive.
closed_testing with a hand-out link if you need a real staging step.Frequently asked questions
Is there a staged rollout?
No. Rollout and updates documents the workaround.
Can I keep two versions live?
One URL per listing resolves at a time. Two versions means two listings, which is not something the store encourages.
How long does signing take?
A synchronous call for one build — seconds for a normal APK — plus a 30-second rescan loop for anything that was missed. See App signing.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]