Because the UX focus is different, the assumed technical infrastructure context is different, and, well, basically everything except the backend service consumed is different. Youtube Go is more distinct in role from the core Youtube app than the other break out apps (which mostly are distinguished by content focus on UX tweaks around the focal content) like Youtube Kids, Youtube Music, and Youtube Gaming.
I guess we have to agree to disagree. I don't think adding a button or two is some fundamental change that requires 10 meetings with 2 designers and 5 developers. They're already streaming the video data, just save it to a file in addition/option to rendering it. They can already play video data, just play it from the file instead of streaming it.
There's probably a lot more changes than you realize. I can only assume given your comments you've never worked on problems like this. There's so many benefits you can get from writing an app specifically for low-end Android devices with poor data connectivity.
>There's probably a lot more changes than you realize.
Do you know what those are or did you just assume that because its Google and so "there must be reason"?
> I can only assume given your comments you've never worked on problems like this.
You may assume it. The alternative explanation is I don't think its all that hard because its not all that hard.
> There's so many benefits you can get from writing an app specifically for low-end Android devices with poor data connectivity.
IMO, all that should be part of the base app. If your app can't handle different workloads (especially as basic as intermittent network connectivity for a video streaming application), its pretty much a huge design fail there.
I get the impression you haven't tried to refactor a large code base to change core functionality before. Any system architecture is built with, inevitably, certain assumptions on how the data is going to come through the app and where it's going to come from. Something as low-level as the source of video files in an app that is no doubt optimized for that is undoubtedly a fundamental change, and one that is going to be easier to fork and rewrite than try to shoehorn into existing code.
Your impression notwithstanding, the fact is that dozens of applications already exist that can play network streams, play files from your hdd, and even record streams to your hard disk (VLC for one), means that its a known solved problem. If, as you say, a video streaming app, at its core, cannot handle something so basic as saving the stream to disk, or playing the video from disk, then I would count that as a major design failure.
Also I don't get where the "undoubtedly", "fundamental change", "going to be easier to X" comes from. What is your basis for those statements?
In my opinion, default offline vs default online is a HUGE architectural difference. You could probably try to hack it into the existing player, but it wouldn't work well.
A ground-up rewrite wouldn't surprise me at all for such a change.
From the screenshots, it looks to be trivial functionality that could be baked into the existing app. Besides the ability to download and play files is not something I consider to be a "HUGE" architectural change.
>It wouldn't make much sense as a feature of the existing app.
Why?