XStreaming: an open source Xbox and xCloud streaming client for mobile

A mobile client, and the platforms it deliberately does not target

XStreaming is described as an open source Xbox streaming client that lets you stream Xbox and play xCloud, and the documentation frames it as an open source mobile client for xCloud and Xbox home streaming, inspired by another project called Greenlight.

The scope is stated with unusual precision, and the exclusions are as informative as the inclusions. The project covers Android and iOS, and it has been published in the Huawei App Gallery for HarmonyOS. For Windows, macOS and Linux including steamOS, the documentation points you to a separate XStreaming-desktop repository or to Greenlight instead. For the Nintendo Switch, it recommends a different open source project, LunarNX, which operates natively within the Atmosphere environment, supports both console streaming and xCloud, and has a maximum output of 1080p HQ.

That is a reasonable division of labour for a small project, but it does mean XStreaming is not a general purpose remote play client. If you want the same client on every platform you own, you are assembling a set of repositories rather than installing one application.

There is a legal note in the README that is worth reading carefully rather than skipping. XStreaming is not affiliated with Microsoft or Xbox, and all rights and trademarks are the property of their respective owners. It is an independent client implementation, and the project accepts that the services it talks to belong to someone else.

The iOS situation is unusual and worth knowing before you look for the app. XStreaming is on the App Store, but due to listing restrictions it is named PeaSyo there, and the documentation asks people who like the app to buy it for the price of a cup of coffee. The code remains fully open source, and anyone can build their own iOS version by fetching the ios branch and compiling it.

The feature list is a controller and network specification in disguise

The features section reads like a checklist of the problems that actually appear when you stream a console to a phone, and it is worth reading each line as a symptom rather than a feature name.

Streaming video and audio from an Xbox One and an Xbox Series S or X is the base capability, at 1080P or 1080P in HQ mode. AMD FidelityFX super resolution v1 is listed, which is the upscaling path for a stream that arrives below native resolution. Virtual OTG and Bluetooth gamepad controls are supported, so the phone can present a controller to the console without a physical one. Controller rumble is supported, and rumble on xCloud works without any proxy in some regions, which tells you the project has dealt with the region differences in how xCloud negotiates input.

Then there are the items that show how much work the project has done. Android TV is supported, so the client is not only a handheld application. IPv6 is supported, which matters because a large share of mobile networks are IPv6 only and a client that assumes IPv4 will fail silently on them. An achievements system is present, and there is a dual render engine.

The dual render engine is explained in the compatibility section rather than the features list, and the explanation is the most useful troubleshooting note in the repository. Version 2 introduces it to ensure compatibility with devices running WebView versions below 91. If the streaming interface shows a blank screen or becomes unresponsive, the fix given is to go to Settings, then Rendering Engine, then Select Native, to switch to the Android native rendering engine for video playback.

That is a genuinely useful design decision, because the WebView on an Android device is the vendor's build, and vendors ship old ones for years. A player that has a native path ready is not caught out by a device that other apps have long since stopped supporting.

Frame generation needs a library the project will not ship

The frame generation feature is where the project draws a line, and the way it draws it is instructive.

The documentation says the XStreaming frame generation is based on a separate project called LSFG-Android, and that you need to import a genuine Lossless.dll to use the full frame generation functionality. It then states plainly that this project will not provide the Lossless.dll file, and asks users to support genuine LSFG and obtain a genuine Lossless.dll.

So the boundary is: the client is open source, the frame generation engine is not, and the binary it needs is something you have to obtain from the vendor yourself. The project does not redistribute it and does not point at a copy it hosts.

What the feature does is described in the features list as LSFG-based frame generation, enabling a 30fps to 60fps and 60fps to 120fps experience on Snapdragon devices. So the audience for it is specific: recent Snapdragon hardware, and a stream whose frame rate you want doubled.

The reason the project cannot include the file is presumably licensing, and the AGPL-3.0 licence that covers the rest of the code does not extend to a third party component the maintainers do not own. The result is a slightly awkward but honest arrangement. The feature is advertised because it works, the dependency is named, and the missing piece is a user-side responsibility. A reader evaluating the project should understand that the advertised 120fps path is not available from a fresh install.

It is also worth noting the interaction with the hardware story. A Snapdragon device getting 30fps to 60fps is a different proposition from a mid-range Android phone trying to decode a 1080p HQ stream and run frame generation on top, which is where the native rendering engine option and the FSR option earn their place.

React Native 0.72 with a patched native layer

The local development section gives the toolchain, and the requirements are specific enough to matter: React Native 0.72.14, Node.js 20 or newer, and Yarn 1.22 or newer. The package manifest pins react-native at 0.72.14 and react at 18.2.0, which is a consistent pairing for that release line.

The manifest also shows a project that reaches well beyond the React Native defaults. The interface is built with react-native-paper and with UI Kitten components and Eva icons, so there are two component systems in play, which is consistent with the Eva design system dependency and the per platform theming that the dual render engine hints at. Navigation uses React Navigation with bottom tabs, native stack and stack navigators. axios handles the HTTP calls and react-native-cookies manages the session cookies that a web based sign-in flow produces, with a QR code SVG component that is almost certainly used for the sign-in handoff.

The native side is where this project does unusual work. There is a nano-rs directory, which suggests a small Rust component compiled into the app, and a patches directory together with a postinstall script that runs patch-package, which means the project patches its node_modules after installation rather than requiring forks. There is also a third-party directory and a Gemfile, so parts of the build depend on the Ruby toolchain as well as Node.

The scripts section of the manifest shows the whole build surface. The android script runs a React Native dev build with the devDebug variant and the application id com.dev.xstreaming, the ios script runs the iOS variant, release:android shells into the android directory and runs the Gradle assembleProdRelease task, and the test script is jest, with a jest.config.js and a __tests__ directory in the repository.

Getting the development build running takes three steps

The documented setup path is short and complete, which means you can have a build on a device without reading anything else.

First, clone the repository and change into it:

git clone https://github.com/Geocld/XStreaming
cd XStreaming

Then install the dependencies with Yarn:

yarn

And finally run the development build:

npm run android

The postinstall hook runs patch-package, so the patches are applied as part of the install step, and that is why the install has to happen before the run.

The Android dev build uses a distinct application id, com.dev.xstreaming, and the devDebug variant. That is worth noting for anyone who also has a store build of the app on the same device, because a debug build and a release build with different identifiers and different signing will install side by side rather than replacing each other.

For a release build the manifest documents a different path, going into the android directory and running the Gradle assembleProdRelease task. The repository also carries a .yarn directory and a .yarnrc.yml, so the project uses Yarn's own vendored binary rather than depending on whatever Yarn happens to be installed globally, and there is a .bundle directory and a Gemfile for the Ruby side of the toolchain.

The three development documents map the protocol

The documentation section points at three files, and their titles are the closest thing the repository has to an architecture description.

The first is the authentication document, the second the web API document, and the third the stream document. That order is the data flow of the application. You authenticate, you talk to a web API to discover what is available, and then you establish the stream.

The authentication document is the one with the most obvious legal and technical weight, because signing in to a console means handling a Microsoft account, a device token, and whatever challenge the service presents. The web API document covers the account and library endpoints that sit between the sign-in and the stream, which is where the information about which games are installed or which titles are available in xCloud would come from. The stream document covers the transport itself, which is where the dual rendering engine, the FSR upscaling and the frame generation all operate.

None of the three documents is reproduced in the README, and this is the main gap in the public documentation. What the repository gives you is a working client and a pointer to where the protocol is explained, so a developer who wants to understand how the streaming handshake works has to open the docs directory.

The contributor list at the bottom of the README names seven people, and the text credits them with contributing the capabilities that make the project work. For a client that has to interoperate with a service it does not control, that is the expected shape of the project: a set of people each of whom reverse engineered or documented a piece of the protocol.

What the AGPL-3.0 licence means for a client like this

The licence is AGPL-3.0, and the README states the position firmly: XStreaming strictly complies with the AGPL v3 licence, and if other projects refer to or borrow from this project's implementation, please strictly comply with this license.

That last sentence is unusual to see in a README and it is aimed at a specific situation. When a project implements a service by talking to it over a network, the service owner can change the service, and a client that only works against the current version of that service becomes a maintenance liability. The AGPL is chosen precisely because it reaches code that is not distributed in binary form, which is the case for a React Native client whose JavaScript bundle is downloadable and whose native parts are buildable from source.

The practical implications for an adopting team are worth stating plainly. If you take this code, modify it, and run it as a service to other people over a network, the AGPL obligations reach that service. If you build it and hand the binary to a colleague, the source obligations come with it. If you use it only for your own play, the practical effect is nil, and that is the overwhelming majority of how it is used.

The other legal point is the disclaimer. The project is not affiliated with Microsoft, and it does not redistribute the Lossless.dll needed for the full frame generation path. A team considering a commercial deployment of a modified client should take its own advice on both the licence and the service terms, because a client that works today may stop working when the service changes, and that is a business risk the licence does not address.

Editorial conclusion

XStreaming fits a player who owns an Xbox console and wants to play on a phone or tablet, especially on HarmonyOS or on a device whose WebView is too old for the default path, and it fits a developer who wants to read a working implementation of the console streaming handshake in TypeScript. It is the wrong choice if you need desktop streaming, since the documentation points elsewhere for Windows, macOS and Linux, and it is the wrong choice if you expect frame generation to work out of the box, because that path needs a vendor library this project will not distribute. Before adopting it, read the three development documents in the docs folder, check the WebView version on your device against the 91 threshold the dual rendering engine exists for, and confirm the AGPL-3.0 terms are acceptable for how you intend to build and distribute it.

Frequently asked questions

Official sources

1. Geocld/XStreaming on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases