What “standalone Quest” means
A standalone Quest build runs on the headset itself. That means the runtime cannot assume Windows, desktop LWJGL natives, SteamVR or a desktop Vivecraft installer. The launcher has to assemble Android-compatible Java, ARM64 native libraries, a mobile renderer, OpenXR integration, controller bindings and the Minecraft/loader/Vivecraft combination for that exact game version.
The runtime stack
| Layer | Purpose |
|---|---|
| Minecraft | The selected Java Edition client and its assets/libraries. |
| Loader | Vanilla, Fabric, Quilt, Forge or NeoForge when that combination genuinely exists. |
| Java | An Android ARM64 Java runtime appropriate for the selected Minecraft generation. |
| Renderer | Mobile rendering compatibility between desktop-oriented game graphics calls and the headset platform. |
| VR gameplay layer | Version-aware Vivecraft-compatible code and dependencies. |
| OpenXR | The headset VR API and bridge used for standalone Quest rendering/input. |
| Controllers | Quest-friendly actions, ray interaction and in-game bindings. |
Compatibility labels matter
SPUDZWARE deliberately separates different levels of proof. Experimental can mean a complete profile exists and host/static validation passes, but physical Quest gameplay has not been proven yet. Pending means SPUDZWARE is still missing a required implementation or component. Broken means an implementation exists but a known failure prevents it from being considered ready. Verified should be reserved for a physical Quest reaching usable VR gameplay.
This distinction matters because a successful metadata resolution or APK build does not prove that Android Java started, Minecraft reached the title screen, OpenXR initialized or the controllers worked in gameplay.
Targeted Minecraft generations
The current SPUDZWARE VR work is focused on a defined target range instead of every historical Minecraft release: 26.3, 26.2, 26.1.2, 1.21.11, 1.21.10, 1.21.9, 1.21.8, 1.21.1, 1.20.1 and 1.19.2. Each version is evaluated against the loader families independently; a loader missing on one version does not disable it everywhere.
Loader releases, Java generations, native requirements and Vivecraft compatibility change over time. SPUDZWARE treats exact combinations as compatibility profiles so the launcher can explain the real reason a selection is available, experimental or unavailable.
What installation should look like
The user selects an instance, Minecraft version and loader, then reviews a runtime summary before installation. A Quest install can include Minecraft files, Java, loader libraries, Vivecraft-compatible components, the mobile renderer, ARM64 natives, OpenXR configuration and controller support. Those pieces are downloaded into staging, verified, configured and promoted only after validation.
If installation is interrupted, Resume should continue from completed managed components. Repair should replace managed runtime files without deleting worlds, screenshots, mods, resource packs or options.
Performance is more than render distance
Standalone VR has a tighter CPU, GPU, thermal and memory budget than a desktop PC. SPUDZWARE therefore separates launcher/runtime compatibility from in-game render distance. A profile can be technically compatible but still need conservative world settings or mod choices to maintain comfortable VR performance.
What to test on real hardware
- APK installs without a split dependency or test-only flag.
- Secure sign-in completes on the headset.
- Android ARM64 Java starts.
- Minecraft starts with the selected loader.
- The mobile renderer initializes.
- OpenXR initializes.
- The VR menu is usable with Quest controllers.
- A world loads and remains playable in VR.
Only the final steps justify calling a profile physically verified. Host-side file checks are valuable evidence, but they are not a substitute for hardware acceptance.