react-native-google-cast and the version matrix that decides your Cast integration

Five major lines, and the table is the real documentation

The most useful thing in this repository is a version history table, and it is worth reading line by line before you install anything.

The 1.x line implemented the library for Google Cast SDK v2 with manual discoverability, and it is marked stopped. The 3.x line was a rewrite for Cast SDK v3 with automatic session management, requiring React Native 0.40 or newer, also stopped. The 4.x line is a completely rewritten API that closely resembles the native Android and iOS APIs, and it requires React Native 0.60 or newer and iOS 10 or newer.

Then the two lines that matter now. 4.9.x requires React Native 0.76 or newer, iOS 15.1 or newer and Android 24 or newer, and its status is supported, with the note that it supports React Native's New Architecture in Compatibility Mode. 5.x has the same platform requirements but its status is that it is currently in development with full support for React Native's New Architecture.

That is a compact summary of the whole project history in five rows. The project started as a thin v2 wrapper, was rewritten twice, and is now at the point where the old architecture bridge is a mature line and the New Architecture version is not finished.

Why the API looks like the native SDKs

The library wraps the native Google Cast SDK for Android and iOS, and maybe web or Chrome in the future, providing a unified JavaScript interface. The note in the version table about 4.x being a completely rewritten API that closely resembles the native Android and iOS APIs is the design decision that matters.

Anyone who has written a native Cast integration has already met the concepts: a cast context, a session, a media load request, a remote player, a route discovery mechanism. If the JavaScript API mirrors those names, then a developer moving between a native app and a React Native app does not have to learn two vocabularies, and documentation for the native SDKs transfers to the JavaScript side.

The alternative would have been a friendlier, more React-shaped API, which is a reasonable thing to want and a reasonable thing to regret later. A wrapper that hides the native model can end up with two of everything, one native and one JavaScript, and the mismatch surfaces exactly when something goes wrong in production and you have to read the native documentation.

The primary language of the repository is Java, which reflects that the heavy lifting is in the android/ and ios/ directories, and the wrapper itself is written in TypeScript so the types are always up to date, which is stated in the project description as a reason to use it.

The distribution story: npm package, podspec, and a config plugin for Expo

The package metadata shows what actually ships and how a consumer gets it.

The npm package is react-native-google-cast at version 4.9.1, licensed MIT, with the main entry at lib/commonjs/index, the react-native entry at src/index, the module entry at lib/module/index and the types at lib/typescript/index.d.ts. The files array includes src, lib, android, ios, the app.plugin.js and react-native-google-cast.podspec, with a set of exclusions for build artefacts, .iml files, xcuserdata, .DS_Store, tests, fixtures and mocks.

The podspec is in the published files, so the iOS side installs through CocoaPods as part of the normal React Native autolinking, and the android/ directory is published for the same reason on the other platform.

The Expo situation is a specific and useful detail. The library can be used by custom built Expo apps, not Expo Go, since Expo SDK 42, and the config plugin is now included in the project, so you add the plugin to your app config and the native wiring happens at prebuild time. The project points you at the Installation and Setup sections of its own documentation for the Expo path.

That inclusion of app.plugin.js in the published files list is a fairly small change with a large effect on adoption, because it is the difference between an Expo app being able to use the library at all and being told to eject or maintain a custom native project.

The playground app is the working example, the demo app is not

There are two example projects in the repository and they are in very different states, and the project says so plainly.

The CastVideos demo app, which would be a React Native version of the CastVideos reference app from Google, is marked as currently outdated. The text in the repository points to the example folder and then strikes it through, with the note that it is outdated.

The playground folder, by contrast, is described as a sample app demonstrating the available APIs provided by the library. That is the one to look at if you want to see how the API is meant to be used, and the contribution guidelines make it part of the process: implement your thing, demonstrate how to use it in the playground project.

That combination tells you something about the project. There is a maintained surface for demonstrating the API and an unmaintained surface for demonstrating the platform, and the reason is that the Google reference app ages badly while the library's own API surface is what changes.

The development scripts in package.json make the distinction visible too. There is a bootstrap script that bootstraps both the example and the playground, a separate script for each that runs the project install, the root install and the pods, a script per project for installing pods, and a docs script that runs a documentation generator and starts the docs website alongside a watch process.

The type definitions and the doc site are generated from the source

Two files in the repository root tell you that the documentation is not maintained by hand.

There is a typedoc.json and a scripts/ directory, and the docs scripts run node scripts/docs.js before starting the docs website, with a separate script that watches for changes. The repository also carries a docs/ directory, and the contribution guide asks you to document functionality in JSDoc and in the docs.

So the JSDoc comments in the TypeScript source are the source of the API documentation, which is the right arrangement for a library whose types are generated from the same source. It also means the quality of the published docs depends on contributors writing the JSDoc, which is why the contribution checklist calls it out as a separate step rather than a nice-to-have.

The hosted documentation is at react-native-google-cast.github.io, with the getting started, installation, setup and troubleshooting pages as the main entry points, and the project points there rather than trying to duplicate the install steps in the repository.

Two more repository details are worth noting for anyone hacking on the library. The formatting is handled by prettier over src/**/*.ts and the linting by eslint across js, ts and tsx files, and there is a babel.config.js, a tsconfig.json and a .clang-format for the native code, so a pull request that touches Java or Objective-C is held to a different formatter from one that touches TypeScript.

Where this library stops being the right answer

The clearest case is an app that needs full New Architecture support right now. The 4.9 line supports the New Architecture in Compatibility Mode, which means the new renderer is running but the old bridge is still in the picture, and the 5.x line is where full support lands, and that line is described as currently in development. Choosing between them is a decision about whether you can wait.

The second case is a project still on an old React Native. The 4.x line needs React Native 0.60 or newer and 4.9.x needs 0.76 or newer, so a team on an older React Native is looking at 4.x or earlier, and the earlier lines are marked stopped. There is no supported path for an old app, only a frozen one.

The third case is a cast application that is not a React Native app. The library is a wrapper for the native SDKs and its API deliberately resembles them, so if you are starting something new and want one cross-platform abstraction, writing directly against the native SDKs gives you the same vocabulary without the bridge.

And the fourth is web. The project description says the library wraps the native SDK for Android and iOS, and maybe web or Chrome in the future. That maybe is doing a lot of work, and if casting to a browser tab is part of the requirement, this is not the library for it yet.

Editorial conclusion

react-native-google-cast suits a React Native app that has to cast to a TV and wants one JavaScript interface over both platforms, and it suits teams on React Native 0.76 or newer with iOS 15.1 and Android 24 minimums, since the 4.9 line supports the New Architecture in Compatibility Mode. It does not suit an app that needs full New Architecture support today, because that only exists in the 5.x line and that line is still under development. Before you pin a version, read the version history table rather than taking the latest tag, because the latest release is 5.0.0-beta.0 while the latest stable is 4.9.1, and note that the last push was on 2026-09-04.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-native-google-cast/react-native-google-cast on GitHub
4. README
5. Releases