[dragonwriter]

> I don't understand why a new app if this could just be an additional feature in the current app.

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.

[ksk]

But why would it need a rewrite? Adding a download and some other buttons?

>It wouldn't make much sense as a feature of the existing app.

Why?

[dragonwriter]

> But why would it need a rewrite?

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.

[ksk]

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.

[dragonwriter]

> I don't think adding a button or two is some fundamental change

Neither do I, but the change here isn't "adding a button or two".

[ksk]

http://www.youtubego.com/signup/

None of these changes seem to be fundamental to me. They seem like trivial changes you expect in an incremental version update.

[lotso]

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.

[LordDragonfang]

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.

[ksk]

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?

[teach]

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.

[skylarsch]

The YouTube app proper can play offline videos already. The catch is, you have to have a YouTube Red subscription.

I don't think it's a technical issue at all, but a "people pay for this feature wherever YouTube Red is available" issue.

[ksk]

It is not default offline at all. http://www.youtubego.com/signup/

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.