V
Vibeview
Pricing
Sign In

Apps

The Apps page is where you manage the applications you want to test on VibeView’s cloud simulators. You can upload iOS and Android apps, organize builds by version, and link test suites to each app.

Apps List

The main Apps page displays all applications uploaded to your organization. Each entry shows the app name, platform (iOS, tvOS, Android, or Android TV), package name, and when the app was last used.

Use the platform filter at the top of the list to narrow results to a single platform. This is helpful when your organization works across several platforms and the list grows large.

Uploading an App

To upload a new app, click the upload button on the Apps page. The same upload modal is used everywhere you add a build in VibeView (the Apps list, the app detail page, and anywhere else upload is offered) so the flow is identical across entry points.

VibeView supports the following formats:

  • iOS and tvOS: .app bundles, bare or compressed (.zip, .tar.gz, or .tgz)
  • Android and Android TV: .apk or .apks packages

Uploads are limited to 500 MB per file. Files are validated on the server using magic byte checks to confirm the file matches the declared format, so renaming a file extension will not bypass validation.

After selecting a file, the modal also shows a Note (optional) textarea before you submit. See Build notes below.

After uploading, the app appears in the list and the first build is created automatically.

App Detail Page

Click any app in the list to open its detail page. From here you can:

  • View all builds (versions) for the app
  • Upload additional builds
  • Manage test suites attached to the app

Build History

Each app can have multiple builds. The Build History table lists them sorted by upload date, with the most recent build shown first. Every build displays the following metadata:

  • Version — the app’s version string (e.g., 1.2.0)
  • Build # — the internal build identifier
  • Size — size of the uploaded file
  • Tags — any tags attached to the build
  • Note — the optional note entered at upload time (see below)
  • Uploaded — when the build was added
  • Uploaded By — who added the build
  • Source — shows a CI badge for builds uploaded from a CI pipeline

To add a new build, use the upload control on the app detail page. The same format and size restrictions apply as when uploading a new app.

Build notes

Each build carries an optional note. Enter it in the Note (optional) textarea of the upload modal after you select a file. Short, specific notes are the most useful — they surface alongside the version in the Build History table and on test run detail pages so you can tell builds apart at a glance.

You can also edit a note after upload. On the app detail page, click the Note cell on any row in the Build History table to edit in place. Press Enter or click away to save; press Esc to cancel. Clearing the field and saving removes the note. Editing requires the Developer or Admin role; viewers see notes read-only.

Examples of useful notes:

  • Fix login crash — hotfix for ticket #1234
  • Pre-release with feature flag X enabled
  • Reverted notifications refactor

Notes are shown in the Note column of the app’s Build History table (truncated with hover preview) and, when a build is used in a test run, surfaced as hover text on the Build pill on the run detail page.

Run the sandbox against a specific build

Each row in the Build History table has a Play icon labelled Run with this build. Clicking it opens the Device Sandbox with the chosen build pre-selected for install.

The sandbox records the pinned build in the URL as a buildId query parameter, so you can link directly to “start a sandbox session against this exact build”:

/sandbox?appId=<app-public-id>&buildId=<build-id>

<build-id> is the numeric AppBuild id (integer). If the parameter is omitted, the sandbox defaults to the app’s latest build.

Test Suites

Test suites are attached at the app level. The app detail page lists all suites for the app — click a suite row to open its detail page at /tests/:suiteId, where you can view cases (Cases tab), analytics, and run history. You can also create, edit, and manage suites from the Tests sidebar entry.

Deleting an App

Deleting an app removes the app record and all of its builds permanently. This action cannot be undone, and a confirmation dialog always appears before anything is deleted. Test suites attached to the app are not deleted — they are detached from the app and remain available.

Tips

  • Upload a new build each time you cut a release so you can run tests against any version.
  • Use the Note field to label milestones like release candidate or regression baseline so they’re easy to spot in the Build History table.
  • Keep one app entry per product rather than creating separate entries for each version — the Build History table handles versioning for you.
  • If an upload fails validation, double-check that the file is a genuine .app (or .zip/.tar.gz/.tgz archive) or .apk/.apks package and is under the 500 MB limit.