One launcher.
Three platforms.

What the launcher is for

SPUDZWARE Launcher is designed to keep the parts of Minecraft that usually get mixed together — game version, loader, mods, modpacks, Java, runtime files, VR components and server connections — attached to a named instance. An instance can be a small Vanilla test world, a Fabric modpack, a Forge setup, or a Quest VR configuration. Changing one instance should not silently rewrite another.

The goal is not to hide compatibility. The launcher resolves what is actually available for the selected Minecraft version and loader, then shows a review step before applying changes. Installation is separate from configuration: choosing Fabric does not mean the launcher should immediately download files, and choosing a different Minecraft version should not silently keep an incompatible loader.

Windows, Android and Meta Quest

Instances are the center of the workflow

Every instance has its own name, Minecraft version, loader choice, loader version, platform target, install state and validation state. The selected instance is meant to persist after a restart. When you switch instances, the visible version, loader, mods, modpacks and runtime summary should switch with it instead of leaving stale information on screen.

1. Create or select an instance.
2. Choose a Minecraft version.
3. Choose Vanilla, Fabric, Quilt, Forge or NeoForge when that loader genuinely exists for the selected version.
4. Review the proposed runtime change.
5. Apply the configuration.
6. Install or repair the managed runtime.
7. Play only after validation reports the instance ready.

Loader choices stay explicit

Fabric may be recommended for some combinations, but the launcher should never pretend that a Forge or Quilt selection is Fabric. Vanilla remains a real user-facing option even when an internal compatibility/bootstrap component is required. Forge and NeoForge are treated as separate loader families because their metadata, libraries and processors are different.

Compatibility is checked per Minecraft version. If a loader does not exist upstream for that version, the correct answer is that the combination is unavailable — not a fake install and not a blanket statement that the entire loader family is unsupported.

Install, validation and repair

Installation is shown as one user-facing job even though the launcher tracks many files underneath. Friendly stages include preparing the instance, downloading Minecraft, libraries and assets, installing Java, installing the selected loader, adding VR components where needed, configuring the runtime and validating managed files. Raw metadata and individual JSON files belong under technical details, not in the main Downloads view.

Repair is selective. The launcher can restore missing or damaged managed files while preserving user worlds, screenshots, mods, resource packs, options and configuration. A failed checksum should produce an actionable component error rather than a wall of internal resolver data.

Accounts and security

Microsoft/Minecraft sign-in uses the official Microsoft and Xbox authentication chain and is intended to verify Minecraft ownership before the launcher treats an account as ready. SPUDZWARE does not need a user's Microsoft password. Reusable session credentials are stored through operating-system secure storage rather than plaintext files.

SPUDZWARE account services are separate from Microsoft/Minecraft identity. That separation lets the launcher use a SPUDZWARE account for platform services while keeping Minecraft ownership tied to the user's Microsoft account.

Updates and release channels

The launcher is being connected to a SPUDZWARE-controlled update service. The design keeps Windows, Android and Quest releases independent, supports stable, beta and development channels, and verifies update metadata and package hashes before installation. Android and Quest still use the operating system's package-install approval flow rather than bypassing platform security.

Where to go next