Releasing updates

After the first release is created, “Release application” changes to “Release update”.

When you need a new version

Create an update when the app's native components change:

• the main icon;
• camera, location, or microphone permissions and their system permission prompts;
• the mobile shell's behavior or a new native feature;
• package name, bundle identifier, signing, or supported platforms;
• app libraries or an Apple or Google build requirement.

Changes to the name, description, and screenshots are reviewed by the stores. Submit them through an update request if they should go live with the new version.

Without a new version

Website changes usually do not require a new build, including products, prices, pages, server logic, and the mobile layout. Bottom menu URLs, shell colors, additional CSS and JavaScript, and other settings the app receives from the server may also apply without a release.

Save the setting, fully restart the app, and check the result on a device. If the change does not appear or affects the app's purpose, data processing, or payments, ask SiteCargo whether store review is needed.

Request an update

1. Save the changes in the builder and on the “Distribution” tab.
2. Fill in “What's new” with a brief description of changes for users.
3. Click “Release update” and confirm submission.
4. Wait for notification that the release was created.

The publication option stays the same, and no new initial setup invoice is created. Public App Store and Google Play links carry over to the new release; TestFlight and APK links apply only to a specific build.

Version

Each successful request increments the minor version:

Last release	New request
1.0	1.1
2.4	2.5
1.2.4	1.3.0

If the saved version has an unknown format, 1.1 is used. The technical build number may change during fixes without changing the user-facing version.

Multiple requests in succession

SiteCargo allows you to create an update while the previous release is still in progress. Each request receives the next version, but app settings are not saved as a separate copy for each release: the team sees their latest saved state.

Create a parallel request only for a separate set of changes, and explain the differences by replying to the email. Clicking again for the same task creates an unnecessary release.

See Update status and history for the current stage and version.