Version Management
Manage app builds in Dashboard V2 and understand shared account storage, over-quota policies, and historical-build cleanup.
Select an app and choose Versions in the top navigation to manage its retained builds. Some bulk actions and scheduled publishing options depend on the account plan and permissions.
As of September 18, 2026, storage is managed by account capacity, and the previous automatic cleanup based on build counts per app is paused. Since October 15, 2026, storage overage is handled by the policies below. Historical builds removed by automatic cleanup disappear from the build list, their download links stop working, and they cannot be recovered. Back up installers you still need in advance.
Account Storage and Usage
Apps and historical builds under the same main account share storage capacity. Uploads by sub-accounts count toward the main account. Overage is no longer determined by a separate build count for each app. Common base allowances are:
| Account status | Base storage |
|---|---|
| Identity verification incomplete, or a verified individual without an active paid plan | 20 GiB |
| Verified company without an active paid plan | 30 GiB |
| Verified account with an active ordinary paid plan | 50 GiB |
Usage is based on installer storage, with 1 GiB = 1024 MiB. Plans, purchased storage packages, and account-specific benefits can affect the total allowance. Check Account menu → Usage for your actual total and used space. Verification requirements, daily publishing limits, and other upload rules still apply separately.
Usage shows the space occupied by latest and historical builds and a per-app breakdown, with actions for manual cleanup. Choose Add Storage to buy a storage package. See Account Center for instructions and Pricing Overview for package prices.
Over-Quota Policies
The main account can choose a policy under Usage → Over-Quota Handling. Accounts that have not changed their policy use the first option by default, without having to save it first. After changing an option, choose Save Policy.
| Policy | Behavior |
|---|---|
| Clean historical builds of the current app first, then other apps if needed (default) | Start with eligible older historical builds of the app being uploaded; if the account is still over quota, continue with eligible historical builds of other apps in upload order, oldest first |
| Clean historical builds of the current app only | Clean eligible history only in the app being uploaded; if still over quota, manually free space or add storage |
| Block new uploads; I will clean up manually | Do not perform automatic capacity cleanup; free space or add storage before uploading again |
Automatic cleanup removes eligible historical builds, not entire apps. Capacity cleanup protects the system's latest builds, current public builds, channel-referenced builds, and other protected versions. Not every historical build is eligible.
How Uploads Are Checked
Uploads are checked as follows:
- Usage is below or exactly at the allowance when uploading starts: the upload is allowed without reserving space for the incoming installer. If successful publication creates an overage, the account policy applies. With manual cleanup selected, this publication can complete, while later new uploads are affected.
- Usage is already over the allowance: an automatic policy first attempts to clear the existing overage. Uploading can continue once usage is back within the allowance. If eligible history is insufficient, a storage error is still returned. A manual policy asks you to resolve the overage first.
- A legacy client or API has not identified the target app yet: the installer may be received before its app is identified and the capacity check and cleanup run. A completed file transfer is not a successful publication; check the final publishing result.
Automatic policies keep attempting cleanup until usage is within the allowance or no eligible builds remain. Large cleanups can take multiple batches. If the page or API reports that cleanup is in progress, retry later. Selecting automatic cleanup does not guarantee every upload will succeed.
When a website upload cannot continue, the page explains the reason and next action. The API returns a failure result and error message; callers should check code, message, and the final publishing status. Sub-account users should contact the main account administrator to free space or add storage.
Capacity cleanup follows the account policy without asking for confirmation on each upload. Keep your own backups of installers needed for long-term archives. Deleted historical builds cannot be recovered.
Latest and Historical Builds
For an app hosted normally, the system's latest build is retained long term and is not automatically removed for capacity overage or download inactivity. After a newer build is published, the previous latest build becomes historical; its eligibility for cleanup also depends on its state and references. Latest-build protection does not cover apps or builds you delete, or an app being blocked.
Download validity and build retention are separate. An unrestricted download date setting does not mean every historical installer is stored permanently. Platform expiration and manual renewal have been retired. See App Validity and Download Availability for other download restrictions.
Long-Inactive Historical Builds
Cleanup of long-inactive historical builds operates independently of capacity-overage handling. Accounts with an active paid storage package are exempt from the 90-day download-inactivity cleanup rule while the package remains valid. This exemption does not apply to capacity-overage cleanup or cleanup initiated by the user.
A non-latest build not covered by this exemption may enter cleanup if no download URL has been generated for 90 consecutive days; if no URL has ever been generated, time is measured from upload creation. URL generation is an activity indicator, not proof of a complete installer download.
If a build enters a grace period, use its Grace until date in Dashboard Versions and its in-app notice to plan backups. After the deadline, the system checks eligibility again; qualifying builds move to Pending cleanup and are processed in batches. Notices may be grouped by account. Not receiving or reading a notice does not automatically extend the deadline.
Filters and Bulk Actions
Filter the list by All, Shown, or Hidden. After selecting builds, available actions may include:
- Show, hide, or delete one or more builds in bulk;
- Set a build as current when exactly one build is selected;
- Set builds to the Dev or Pro environment when the account has that capability.
Per-Build Actions
| Action | Purpose |
|---|---|
| Edit | Change release notes and other editable information |
| Publish | Publish now, or schedule publication when the account supports it |
| Show/Hide | Control whether the build appears on the install page |
| Set Current | Make the build the app's current public version |
| Set Dev/Pro | Change the build environment when the capability is enabled |
| QR Code and URL | Get an install entry for that build |
| Download | Download the uploaded installer |
| Certificate | Inspect signing and device information for the installer |
| Delete | Permanently remove the build and installer |
Exactly one build must be selected when setting the current build. Deleted builds cannot be recovered. Before bulk deletion, keep at least one build required by the business and check whether external channels still point to a selected build.
Channels can contain multiple builds in their own order. After publishing or deleting a build, also check the build list in Distribution Channels.