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.

We are building a musician practice application that uses MusicKit.js inside a WKWebView on iOS and macOS. One of our core use cases is musical looping, where playback repeatedly seeks back to a loop start position while a song is playing. A typical loop length is 1-4 seconds, making interruptions that might be acceptable for general media playback very noticeable in our use case. For looping we currently use MusicKit’s seekToTime() API. We have also experimented with audioElement.fastSeek() and directly setting audioElement.currentTime. In all cases, seeking to a nearby position during playback produces an audible hitch or pause, even when the destination appears to already be buffered. We have observed similar interruptions when changing the playback rate during playback. For comparison, the same JavaScript bridge architecture running in a Chromium-based WebView on Android exhibits significantly smoother seek behavior and supports near-seamless looping. At this point, the WebView media stack appears to be the primary platform difference we have identified. We are currently using MusicKit.js v2. We are aware that v3 is available, but have not found anything suggesting this behavior has changed. As part of our investigation, we also experimented with Apple’s native MusicKit APIs. We observed that seeking and playback-rate changes can still produce audible interruptions, although playback-rate changes behave noticeably better than our MusicKit.js / HTML audio implementation. This led us to wonder whether the behavior originates from the underlying Apple media pipeline rather than MusicKit.js itself. Our questions are: Is it expected that seeking during playback, whether through seekToTime(), fastSeek(), or currentTime, causes the playback pipeline to be interrupted or rebuilt on Apple platforms? Are there known differences in WebKit’s media pipeline, buffering, or seek handling that would explain why the same implementation exhibits smoother seek behavior in a Chromium-based WebView? If so, are there recommended WebKit, WKWebView, or MusicKit.js techniques to achieve smoother, near-seamless looping? Given that we observe similar, though less pronounced, behavior when using native MusicKit APIs, is this a known characteristic or limitation of the underlying Apple media stack? If so, are there any APIs or implementation patterns recommended for applications that require tight musical looping and low-latency seeks? Any guidance would be greatly appreciated. Our goal is to provide musicians with seamless looping for practice and transcription, where even very small interruptions are noticeable.