OtaKitTurn every pull request into an installable Capacitor preview
Give reviewers a real device build for every pull request. How to publish per-PR preview channels so testers install the exact change on their phone before it merges, with OtaKit and CI.
Web teams get preview URLs for every pull request — a reviewer clicks a link and sees the change live. Mobile teams usually don't, so review happens against a diff or a description instead of the actual running app. With update channels you can give every PR an installable preview on a real device, and it's simpler than it sounds. This guide shows how with OtaKit and CI.
The trick: a channel per PR. Testers install one preview build of your app once, then each PR publishes its web bundle to its own channel — switch channel, see that PR's change on your phone. No per-PR native build.
1. A reusable preview binary
Ship your testers a single “preview” build of the app — internal distribution via TestFlight or Firebase App Distribution. It follows whatever channel you point it at, so you build it once and reuse it across every PR.
2. Publish each PR to its own channel
In your CI workflow, on every pull request, build the web app and release it to a channel named for the PR:
# in the PR workflow
npm run build
otakit upload --release "pr-${PR_NUMBER}"Now there's a live channel carrying exactly that PR's code. See CI automation for wiring it into your pipeline.
3. Reviewers switch to the PR channel
In the preview build, expose a way to enter a channel name (a debug screen). A reviewer types pr-123, the app switches, and they're running that PR:
import { OtaKit } from '@otakit/capacitor-plugin';
await OtaKit.setChannel({ channel: 'pr-123' });See targeting users with channels for the switching mechanics.
4. Clean up merged PRs
When a PR merges or closes, delete its channel/release so old previews don't pile up. A otakit delete step in the close workflow keeps things tidy.
This changes review culture: instead of “looks good in the diff,” reviewers actually use the change on a device before approving. Bugs that only show up on real hardware get caught before merge, not after release.
Where to go next
See staging environments for the broader channel model and Channels & runtime version for the details.