Its a ground-up rewrite of the app with a very different experience focus and for a different audience. It wouldn't make much sense as a feature of the existing app.
>It wouldn't make much sense as a feature of the existing app.
Why?
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.
Neither do I, but the change here isn't "adding a button or two".
None of these changes seem to be fundamental to me. They seem like trivial changes you expect in an incremental version update.
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.
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?
A ground-up rewrite wouldn't surprise me at all for such a change.
I don't think it's a technical issue at all, but a "people pay for this feature wherever YouTube Red is available" issue.
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.