What the Service Framework is
A way of building an application as services: self-contained pieces of logic with a defined lifecycle, registered once with a central manager and resolved anywhere they are needed. It grew out of years of shipping XR apps in Unity, where the alternative was singletons, static managers and scripts that only worked in the scene they were written in.
A service is a plain class. It says what it depends on in its constructor. The manager creates it, starts it in the right order, drives its lifecycle and hands it to anything that asks. Need a different implementation on a different platform? Register a different service. Nothing that uses it changes.
Why you would use it
Every project can be held together with a few static managers. The cost arrives later: hidden dependencies, an initialisation order nobody wrote down, and logic that cannot be tested without running the whole application. The framework replaces that with three guarantees.
Dependencies are explicit
A service asks for what it needs in its constructor. The manager satisfies it in order, or fails at startup with the name of what is missing.
Implementations are swappable
One leaderboard service for Steam, another for PlayStation. Storage for the browser, storage for native. Callers see one interface.
Logic is testable
Construct a service with fake dependencies and assert on it. No scene, no play mode, no browser.
Where it pays off: settings and save data, asset loading, scene or level management, leaderboards and accounts, input and interaction, analytics, anything with a platform-specific back end, and anything you want to test.
Two roads, one choice
The framework ships for two platforms. You choose by where your application runs, not by which features you want: both carry the full model.
Unity (C#)
The original framework, distributed as a Unity package on OpenUPM. Services are registered through ScriptableObject profiles. Editor tooling creates services from a template, switches the active platform for testing, and shows what is running in play mode. Unity 6 or newer.
com.realitycollective.service-framework
Web (TypeScript)
The same model for browsers and WebXR. A core npm package holds the manager, lifecycle, injection, events and schedulers. A thin connector ties it into React, three.js, Babylon.js or Meta IWSDK. A service written against the core runs unchanged on every host.
@realitycollective/service-framework plus a host package
Building both? Services port between them by design: the migration guide maps each concept one to one.
What is shared
These are not two frameworks that happen to share a name. The principles, the lifecycle and the rules for registration and dependencies are the same, implemented twice in the idiom of each language. Read the ladder top to bottom: the middle column is identical on both sides.
createServiceProfile lists registrations; each service is created through useClassBaseServiceBaseServicecreateServiceTokenIPlatform) gate per build targetBaseServiceModuleBaseServiceModule<TParent>The generated API reference covers both, built from the C# XML documentation and the TypeScript declarations. Questions go to the Reality Collective Discord.