react-native-track-player V5: A Commercially Licensed Rewrite on the New Architecture
The best audio player for React Native. Built on the New Architecture — Android Auto, caching, preloading, background playback, and more.
At a glance
- What is it?
- react-native-track-player V5 is a JSI-based audio player for React Native 0.74 and later, with background playback, Android Auto, caching and preloading. It is a paid dependency for commercial apps, and it is not compatible with V4.
- Who is it for?
- Adopt react-native-track-player V5 if your app already runs the New Architecture on React Native 0.74 or later, you need background playback, Android Auto, caching or preloading, and you are prepared to pay for a commercial licence. Stay on V4 on the v4 branch under Apache-2.0 if you cannot migrate, cannot enable the New Architecture, or cannot take a paid dependency.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 61 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem react-native-track-player solves for React Native audio apps
Playing a single sound file in React Native is easy. Keeping audio alive when the app is backgrounded, wiring the lock screen and notification controls, handling a headset being unplugged, and buffering the next track before the current one ends is not. Those are the jobs react-native-track-player takes over. The README describes it as a player with background playback, Android Auto support, audio caching, preloading, remote controls and React hooks such as usePlaybackState, useIsPlaying, useProgress and useActiveMediaItem.
The audience is narrow and specific. The requirements section states React Native 0.74 or later with the New Architecture enabled, meaning Fabric and TurboModules. If your app is still on the old bridge architecture, this library is not a candidate until you migrate. That constraint is stated plainly, and it is the first thing to check before reading any further.
The second constraint is commercial. The README carries an important note: starting with V5, react-native-track-player is commercially licensed. Personal and educational use stays free; commercial use requires a paid licence, with pricing at rntp.dev/pricing. V4 and earlier remain available under Apache-2.0 on the v4 branch. That single paragraph changes the adoption decision more than any feature in the list.
How the V5 rewrite works: JSI, TurboModules and synchronous calls
V5 is a complete rewrite, and the README says it is not backwards-compatible with V4. The mechanism behind that break is the move to JSI with TurboModule support. The README states that getProgress(), getQueue() and isPlaying() return synchronously in V5, where a bridge-based API would have to round-trip through a promise. The Android and iOS native layers were rewritten as part of the same effort.
In practice that means the shape of your code changes. Reading playback state no longer requires awaiting a promise before you can render a progress bar or decide whether a button shows play or pause. The hooks named in the README (useIsPlaying, useProgress, useActiveMediaItem) exist to feed that state into React components, and the quick-start example shows them destructured directly in a component body.
The trade-off is that the synchronous surface is only available to apps that actually run the New Architecture. JSI and TurboModules are not opt-in extras on top of the old runtime; they are the runtime. The README frames this as "no bridge overhead, no jitter", which is a claim about the architecture rather than a measured result, and the repository does not publish benchmark numbers to support it. Treat the synchronous API as the concrete, verifiable change and the jitter claim as positioning.
Installing react-native-track-player and playing your first track
The package is published as @rntp/player. The README gives a single npm install command, followed by a pod install for iOS. Android links automatically, so there is no manual native step documented for that platform.
npm install @rntp/playerFor iOS, run the CocoaPods install from the ios directory. The README shows the combined form:
cd ios && pod installSetup happens once at app startup. The README notes that on Android this call must be made in the foreground. The example passes a contentType of 'music', enables handleAudioBecomingNoisy, and sets an Android wakeMode of 'network':
import TrackPlayer from '@rntp/player';
await TrackPlayer.setupPlayer({
contentType: 'music',
handleAudioBecomingNoisy: true,
android: { wakeMode: 'network' },
});After setup, hand the player a queue with setMediaItems and start playback. Each item carries a url plus metadata such as title, artist and artwork:
await TrackPlayer.setMediaItems([
{
url: 'https://example.com/track.mp3',
title: 'Track Title',
artist: 'Artist Name',
artwork: 'https://example.com/artwork.jpg',
},
]);
TrackPlayer.play();For the UI, import the hooks from the same package. The README's example destructures playing from useIsPlaying, position and duration from useProgress, and the current item from useActiveMediaItem, then returns the player UI. What you should see after this sequence is audio starting, the progress values advancing, and the active media item reflecting the track you queued. The README does not document what happens if setupPlayer is called more than once, or how to recover if it rejects, so plan for that case yourself.
Where react-native-track-player V5 is the wrong choice
The licence is the first disqualifier. If you ship a commercial app, V5 is a paid dependency, and the README points to rntp.dev/pricing rather than stating terms inline. Teams that cannot add a per-project licence cost, or whose legal review cannot accept a NOASSERTION licence field on the repository, should look at the v4 branch instead of assuming V5 is the only path.
The architecture requirement is the second. React Native 0.74 or later with Fabric and TurboModules enabled is not a soft recommendation; the README lists it under Requirements. An app on an older React Native version, or one that has deliberately stayed on the old architecture, cannot use V5 at all. Upgrading React Native and enabling the New Architecture is a project in itself, and it is not something this library can do for you.
Third, V5 is not backwards-compatible with V4. Any migration is a rewrite of the player integration, not a version bump. If your app has a large amount of V4-specific code, the cost of moving is real and the README offers no migration guide, only a note that the break exists. Finally, the README does not document rollback, so there is no stated procedure for returning to V4 after a partial migration.
react-native-track-player compared with expo-audio and react-native-sound
The two names that come up most often in comparison searches are react-native-sound and expo-audio, and the difference is scope rather than quality. react-native-sound is a playback primitive: you load a file and play it. It does not present itself as a media session layer, so lock screen controls, notification controls, Android Auto and a queue model are things you build or add yourself. react-native-track-player treats those as the product, which is why its setup involves a player instance, a queue, and hooks that read state back out.
expo-audio sits inside the Expo ecosystem. If your app is managed by Expo and you want the audio surface to come from the same toolchain as the rest of your dependencies, that alignment is the appeal. react-native-track-player is not an Expo module in the README's install path; the documented steps are npm plus pod install, and its requirements are stated in terms of React Native version and architecture rather than Expo SDK. Choosing between them is largely a question of whether you want a media session with a queue and car integration, or a simpler playback API that fits an existing Expo setup.
The honest framing is that these are not interchangeable. If you only need to play a short sound effect, react-native-track-player's setup call, queue model and licence are overhead you do not need.
Maintenance, releases and what the V5 licence means for upgrades
The repository is not archived, and the last push was on 2026-07-31. Recent releases are v5.7.0 on 2026-07-16, v5.6.0 on 2026-06-20 and v5.5.0 on 2026-06-06, so the V5 line has been receiving point releases roughly monthly over that window. The README names no support window, no deprecation policy for V4 beyond its availability on the v4 branch, and no long-term support commitment for any version.
That matters for upgrade cost. Because V5 is a rewrite with a synchronous API, the expensive upgrade is V4 to V5, not 5.5 to 5.7. Once you are on V5, the point releases are the normal kind of maintenance. The licence question is separate and ongoing: the README says commercial use requires a licence and directs readers to rntp.dev/pricing and license.txt, but it does not state whether a licence is perpetual, per app, or renewable. Verify that directly with the vendor at [email protected] before you build a business on it. Nothing here is legal advice, and the repository's NOASSERTION licence field means the terms live in license.txt rather than in a standard identifier you can reason about from memory.
What the repository layout tells you about trying it
The top level holds CONTRIBUTING.md, README.md, license.txt and a devenv setup (devenv.nix, devenv.yaml, devenv.lock) alongside an example directory. The example is a full React Native app: App.tsx, index.js, metro.config.js, babel.config.js, jest.config.js, TypeScript config, a tailwind.config.js with a nativewind-env.d.ts, and both android and ios folders. For anyone evaluating the library, that example is the fastest way to see the API in a running app, and it is the closest thing to a demo in the repository.
The presence of a .nvmrc and the devenv files suggests the maintainers pin a Node version and a reproducible development environment for contributors, which is a reasonable signal about how the project is worked on but says nothing about the stability of the library itself. The README also points to rntp.dev for full documentation, API reference and guides, so the repository README is a starting point rather than the complete reference. If a behaviour is not described in the README and not visible in the example, rntp.dev is where to look next.
Editorial conclusion
Adopt react-native-track-player V5 if your app already runs the New Architecture on React Native 0.74 or later, you need background playback, Android Auto, caching or preloading, and you are prepared to pay for a commercial licence. Stay on V4 on the v4 branch under Apache-2.0 if you cannot migrate, cannot enable the New Architecture, or cannot take a paid dependency. Before committing, verify three things: that your app has Fabric and TurboModules enabled, that the licence terms at rntp.dev/pricing cover your distribution model, and that the synchronous V5 API surface matches the calls your current V4 code makes, because V5 is not backwards-compatible.
Frequently asked questions
How do I use react-native-track-player in a React Native app?
Install @rntp/player with npm, run pod install in the ios directory, then call TrackPlayer.setupPlayer once at startup (in the foreground on Android). After that, pass tracks to setMediaItems, call TrackPlayer.play(), and read state in your UI with hooks such as useIsPlaying and useProgress.
Does react-native-track-player V5 require the New Architecture?
Yes. The README lists React Native 0.74 or later with the New Architecture enabled (Fabric and TurboModules) as a requirement, and V5 is built on JSI so calls like getProgress() and isPlaying() return synchronously.
Is react-native-track-player free for commercial apps?
No. The README states that starting with V5 the library is commercially licensed, that personal and educational use remains free, and that commercial use requires a paid licence purchased via rntp.dev/pricing. V4 and earlier remain available under Apache-2.0 on the v4 branch.
Can I upgrade from react-native-track-player V4 to V5 without changing my code?
No. The README states that V5 is a complete rewrite and is not backwards-compatible with V4, with rewritten Android and iOS native layers and a synchronous JSI-based API.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/doublesymmetry-react-native-track-player)