Vibeview
Pricing

Live Development

Run your React Native app on a VibeView device while you develop — edits on your machine hot-reload on the streamed device in about a second.

How it works

Running vibeview dev starts a device session and connects it to a Metro bundler, so the app on the device is talking directly to your local JavaScript. Save a file and Fast Refresh updates the running app live, the same as it would on a simulator running on your own machine. You only need to rebuild and re-upload a debug build when you add or change a native dependency — everyday JavaScript and asset changes never require a new upload.

vibeview dev can drive the whole loop for you: it can run your build command, upload the result, start Metro if it isn’t already running, and open the session — or you can build and upload manually and just point dev at an existing app. Both paths are covered below.

Requirements

  • The VibeView CLI, installed and logged in.
  • A React Native project with a way to produce a DEBUG build: an iOS simulator .app build or an Android debug .apk. The build must match VibeView’s device architecture — x86_64 for Android, arm64 simulator slice for iOS — see Preparing your build: Architecture if your project filters ABIs (common for TV-targeted apps). An Android build missing x86_64 will fail to install or crash on launch.
  • Metro (yarn start/npx expo start or equivalent) — vibeview dev can start this for you if you give it the command during setup.

Quick start

Run vibeview dev from your project root.

  1. First run in a project: vibeview dev walks you through setup — which platform to run, an optional build command (a detected default is offered for Expo and bare React Native projects), and an optional command that starts Metro. Any of these can be skipped; skipped ones can be added to vibeview.json later (the command prints the exact keys to add). Your answers are saved to a vibeview.json file in the project so later runs start immediately with no prompts.
  2. Getting an app to run: if you configured a build command and don’t have an uploaded app yet for this platform, vibeview dev builds and uploads one for you. If you already have an app, it asks whether to build a fresh one or reuse the existing upload. If you skipped the build prompt, it sends you to a picker over your already-uploaded apps.
  3. The session: VibeView starts a device session — starting Metro first if it configured a command and nothing is running on the port yet — and opens the session in your browser. Edit your code and watch the change appear on the device. Press Ctrl-C in your terminal to end the session (this also stops a Metro that vibeview dev started for you).

Day to day, once setup is done, it’s one command:

vibeview dev

Choices are remembered per platform: vibeview dev --platform tvos switches to your TV app (asking which app once, the first time), and a bare vibeview dev reruns whatever platform you used last — no config editing to switch.

After a native change, rebuild and upload before starting the session:

vibeview dev --build

For CI or a manual upload without starting a session, build and upload alone:

vibeview build

See CLI: dev and CLI: build for the full flag and config reference, including the vibeview.json schema.

Metro

If Metro is already running when you start a session, vibeview dev uses it as-is — it never touches a Metro it didn’t start. If nothing answers on the port and you configured a Metro command during setup, vibeview dev starts it (prefixing its output with [metro]) and stops it again when the session ends. If nothing is running and no Metro command is configured, the command stops with a clear message instead of opening a session your app can’t use. If Metro goes down mid-session, the terminal tells you too — start Metro in your project again, then reload the app in the session and it picks up right where you left off.

Building and uploading manually

If you’d rather run your own build tooling and skip the build-command prompts, that still works — upload a debug build with vibeview upload-app (see CLI: upload-app) and pick it from the picker on vibeview dev’s first run, or pass --app <id> directly:

vibeview upload-app ./build/MyApp.app
vibeview dev --platform ios --app <the-uploaded-app-id>

This is also the path for producing an iOS simulator build in CI — see Developing for iOS without a Mac below.

Debug builds

vibeview dev needs a debug build of your app — a build that can talk to a local Metro bundler. For Android that’s a debug .apk; for iOS it’s a simulator debug build. A release/production build won’t work with dev.

TV apps

vibeview dev also runs TV apps: use --platform tvos (Apple TV simulator) or --platform androidtv (Android TV emulator). The same debug-build rules apply — an Android TV debug .apk, or a tvOS simulator debug build.

VibeView recognizes debug builds automatically when you upload them, and vibeview dev always runs the latest debug build of the app you pick — so if you also upload release builds of the same app, they don’t interfere with your dev loop. If the app you select has no debug build, vibeview dev stops with a clear message and does not start a session; upload a debug build with vibeview upload-app and run it again.

If your build won’t install

If your debug build can’t be installed on the device (for example an Android build without an x86_64 architecture), vibeview dev stops the session and prints the install error instead of leaving you on an empty home screen. Rebuild with x86_64 included (reactNativeArchitectures=armeabi-v7a,arm64-v8a,x86_64 in android/gradle.properties) and upload the new build.

If the app you previously selected has been deleted, vibeview dev warns you and asks you to pick an app again. If you passed the deleted app’s id with --app, the command exits with an error telling you to run without --app to pick from the list.

Developing for iOS without a Mac

An iOS simulator debug build can be produced in CI (for example with EAS Build or a GitHub Actions runner) and uploaded straight to VibeView, so day to day JavaScript work never requires owning a Mac:

name: Build iOS simulator debug build

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install VibeView CLI
        run: npm install -g vibeview

      - name: Install dependencies
        run: npm install

      # Build an iOS *simulator* debug build. With EAS Build:
      - name: Build iOS simulator debug build
        run: eas build --platform ios --profile development-simulator --local --output ./build/MyApp.tar.gz
      # With a bare React Native project, use a Debug-configuration
      # `xcodebuild` for the Simulator destination instead.

      - name: Upload debug build to VibeView
        env:
          VIBEVIEW_API_TOKEN: ${{ secrets.VIBEVIEW_API_TOKEN }}
        run: vibeview upload-app ./build/MyApp.tar.gz

Once the build lands on VibeView, run vibeview dev --platform ios from Windows or Linux — the CLI only needs your local Metro bundler, not a simulator or a Mac. When a native dependency changes, rebuild through the same CI workflow and upload the new debug build; the day-to-day loop of editing JavaScript and seeing it hot-reload never needs a Mac.

Limitations

  • Only JavaScript and asset changes hot-reload. Adding or upgrading a native module requires rebuilding your debug build and uploading it again.
  • Live Development supports React Native today. For other frameworks, contact support@vibeview.io.
  • A live development session bills streaming minutes the same as any other VibeView session.