I'm building a third-party Twitch client for iOS + Android and embedding player.twitch.tv in a WebView with the embedded JS method. One major problem is that this process is quite fragile on mobile. Playback
works in the sense that audio plays and video advances but standing up a full chromium/safari instance on mobile is performance intensive and results in the view being quite taxing on the user’s device, in addition to not being the best developer experience:

• WKWebView on iOS and Android System WebView both add memory and GPU cost on top of my application, rather than just using the lightweight AVPlayer (IOS) and ExoPlayer (Android) video player. We’re having to effectively shipping a mini-browser in the app to play one video.
• Layout is expensive. Any animated resize of the WebView container (common in mobile: chat open/close, rotation, keyboard, bottom sheets etc.) can stall or detach the video compositor

Because of this we’ve had to spend a lot of engineering time trying to get the webview to behave properly on both platforms, rather than focussing on other parts of the application and delaying our release of the application.

What would actually be ideal and less of a frustration would be to have a Helix endpoint that returns a short-lived HLS URL for a live stream (and ideally VODs), so native apps can just use native video players instead of having to load a full chromium/safari embed.

Example:

GET /helix/streams/playback
?broadcaster_id={id}

Response

{
"data": [{
"broadcasterid": "123456",
"streamid": "789",
"playbackurl": "https://…/index.m3u8?token=…",
"expiresat": "2026-06-07T20:30:00Z",
"type": "live"
}]
}

• 404 / offline when the broadcaster isn’t live, consistent with Get Streams.
• Optional video_id param for VOD playback later
• Clear docs on refresh cadence (when to re-fetch before the playback url expires)
• Explicit rate limits

This mirrors patterns that other video APIs use: fetch metadata, receive a stream URL and pass that to the player

Constraints I’d expect from Twitch:

• Requiring registered client ID + OAuth, same as the rest of Helix.
• Geo / entitlement checks server-side.
• Ads / subscriber only handled server-side in what URL is returned (or a clear error), not up to the client to implement ideally