Private Testing | Documentation
    
    
    
- 
    
- 
    
    
    
- 
    
- 
    
- 
    
- 
    
    
  
  
    Skip to contentDocumentationSearch⌘CtrlK Main Navigation PortalThemeMenuReturn to top Sidebar Navigation 
## Get Started
Overview
### Quickstart
Sign inHardwareInstall Node.js & npmInstall Even Hub toolingYour First AppTemplatesArchitecture
## Build
Page LifecycleDisplay & UI SystemUI/UX Design GuidelinesDevice APIsContextual MenuNetworkingBackground & Lifecycle
## Test
SimulatorLocal TestingPrivate TestingBeta Testing
## Ship
Packaging & DeploymentApp Submission & QA Guidelines
## Reference
GlossaryCLIVersioning PolicyChangelogFAQ
## AI Tooling
Claude CodeOn this pageLast updated: 2026-06-04Private 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 Released app than the dev-server flow ever will - same install path, same manifest enforcement, same icon assets, same permission prompts.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:
- Open hub.evenrealities.com/login, go to your project, Private builds tab.
- Upload myapp.ehpk.
- On your phone, open the Even Realities App and go to the Even Hub tab (Developer Mode).
- Me → Apps → Private builds lists your upload. Tap Install.Within a few seconds the build is on your glasses. Launch it from the glasses home, the same way a Released app launches.→ 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. Glasses launch the app from the home menu, not from 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.
## 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 ​
 | 
|  | Symptom | Likely cause | Fix
|  | Upload rejected: "invalid manifest" | app.json field missing or wrong shape | Check the error detail, see App Submission & QA → Manifest
|  | Upload rejected: "package_id taken" | Someone already claimed it | Change package_id to a unique reverse-DNS string you control
|  | Install succeeds but glasses show black screen | Bridge call ran before waitForEvenAppBridge() | Check src/main.ts - await the bridge before anything else
|  | Permission prompt never appears | Permission declared in app.json but never invoked | Permission prompts fire on first invocation, not at launch. Trigger the API path that needs the permission
|  | App vanishes after lock | Backgrounded WebView killed | Expected. 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 reviewer-parity environment - same install path, same lifecycle, same OS treatment as a Released app.
## Related ​

- Packaging & Deployment - the .ehpk build and manifest schema
- App Submission & QA Guidelines - what reviewers check
- Beta Testing - the next mode up
- Background & Lifecycle - why lock survival is only partial herePagerPrevious pageLocal TestingNext pageBeta Testing