bug(iOS): audio player seekbar does not update position and time after manually moving

[divyanshu-patil]

Describe the Bug

When playing audio, manually dragging the seek bar does not update its position, and the playback time also remains unchanged. The seek bar appears to stay frozen while audio plays correctly from the time of progress

This unexpected behavior occurs only on iOS. On Android, the seek bar and playback time update correctly when seeking.

Steps to Reproduce

1. Open the app on iOS.
2. Navigate to any room.
3. Play an audio message.
4. Drag the seek bar to any position to seek the audio.
5. Observe the seek bar position and the displayed playback time.
6. Observe that the audio continues playing.

Expected Behavior

seek bar and playback time should update as per audio playback progress

Actual Behavior

seekbar and time freezes at the point when user releases seekbar

Rocket.Chat Server Version

lastest: docker-compose image

Rocket.Chat App Version

4.68.0

Device Name

iPhone 17 Pro simulator

OS Version

iOS 26

Additional Context

This strange behaviour happens only on iOS and works correctly on android

Screenshots

ios.emulator.audio.seek.issue.compressed.mp4

[ANANYA542]

Hi I’d like to work on this issue and submit a fix. I’m currently investigating the iOS-specific audio seek behavior and will share updates here.Please assign this issue to me if possible.

[divyanshu-patil]

the issue does not get assigned but you can work on it,
can you make sure its reproducible at your end?

[ANANYA542]

Thanks for the clarification. I’m already working on this issue.I’ve been able to reproduce the behavior on iOS using the iOS Simulator by seeking during audio playback — the audio continues playing, but the seek bar position and time label stop updating after the seek operation. I’m currently investigating this in AudioManager.ts, as it appears to be related to how expo-av handles playback status updates on iOS after calling setPositionAsync().I’ll continue validating the fix on iOS and will also make sure there’s no regression on Android before opening a PR. Please let me know if there’s anything specific you’d like me to verify or document further.

[divyanshu-patil]

Can you update this on the open server ? React-native channel to be specific.

[ANANYA542]

@divyanshu-patil I can update it on the React Native channel. Could you please share the Open Server link, or guide me on where I can access it? I want to make sure I’m posting the update in the correct place.

[divyanshu-patil]

Update it on https://open.rocket.chat/channel/react-native

[deepak0x]

Hey @diegolmello @Rohit3523 — the Reanimated v4 migration in PR #6720 (commit 75d866b88) reworked Seek.tsx and this looks resolved now.

The new implementation uses a contextX SharedValue to track the baseline before panning, and a useDerivedValue hook that handles bidirectional sync: when panning, currentTime follows the slider position; when not panning, translateX follows the audio's currentTime. The timeLabel updates from currentTime in both cases. There's also an onFinalize handler that restores the slider position if the gesture fails.

So after a manual seek, once the gesture ends and isPanning goes false, the slider and time label stay in sync with the actual audio playback position. Think this can be closed.