Skip to main content
Revyl uses a two-tier system for organizing your mobile applications: Main Builds (build aliases) and Versions. Understanding this structure helps you manage multiple releases efficiently.

​
Build Structure

Build (Alias)
├── Version 1.0.0
├── Version 1.1.0
├── Version 2.0.0 (Latest)
└── Version 2.1-beta

​
What is a Main Build?

A main build (or build alias) is a named container that groups all versions of a specific application variant. It’s not a file itself-it’s an organizational label.

​
Examples of Build Aliases

  • Android Production - Your production Android app
  • iOS Staging - Your staging iOS environment
  • Android Debug - Development builds
  • iOS Beta - Beta testing releases

​
When to Create a New Build

Create a new main build when:
  • ✅ Testing a different app variant (production vs staging)
  • ✅ Managing separate iOS and Android apps
  • ✅ Handling different app flavors (customer-specific builds)
  • ✅ Organizing beta vs production releases
Don’t create a new build for:
  • ❌ Minor version updates
  • ❌ Bug fixes
  • ❌ Feature updates to the same app

​
What is a Version?

A version is an actual uploaded build file representing a specific release of your app. Each version contains:
  • The compiled app bundle (.app for iOS, .apk for Android)
  • A version identifier (e.g., “1.0.0”, “2.1-beta”)
  • Package name/bundle identifier
  • Upload timestamp

​
Version Naming

Best practices for version names: Semantic Versioning (Recommended) 
1.0.0 - Major.Minor.Patch
2.1.3 - Version 2, feature 1, bugfix 3
Custom Labels 
v2.1-beta - Beta releases
2024.01.15 - Date-based versions
sprint-42 - Sprint-based naming

​
The “Latest” Badge

The most recently uploaded version automatically receives the Latest badge. This helps you quickly identify the current version when creating tests.

​
Practical Example

Let’s say you have an e-commerce app:

​
Setup 1: Separate Build Aliases

Build: "Shopping App - Production"
├── Version 1.0.0 (Initial release)
├── Version 1.1.0 (Added wishlists)
└── Version 1.2.0 (Latest) (Cart improvements)

Build: "Shopping App - Staging"
├── Version 2.0.0-rc1
└── Version 2.0.0-rc2 (Latest)

​
Setup 2: Single Build with All Versions

Build: "Shopping App"
├── Version 1.0.0-prod
├── Version 1.1.0-prod
├── Version 1.2.0-prod
├── Version 2.0.0-staging-rc1
└── Version 2.0.0-staging-rc2 (Latest)
Both approaches work-choose based on your team’s workflow.

​
Using Builds in Tests

When creating a test, you select:
  1. The build alias (e.g., “Android Test App”)
  2. The specific version (e.g., “1.0.0” or “Latest”)
Build selection in test creation Tests can target:
  • A specific version (e.g., always test version 1.0.0)
  • The latest version (automatically use the newest upload)

​
Version History

All versions remain accessible unless explicitly deleted. This allows you to:
  • Test against older releases
  • Compare behavior across versions
  • Reproduce bugs from specific builds
  • Maintain test compatibility

​
Managing Versions

​
Uploading a New Version

  1. Navigate to the build in the Builds page
  2. Click Add new version
  3. Enter the version identifier
  4. Upload the build file
The new version becomes the “Latest” automatically.

​
Deleting Old Versions

To delete a version:
  1. Click the menu (⋮) next to the version
  2. Select Delete
  3. Confirm deletion
⚠️ Warning: Deleting a version cannot be undone. Tests using that specific version will fail.

​
CI/CD Integration

When integrating with CI/CD pipelines:
  • The build alias stays constant
  • Each CI run uploads a new version
  • Version names can be auto-generated from:
    • Git commit hash
    • Build number
    • Branch name + timestamp
See CI/CD Integration for automation details.

​
Next Steps

Need help? Contact [email protected]