Build your mobile app on every GitHub pull request

A pull request for a mobile app usually ends in one of two places. Either a reviewer approves code they never ran, or someone checks out the branch, waits for a local build, and opens a simulator, which on the iOS half means owning a Mac. CI can make the build, but the build ends up as an artifact nobody opens.

The VibeView GitHub App makes the build on its own and puts it one click from the pull request, on a device that is already running.

What happens when you push

• A push to a branch you picked builds every project in the repository, one build per platform.
• A pull request opened from a branch of the same repository builds too, on every new commit. Draft pull requests included.
• Each project and platform gets a check on the commit, which moves from queued to building to its result. Details opens the build in VibeView.
• The pull request gets one comment: a small table with each platform’s status and a link to its build. When a build succeeds, the comment links Run on a simulator or Run on an emulator. The same comment is edited as builds finish and as you push again, so it never piles up.
• A new commit on the pull request cancels its older builds that are still running. Their checks say which commit superseded them. Pushes to a branch are never cancelled, because a build of main is a record of that commit.

The builds are the same ones vibeview build --cloud makes, so everything a cloud build supports works here: React Native and Expo, Flutter (FVM pins included), Capacitor and Ionic, Kotlin Multiplatform, and native Xcode or Gradle projects. A project picks its Xcode, Node.js major and Ruby the same way it does from the CLI.

Set it up

Start the install from VibeView rather than from GitHub, so the installation links to your organization. You need the Admin role in VibeView and to own the GitHub account you install it on.

Open the pull request’s build on a device

This is the step a build service on its own stops short of. Click Run on a simulator in the pull request comment, pick a device, and the exact commit opens on a cloud iPhone, Android phone, Apple TV or Android TV in your browser. Tap through the change, record a test against it, or share the device with someone who has no Mac and no checkout.

For a React Native or Expo app, which build that is matters. Without a preview profile, a React Native or Expo pull request build is a debug build that loads its JavaScript from Metro, and a pull request has no Metro running, so the comment shows Debug build, with a link explaining why, in place of a Run link. A preview build is the same app in Release with the JavaScript inside, and runs by itself. The repository’s Build profile setting is Automatic by default: pushes and pull requests build the preview profile when the project has one, and development otherwise. So once your vibeview.json has a preview profile, Run on a simulator opens a build that just works. To build a different profile, name it in Build profile. Flutter, Capacitor, Kotlin Multiplatform and native projects need nothing extra: their development builds already run by themselves.

{
  "platforms": {
    "android": {
      "build": {
        "profiles": {
          "development": {
            "command": "npm ci && cd android && ./gradlew assembleDebug",
            "artifact": "android/app/build/outputs/apk/debug/*.apk"
          },
          "preview": {
            "command": "npm ci && cd android && ./gradlew assembleRelease",
            "artifact": "android/app/build/outputs/apk/release/*.apk"
          }
        }
      }
    }
  }
}

The links only open for people signed in to your VibeView organization, even on a public repository, so a pull request comment never gives the public a way into your builds.

Signed releases from version tags

Turn on Version tags in the repository’s settings, and pushing a new tag that matches the pattern (v* by default) makes a production build of each project:

git tag v1.4.0
git push origin v1.4.0

The build uses the production profile in your vibeview.json, is signed with your app’s credential, and lands on the Builds page as an .ipa, .aab or .apk, labelled with the tag and ready to download or submit to TestFlight or Google Play. Its checks are named VibeView: iOS, production and so on, so they never get mixed up with the branch build of the same commit. To build something else from tags, set the repository’s Tag profile: preview, for example, makes an unsigned build anyone on your team can run. Pushes and pull requests never make a signed build.

The App doesn’t send the build to a store by itself. To send each version tag to TestFlight automatically, use a workflow: GitHub Actions to TestFlight, no Mac runner.

If a signed build’s app has no valid signing credential yet, nothing runs: the check says Signing isn’t set up and links to the Signing tab. Fix it, then use Re-run all checks on the tag’s commit.

Monorepos, skips and forks

• Monorepos. Add a row per project folder. With Only build changed projects on, a push or pull request builds only the projects whose folder it changed, and the others get a neutral “No changes in this project” check.
• Skipping a commit. Put [skip ci], [ci skip] or [vibeview skip] in the commit message. The checks say “Skipped by commit message”. Release tags ignore it: pushing a tag is the request.
• Forks. Pull requests from forks never build. VibeView doesn’t download, store or build anything from a fork.
• Required checks. To block a merge until a build succeeds, add its check to your branch protection rules on GitHub.

What it costs

A build from the GitHub App counts like any other cloud build: its minutes use your plan’s included build minutes for the month and then usage credit. See pricing. Only the branches and pull requests you turn on build, so pick Branches with care on a busy repository. When a build can’t start, for example because you are out of included build minutes and credit, its check says so with Action required and a link to the page that fixes it. A build is never skipped silently.

The GitHub App or a workflow?

Use the App when the build is what you want from CI: it is the shortest path from a push to a build you can open on a device. Use a workflow when the build is one step among others you own. A GitHub Actions or other CI workflow runs the same vibeview build --cloud as a step, and can then run your tagged test groups against the new build. On GitLab, Bitrise or CircleCI, the workflow is the way in.

Frequently asked questions

Can I build my iOS app on every pull request without a Mac?

Yes. The GitHub App builds the iOS half on VibeView’s macOS builders, and the pull request comment links the simulator build to a cloud iPhone you open in the browser. You need no Mac and no macOS runner.

Do pull requests from forks build?

No. VibeView ignores them completely and downloads nothing from a fork. Only pull requests opened from a branch of the same repository build.

Does the App see all my repositories?

No. On GitHub you choose Only select repositories, and VibeView can read only those. You can change the list later in the App’s settings on GitHub.

Can a version tag make a signed production build?

Yes, when Version tags is on for the repository. A new tag matching the pattern builds each project with its production profile and signs it with your app’s credential. Without a valid credential, the check says signing isn’t set up and nothing runs.

Does it work with GitLab or Bitbucket?

The App is GitHub.com only. On another CI, run vibeview build --cloud as a step: builds then carry their commit and branch too.