Documentation

Theme

Last updated: 2026-10-09

Private Testing is the first mode where the real packaging path runs end to end. You build an .ehpk with the CLI, upload it as a private build in the dev portal, and install it on your own glasses through the phone app. The result behaves much closer to a published app than the dev-server flow ever will - same install path, same manifest enforcement, same icon assets, same permission prompts.

A private build is launched from the phone app. The glasses menu lists Beta and published apps, so starting your app from the glasses alone takes a promotion to Beta. See Beta Testing.

There is no scripted install yet. Every iteration goes through the UI - upload, install, look. Budget around ten seconds per cycle.

See Test for how Private Testing compares to the simulator, local sideload, and beta builds.

The flow ​

bash
# 1. Build your production bundle
npm run build

# 2. Pack it into .ehpk
evenhub pack app.json dist -o myapp.ehpk

Then in the dev portal:

  1. Open hub.evenrealities.com/login and go to your project, Builds tab.
  2. Upload myapp.ehpk. It lands in the Private builds section with a grey Private tag.
  3. On your phone, open the Even Realities App and go to the Even Hub tab (Developer Mode).
  4. Me → Apps → Private builds lists your upload. Tap Install.

Steps 1 and 2 also run from a terminal, which is what a CI job uses:

bash
evenhub upload myapp.ehpk -m "What changed"

Steps 3 and 4 stay manual. See Builds.

Within a few seconds the build is on your glasses, and launching it from the phone app runs the real boot sequence.

→ Detail: Packaging & Deployment

What Private Testing covers ​

  • Full .ehpk packaging path. Manifest validation, icon checks, file inclusion / exclusion, all of it. If something is going to fail packaging at review time, it fails here first.
  • Real permission prompts. The phone app prompts for permissions exactly as it will for end users. Strings, ordering, denial paths - all real.
  • Real launch UX. The app boots from an installed package instead of a dev URL. The first-frame timing and the boot sequence are real.
  • Real install / uninstall flow. You see what your users see when they install, including any version-update behavior.

What Private Testing does not cover ​

  • No HMR. Every code change is a full build, re-upload, re-install. Slow loop.
  • No headless automation. There's no scripted install + run + assert path for private builds yet. Treat them as manual smoke tests, not regression harness.
  • Only partial lifecycle survival. Private builds survive backgrounding briefly but don't pass the 5-minute lock test the QA reviewer runs. For that gate, use Beta Testing.
  • No distribution to other testers. Private builds are tied to your account. To get a build onto a colleague's phone, use Beta Testing.
  • No glasses-menu entry. Every launch goes through the phone. The glasses menu lists Beta and published apps, so a build you want to start from the glasses alone has to be promoted to Beta first.

When to reach for Private Testing ​

  • You changed the app.json manifest and want to verify it validates.
  • You added or changed a permission and want to see the real prompt.
  • You added icon assets or screenshots and want to see how they render in the install list.
  • You want a smoke test that the packaged build boots before promoting to a beta.

Common failure modes ​

SymptomLikely causeFix
Upload rejected: "invalid manifest"app.json field missing or wrong shapeCheck the error detail, see App Submission & QA → Manifest
Upload rejected: "package_id taken"Someone already claimed itChange package_id to a unique reverse-DNS string you control
Install succeeds but glasses show black screenBridge call ran before waitForEvenAppBridge()Check src/main.ts - await the bridge before anything else
Permission prompt never appearsPermission declared in app.json but never invokedPermission prompts fire on first invocation, not at launch. Trigger the API path that needs the permission
App vanishes after lockBackgrounded WebView killedExpected. Use Beta Testing for lock-survival validation

When to graduate to Beta Testing ​

Move to Beta Testing when:

  • You are within a few iterations of submitting for review.
  • You need to validate the 5-minute locked-phone behavior.
  • You want a colleague to install the same build for review.
  • You want to launch the app from the glasses menu without reaching for the phone.
  • You want reviewer-parity environment - same install path, same lifecycle, same OS treatment as a published app.