RNTP v5 void Mutation Issues

[brianlenz]

Describe the Bug
We have upgraded to RNTP v5 (New Arch / TurboModule), but we're unable to publish to production because the void methods in RNTP v5 have "eventual consistency" which means we can't rely on when the changes take effect. In RNTP v4 (and the "old" v5 alpha), we could await all of those calls so that we knew definitively when they finished executing.

It's worth noting that most of these issues only seem to be present on release builds on real devices. The simulator and dev builds w/ Metro don't seem to reproduce the issue.

In particular, there is no synchronization between the void mutations (dispatched to the main queue) and synchronous JS-thread getters.

From ios/TrackPlayer.swift:57:

All void module methods run on the main queue: AVPlayer, AVAudioSession, and the MediaPlayer singletons assume main-thread use, and RN dispatches calls FIFO onto this queue. The blocking synchronous getters still run inline on the JS thread.

This means:
• setMediaItems, clear, addMediaItems, etc. → dispatched to DispatchQueue.main, return to JS immediately
• getQueue(), getActiveMediaItemIndex(), isPlaying(), etc. → run inline on the JS thread, bypassing the main queue entirely

There is no synchronization between these two groups. Calling getQueue() immediately after setMediaItems() can return stale results (the old queue) or an empty array [] (if the main thread is between queue.clear() and player.add() inside setMediaItems).

@dcvz we are finding that there are multiple scenarios in our app adversely affected by the eventual consistency of these calls. I'm assuming other people upgrading from RNTP v4 and the v5 alpha will have similar issues, so just wondering if there is anything we can do to make these calls synchronous?

Steps To Reproduce / Reproduction
Pseudo-code that triggers the issue:

// Replace the entire queue
TrackPlayer.setMediaItems(newTracks);
// ^ void — dispatched to DispatchQueue.main, returns to JS immediately

// Any subsequent code — e.g. a component that navigates and mounts:
const queue = TrackPlayer.getQueue();
// ^ inline on JS thread — main queue may not have processed setMediaItems yet
// queue.length can be 0 even though newTracks is non-empty

Environment Info:

react-native info

System:
  OS: macOS 26.6.1
  CPU: (10) arm64 Apple M1 Max
  Memory: 218.64 MB / 64.00 GB
  Shell:
    version: 5.3.9
    path: /opt/homebrew/bin/bash
Binaries:
  Node:
    version: 25.6.1
    path: /opt/homebrew/bin/node
  Yarn:
    version: 4.17.1
    path: /opt/homebrew/bin/yarn
  npm:
    version: 11.9.0
    path: /opt/homebrew/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/brian/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 25.5
      - iOS 26.5
      - macOS 26.5
      - tvOS 26.5
      - visionOS 26.5
      - watchOS 26.5
  Android SDK:
    API Levels:
      - "29"
      - "30"
      - "31"
      - "33"
      - "34"
      - "35"
      - "36"
    Build Tools:
      - 26.0.2
      - 26.0.3
      - 28.0.3
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 31.0.0
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
      - 35.0.0
      - 36.0.0
    System Images:
      - android-28 | Google ARM64-V8a Play ARM 64 v8a
      - android-29 | Google APIs ARM 64 v8a
      - android-29 | Google Play ARM 64 v8a
      - android-30 | Google Play ARM 64 v8a
      - android-31 | Google Play ARM 64 v8a
      - android-33 | Desktop ARM 64 v8a
      - android-33 | Google APIs ARM 64 v8a
      - android-34 | Google Play ARM 64 v8a
      - android-35 | Google Play ARM 64 v8a
      - android-36 | Google Play ARM 64 v8a
      - android-36 | Pre-Release 16 KB Page Size Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2026.1 AI-261.25134.95.2612.15914620
  Xcode:
    version: 26.6/17F113
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.30
    path: /opt/homebrew/bin/javac
  Ruby:
    version: 3.3.0
    path: /Users/brian/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.2.0
    wanted: 19.2.0
  react-native:
    installed: 0.83.6
    wanted: 0.83.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

• @rntp/player version 5.8.0
• iPhone 17 Pro Max
• iOS 26.6

How I can Help
Have you investigated the underlying issue?
Yes, the issue appears to be by design, but creates challenges for consumers.

[dcvz]

Thanks for the report @brianlenz, we'll take a look! Many users are on v5 so I'm surprised this hasn't come up yet.

[pizzapanther]

I’m seeing this consistently also. I have to do a setTimeout with a 10ms wait to get the new queue. That seems to work consistently but I haven’t tested extensively yet.

[brianlenz]

@dcvz no pressure, but I was just curious if you have any estimate on when improvements might come through in this area? We'd favor a solution where we can deterministically rely on these methods fully completing so that we can reliably call methods sequentially. The ideal would be for these methods to not return until execution has completed fully (e.g. making them async so we can use await). Thank you! 🙏

[dcvz]

Hey @brianlenz, apologies there was another RNTP issue that took a lot of my bandwidth. This should now be fixed in 5.9.2. All synchronous getters on iOS now run through the same queue as the mutations, so they wait for pending changes before reading. getQueue() right after setMediaItems() returns the new queue, every time which now matches how Android already worked.

@pizzapanther your setTimeout workaround can be removed after updating.

I'm closing but please feel free to re-open if you see something off.

[brianlenz]

@dcvz thank you so much! No worries on the delay 🙏 I'm going to go give it a shot and will let you know if anything seems off!

[pizzapanther]

I'm still seeing the same issue, I don't get an updated queue after adding/setting items. The timeout work around still works.