Sounds right to me? You wouldn’t edit code on your phone. Git client on an iPad is barely usable to edit anything, just give up and use ssh. On a desktop, the browser already has the social features, and it would be a waste of your employees to constantly replicate work to the desktop client.

GitHub isn’t competing against Working Copy, or SourceTree. It’s competing against GitLab etc. So on desktop, they aimed to make an oversimplified beginner’s git client, to encourage beginners to use GitHub over alternatives. On mobile I suspect it was just too hard to build what people needed as a web app. Some people want push, which iOS web apps can’t do. May as well have it do a bunch of other things people like to do from their phone, and beat web with native controls.

Your point about why the GitHub is about the social features on mobile is spot on to me.

But the point about the desktop client I don't really follow, and that's my issue with GitHub's app product strategy: I think both apps should be about the social features.

I don't understand why a beginner's git client is important (is that really what GitHub Desktop is supposed to be?). And I'm not sure what this means: "it would be a waste of your employees to constantly replicate work to the desktop client"?

I want a social GitHub Desktop client because I want the better integration with my desktop, e.g., I want notifications for PR reviews and comments on issues, and I want to be able to jump immediately to the actual source code file being commented on in my local copy of the source. It seems like these are similar benefits to why Slack has a desktop app for example. And these are the types of integrations that would further differentiate GitHub from other git hosts.

Key is that zero development effort need be poured into making a native version of the github website, because it already works. The web is good enough on desktop. You want notifications, it could do them! You want to jump to an editor, no reason why the web couldn't do that (although you might have to switch branches!). Slack is different because when you're chatting, you don't really need tabs, but on GH I will usually have 10-15 open from a few different repos that stay mixed in with other pages for context. You're throwing away all the good things about browsers if you make it all native. And then you remember that every social feature comes at the cost of executing a git client really well. I'm personally very happy with GitUp.app not being clogged up with GitHub API calls to fetch comments, and showing alerts that when clicked will pull me away from the commit diff I was viewing. It works exactly as Git does offline.

If you address all those things, congrats, you've still barely reached par, and what do you have to show for it? Maybe a cool new look? This is why it's a waste, and an ongoing cost as GitHub.com evolves.

> Key is that zero development effort need be poured into making a native version of the github website, because it already works.

This is true of every web app that also has a desktop app, e.g., Slack, Trello, Notion, and Figma. So yes, that trade off always exists. I'd just prefer GitHub make the decision differently, like those apps I listed do, and choose to have a desktop app.

> You want notifications, it could do them!

Notifications are worse in the browser. E.g., they cannot provide a badge on the app icon, and I cannot easily switch to the app that's the source of the notification like I can with a desktop app. I want the same communication workflow that I use with email and Slack, i.e., I get a notification that someone has commented on my code, and a badge icon as a reminder to address it. Then I can click the app icon when I'm ready to address it (and open the relevant source files directly in my editor if I need to).

> You want to jump to an editor, no reason why the web couldn't do that (although you might have to switch branches!).

Can you walk me through how a web app would implement that feature? E.g., the browsers sandboxing model prohibits access to the file system? And how would a website even know where the repo was checked out?

> Slack is different because when you're chatting, you don't really need tabs, but on GH I will usually have 10-15 open from a few different repos that stay mixed in with other pages for context. You're throwing away all the good things about browsers if you make it all native.

Again, all of that is true of every app that has a desktop app and a web app. Also many desktop apps also support tabs? E.g., VS Code. In fact, tabs are built-in at the window manager level on macOS. And you wouldn't have to choose between the desktop app and the web, just like with those other apps you could use the solution that best fits the situation.

> And then you remember that every social feature comes at the cost of executing a git client really well. I'm personally very happy with GitUp.app not being clogged up with GitHub API calls to fetch comments, and showing alerts that when clicked will pull me away from the commit diff I was viewing. It works exactly as Git does offline. If you address all those things, congrats, you've still barely reached par, and what do you have to show for it? Maybe a cool new look? This is why it's a waste, and an ongoing cost as GitHub.com evolves.

I'm not really following this paragraph, e.g., "showing alerts that when clicked", what's the referring to? But let me give a counter perspective: The GitHub client I'm envisioning would not be a git client, it would be GitHub client. E.g., you would not be able to stage commits in it. In my experience, the number of developers that use a GUI git client is vanishingly small (personally I think GUI git clients are great, but anecdotally they're very rare among my colleagues). Therefore, I think making a git client is a silly market for a company of GitHub's size to be involved in. Whereas as their social features, and the level of integration they could do between a checked out repo and comments/issues, those would be true differentiating features that would keep developers from switching to other hosts like GitLab.

> Can you walk me through how a web app would implement that feature?

Same way you open a URL in the App Store? Not hard to let VSCode manage repo URL => workspace path mappings.

> Also many desktop apps also support tabs

Read again: "10-15 open from a few different repos that stay mixed in with other pages for context". Can't do that. You need a pretty huge value proposition for me to be willing to drop contextual tabbing to switch to your native app.

> I'm not really following this paragraph, e.g. "showing alerts that when clicked"

That's on you man, you brought up notifications. You also clearly understood when you replied on-point, no need for dramatically hand-waving an entire paragraph as incomprehensible.

> In my experience, the number of developers that use a GUI git client is vanishingly small

This tells me that GitHub.com is doing the everything-except-staging-commits job just fine for most people. AFAIK you add little value extending GH's analysis to live checkouts, and to gain what little there is, you'd have to bring some of that analysis online, compiled into the app, instead of cloud job queues. Pretty obvious why they wouldn't want to do that!

I think the beginner's client is a pretty big feature, but agree, they should have the social features better integrated... including searching/tagging related issues with commits etc.

There are a few nifty things you can do, but I don't see why a simply link to a GitHub.com page wouldn't do the job. Like the :Gbrowse command in fugitive.vim. Opening a URL sounds a lot cheaper to build than investing in a long term native apps team.