The latest articles on DEV Community by Leonard Matasel (@leonard_matasel). https://dev.to/leonard_matasel https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4131609%2Fdeffddd5-05bd-4df8-b8c6-25013d6b6b5c.jpg https://dev.to/leonard_matasel en Leonard Matasel Fri, 18 Sep 2026 13:26:30 +0000 https://dev.to/leonard_matasel/playing-youtube-in-flutter-the-case-for-a-webview-fallback-25dn https://dev.to/leonard_matasel/playing-youtube-in-flutter-the-case-for-a-webview-fallback-25dn <p>Every Flutter app that plays YouTube picks one of two strategies, and both break. </p> <p><strong>Direct extraction</strong> resolves the stream URLs and hands them to <code>video_player</code>. You get native playback, real quality switching and a UI you control. You also get a dependency on an interface nobody promised you: when YouTube changes something upstream, extraction returns nothing and your users get a black screen. </p> <p><strong>A WebView</strong> is the strategy that doesn't break, because it's the player YouTube itself maintains. You pay for it: the chrome isn't yours, quality selection isn't yours, and integrating it with the rest of your UI is work. </p> <p>The useful answer is not to choose. Try extraction, and when it fails, fall back to the WebView for that video — not for the whole app, not permanently. </p> <h2> What "fails" means </h2> <p>Failure here isn't an exception you catch around the player widget. It's earlier: the extraction step returns no playable stream, or returns one that the platform refuses. The fallback belongs at the point where you still know which video you were resolving and haven't shown anything to the user yet. Deciding after the first black frame is too late — by then you're swapping a widget the user is already looking at.</p> <h2> What this costs you </h2> <p>The fallback path is not feature-equivalent, and pretending otherwise is how you get bug reports. In a WebView you lose the native quality selector and your own control overlay. So the fallback needs to be a degraded-but-working path you have actually tested, not a branch you wrote once and never exercised. </p> <h2> Where this ended up </h2> <p>I wrapped all of it in a package, <code>omni_video_player</code>: YouTube with the automatic fallback described here, plus Vimeo, HLS with quality switching, network files and assets — one widget, one controller.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code> OmniVideoPlayer( sourceConfiguration: VideoSourceConfiguration.youtube( videoUrl: Uri.parse('https://www.youtube.com/watch?v=...'), preferredQualities: [OmniVideoQuality.high720], ), ) </code></pre> </div> <p>Two limits worth knowing before you adopt it: YouTube quality selection works on Android only, because on iOS the API exposes a single muxed 360p stream and there is nothing to switch between; and WebM seeking is off on iOS, because WebKit stalls the decoder on a seek and can't recover. </p> <p>Android, iOS, Web. BSD-3.<br><br> <a href="https://pub.dev/packages/omni_video_player" rel="noopener noreferrer">https://pub.dev/packages/omni_video_player</a></p> flutter mobile programming software