5.4 KiB
Beta 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-04Beta Testing is the only mode that behaves identically to a Released app on a real user's phone. You pack the .ehpk exactly as you would for submission, push it to a Beta group containing yourself (and optionally teammates), and install it from the phone app's Beta tester section. The OS, the lifecycle, the lock-screen behavior, the system exit dialog - all of it matches what an end user (and a QA reviewer) sees.If you're heading into review, this is the gate. Skip it and you'll fail.See Test for how Beta Testing compares to the simulator, local sideload, and private builds.
The flow
bash
# 1. Build and pack
npm run build
evenhub pack app.json dist -o myapp.ehpk
Then in the dev portal:
- Open hub.evenrealities.com/login, go to your project.
- Beta groups tab - create a group (e.g., self-test) and add your own account email. Add teammates' emails if you want them to test the same build.
- Builds tab - upload myapp.ehpk.
- Push the build to your self-test group.On your phone (and any teammate's phone):
- Open the Even Realities App.
- Me → Beta tester lists the build.
- Tap Install.From here on, the build behaves exactly as if it were Released. Launch from glasses home, full OS lifecycle, real backgrounding.
What only Beta Testing validates
The things you can't test anywhere else:
The 5-minute locked-phone test
Open your app, put it in a steady state (something visible on glasses), lock the phone, wait 5 minutes, unlock. The app should still be where you left it. This is the exact test the QA reviewer runs. Private builds survive briefly but not 5 minutes; Local Testing dies the second the phone locks.
shutDownPageContainer(1) system exit dialog
The system exit-confirmation dialog only renders for a real install. Root-page double-tap must call bridge.shutDownPageContainer(1). Apps using 0 (immediate exit) or a custom in-app exit UI on the root page are auto-rejected at review.
Real permission denial paths
What does your app do when the user denies a permission? Beta Testing is where you actually exercise that branch. Local Testing skips some prompts; Private Testing fires them but the reviewer's denial path is a Beta-equivalent install.
What still requires care
- Console logs are visible in the phone app's Developer Mode console. Handy for debugging, but don't log secrets - that install path is reviewer-visible too.
- Crashes don't auto-report in beta yet. If your app vanishes, the console buffer is your only signal - check it immediately.
- Beta install is a real install. localStorage, IndexedDB, everything persists exactly as it would for an end user. Reset between test rounds when you need a clean state.
The pre-submission checklist
Walk through each of these on the beta build before promoting to Submitted: | | | # | Check | Pass criteria | | 1 | 5-minute locked-phone test | Open the app, lock the phone for 5 minutes, unlock - state preserved, no spinner, no black screen. | | 2 | Root double-tap fires the system exit dialog | Visible confirmation; WebView closes on confirm. | | 3 | Permission denial paths handled | Deny each declared permission once - app degrades gracefully or surfaces a clear next-step message. | | 4 | Re-launch a first-party app (Conversate, Navigate) after exit | Launches cleanly without restarting glasses. | | 5 | No console errors at boot | Console buffer is clean immediately after launch.The full reviewer rubric: App Submission & QA Guidelines.
Common failure modes
| | | Symptom | Likely cause | Fix | | Beta tester section doesn't list the build | Account not in the group, or build not pushed to group | Re-check the portal: group membership + build assignment | | Install succeeds, app vanishes on lock | Backgrounding kills the WebView, no resume handler | Background & Lifecycle - persist eagerly to localStorage and rebuild on relaunch | | Double-tap exits silently | shutDownPageContainer(0) or no exit handler | Use shutDownPageContainer(1) on the root page | | Permission prompt copy is wrong | Edit app.json permission desc, repack, re-upload | Old beta still has old copy until reinstalled | | Build updates don't propagate | Higher min_sdk_version than tester's firmware | Tester needs firmware update first, or you need to lower min_sdk_version
When you're done
The .ehpk that passed every box above is the one you submit. Move the build from Test to Submitted in the portal. The reviewer installs from your beta build's lineage - if your beta passes the 5-minute test, the reviewer almost certainly will too.→ Next: App Submission & QA Guidelines
Related
- Packaging & Deployment - the build path
- App Submission & QA Guidelines - the reviewer rubric
- Background & Lifecycle - what survives the 5-minute lockPagerPrevious pagePrivate TestingNext pageShip