This question overlaps with a newer post that contains additional implementation details
To avoid splitting discussion, please see:
“MusicKit.js / WKWebView: Are audible hitches during seek a known WebKit or Apple Media Stack limitation?”
We are building a music practice application that uses MusicKit.js inside a WKWebView on iOS and macOS.
Our application requires tight musical looping, where playback repeatedly seeks back to a loop start position while a song is playing.
We have observed that:
• Seeking to a nearby position within already-buffered audio using HTMLAudioElement.currentTime causes an audible interruption or hitch.
• Changing HTMLAudioElement.playbackRate during playback also appears to interrupt playback briefly.
• These interruptions make seamless looping difficult to achieve.
For comparison, a very similar JavaScript architecture running in a Chromium-based WebView on Android exhibits significantly smoother seek behavior and supports near-seamless looping.
Our questions are:
- Is it expected that changing currentTime or playbackRate on the underlying audio element causes the playback pipeline to be interrupted or rebuilt on Apple platforms?
- Are there any recommended WebKit, WKWebView, or MusicKit.js techniques that can reduce or eliminate these interruptions when seeking within already-buffered media?
- Would native MusicKit playback provide lower-latency or more seamless seeking than MusicKit.js, or do both approaches ultimately rely on the same playback pipeline?
Our use case is musical practice, where even interruptions of a few tens of milliseconds are noticeable.
Any guidance on achieving the smoothest possible loop-seeking behavior on Apple platforms would be greatly appreciated.