I've been using betas for the Android app, but in my experience there's still a lot of paper cuts here.
For example, I do quite a few code reviews on my Pixel 2, but what drives me crazy is that the lines in the diffs wrap! On top of that, the code font it uses is pretty large, so wrapping happens often and makes reviewing much harder.
The support for per-commit code review (which is only so-so in the desktop web experience) is even harder to use on mobile.
The main activity feed from / is nowhere to be seen, even though this is something I use daily on my laptops (long-standing pet peeve, since this is also non-existent in the mobile web view).
If you follow a link to particular issue comment (for example, from the bottom of a notification email), the Android app will just land you at the top of the issue.
So, having the app is an improvement over the mobile web experience (particularly since the PR review approval button was impossible to hit in the mobile web view without zooming), but IMO there's still a lot to be done here, and I hope they keep executing on it.
I feel for text wrapping, letting it simply flow off the device screen works well in this UX scenario because all of these devices should be expected to be multi-touch enabled. It is very intuitive for a mobile device user to swipe left/right in order to scroll content that is obviously clipped by the screen dimensions. Swiping left/right and pinching to zoom are the very first things I tried when reviewing a PR. I feel if you could support some approach where the text item is displayed at full scale always (no line break/wrapping), and the user can basically treat the view like they would an image (pinch-to-zoom/pan).
Additionally, perhaps the code review process on mobile could be somewhat different from the desktop experience. Instead of trying to display the full diff all at once for a file, perhaps you aggregate the diff regions, and then display those one-at-a-time. Sort of like a tinder for code reviews. Swipe left on a diff region for deeper review, swipe right for approval. Lots of cool stuff you can do if you fully-leverage the mobile device environment and related user knowledge.
BTW, I love the direction all of this is headed in. Keep up the great work.
I too use the feed or homepage. Mostly for discovery of repos from people I follow and getting notifications about who starred which of my repositories. I do miss that in the app. Otherwise I love it so far.
Yes I have to say, this is fast becoming one of my favourite ways to discover new repos. It attracts developers who might not be the most vocal on traditional forms of social media but otherwise have something worth visiting.
As the sibling comment says, horizontal scrolling would be an improvement over the status quo. Pinch to zoom would be another nice win.
> Can you tell me more about what you use this feed for? You're talking about the one on the github.com home page?
Yes, that's the one I'm talking about. I use it to see who's starring repos I'm involved in, who's following me, and what the developers I follow are starring (the feed also has stuff about what people are pushing to repos I watch, but that is not interesting to me because I usually keep track of it by following PRs or issues). Just keeping track of what's going on in the world.
Finally, I found the feedback handling from the betas somewhat discouraging. At least when I tried it, it just emailed off and there was no follow-up at all. If that process was a bit more conducive, I might have given you this feedback sooner.
I've often used it, but just checked and now it doesn't work.They have improved the UX, pray they do not improve it any further.
I don't want to have an account (because they want email), so it looks like this is the end of github for me.
EDIT: in android firefox, I found the "Request Desktop Site" works (on a code page) e.g. https://github.com/termux/termux-app There is also a desktop link in the footer, but it doesn't work.
WARNING: If I try the desktop link and then "Request Desktop Site", I get to https://github.com/site/mobile_preference (a 404). Starting fresh and just doing "Request Desktop Site" works.
I saw there's now an option in Github user settings which allows you to mark your entire account as always serving desktop pages when you're on mobile.
Ironically, can't dig up the link on mobile since I've not yet clicked that button.
"Mobile settings"
[ ] Opt out of mobile pages
This will cause all your sessions and devices to only experience the desktop site for all pages. Pages designed to be responsive will still scale down properly.
I wish their web experience was improved on mobile. I have no interest in downloading apps of 90% of the websites I visit on my mobile browser. Right now the rare times I need to use github on mobile, I almost always have to switch to the desktop view because their mobile offering is so lacking in critical features.
I wish they showed the full readme by default on mobile repository pages. If I'm on my phone, there's a good chance I'm only there to look at the readme, anyway. Just let the readme extend down without needing to expand it. Or at least, don't make expanding it a new page load.
I just miss the desktop mode link on the bottom of every page. Sure it's harder to use, and I spend most of my time in mobile view, but sometimes I just need to get shit done.
I actually sent them a support ticket about this, and this was their reply:
"I understand how the previous workflow would be useful, and we apologize for the inconvenience it has caused.
However, the good news is that the mobile team is working on releasing iOS and Android GitHub mobile applications early next year, which should resolve some of the limitations of the current mobile site."
Like really, just give me the desktop view back ffs.
You can still use the desktop site by using the 'Request Desktop Site' on your phone's browser (at least on most browsers). If you're logged in to GitHub, you can enable 'Opt out of mobile pages' in your account settings, though it sounds like you want to use both.
Best example of the above is YouTube. Have to reload like 3 times to get the real desktop site on iOS just to have background video playback and access to all videos on most pages.
(This is with YouTube set to request desktop site always in settings).
On iOS at least, the "Request Desktop Site" option has been moved under the reader options in the URL bar. It seems to work for me, though is annoying.
This is literally why I hate native apps... they will always take resources away from the website which is an absolute necessity. Unless the service is app only (rare), now you have 3 separate teams working to build the same solution.
> I wish their web experience was improved on mobile. I have no interest in downloading apps of 90% of the websites I visit on my mobile browser.
Totally agree with you here. Lots of other sites link to GitHub and being pulled out of the browser and into a native app is just not a good user experience. I've uninstalled Facebook and Twitter the same reason, and I enjoy using the social sites a lot more now.
As someone that works for an organisation that develops almost 100% desktop applications and desktop form-factor web applications, I've been somewhat terrified of the new entrants into the workforce that started on phones as opposed to computers. It seems like nobody is taking their existence and eventual assumption of purchasing decision making powers seriously and I figure we'll suffer in the long-term as an organisation because of this.
I had been trying to tell myself that people still "sit down at a desktop to do work" to make myself feel better about our inaction over this it but that github is spending on mobile form factor makes me feel like I'm lying to myself about that.
What are people's general takes on this? I sway towards "in twenty years it will start to be a massive deal" but I struggle to find a convincing platform to soapbox on this to the organisation at large.
My take is that most companies don't need a native app unless they're specifically targeting mobile users and doesn't have a need for desktop users.
So you're better off generally to make the app a web app. If that doesn't work yet, are you sure about that? With web assembly and some new browser apis it's really very few apps left that actually need the native experience.
Sure if you build apps for cars, planes or something like that I understand that you want the native experience. But there is also tons of "native with an asterisk" tools like Xamarin and React Native for example.
Sure the app may be a bit larger but do users really care? With those kind of technologies you can build native for all platforms easily.
The choice really is up to the developers and there is lots of choices nowadays, thankfully.
A lot of this is legacy which is why making the argument for change is one about expense. Its about justifying the expense by selling the hot path of the use-case of using technical applications on a phone.
Everyone is sunk-cost fallacy here over the potential of mobile use-cases, they're dismissed as a use-case.
I vaguely bought into the idea for a while and now github are like:
> Review PRs and look at code on a mobile form factor
and now I'm like:
> oh, so that use-case is a thing?
I'm terrified some CTO in twenty years time of an org we want to sell it to will instantly shitcan our offering because it doesn't support mobile use-cases. Because mobile is their culture and the reason we don't value it today is _only_ because mobile isn't the culture we grew up with.
Well, you gotta follow the market, right? If they want mobile, then you'll have to give them mobile, lest they not buy from you. What is terrifying about that, except for not wanting to change?
Being a dinosaur and seeing a big fiery thing in the sky. Thinking maybe it'd be better to get a bit of a head start on that mammal business. But its hard to make that business case, isn't it? Thankfully this news makes it easier I guess.
ye, possibly. Perhaps when everyone starts out on phone/tablet then desktops will be seen as old and archaic.
I mean its a silly example but I never see people in sci-fi sit down with a mouse and keyboard. Perhaps new generations will force in new ergonomic standards?
I came to a similar realization yesterday. Many people no longer have computers at home. Instead they simply have their phone as their sole computing device.
You DO know people that dev on mobile???
Is it their primary platform or just an acceptable downgrade during in transit or "out of office". What sort of programs do they use? Do they remote into tastier machines to run beefier programs or are there a range of IDEs for mobile?
As far as I can tell, their preferred device is an iPhone 7 that they use to SSH into other machines that they run vim on, which they have told me that they do not think of as a "downgrade" from their main machine, a 12" MacBook (which presumably does the same thing).
I've never quite understood the whole "developing on my phone/tablet" thing. It's like calling my keyboard/mouse a "development machine". I'll be impressed when I see someone actually switching to their phones for development: compiling, testing and running all on the device itself.
I'm sure we'll start to get some. Surely some members of the phone generation are more devastatingly dexterous on a phone than a keyboard.
Perhaps the typical university path makes it less common? I'd imagine the autodidact path might be more likely for a new breed should the new breed even exist.
I tried out the beta version of GitHub's iOS app. I didn't find a single bug in it, and I really enjoyed using it for casually browsing code on my phone.
I would highly recommend downloading it if you sometimes take a look at GitHub repos when on your phone, which I think is most programmers.
Unfortunately I didn't use it for about fourteen days or something so my beta access was taken away :(
I love that feature too; I had to use BitBucket on a project a while back and really missed it. Now I'm using GitLab at my day job and fortunately code browsing from any commit works great from there as well.
As far as I can tell, this view is impossible to find on mobile, both on the website and through the app (yes, you can switch to the desktop website, but would it really be that hard to have one link to it on the mobile site?). It's maddening!
I immediately found display issues on an iPhone 6. I know it’s barely supported any more, but doesn’t Xcode give you the tools to make screen-independent layout? Doesn’t seem to be helping much across the apps I’ve used.
I like the GitHub for iOS app, but I've seen a number of things I wish were improved or were outright buggy and they unfortunately didn't seem very receptive of the feedback I sent them :(
Hi, thanks for reaching out! Here's a couple I've submitted to mobilefeedback@github.com:
* Repository names aren't centered to the screen; they're centered to the space left between the bar button items. This might be intentional but is somewhat strange and out-of-place on iOS.
* Repositories with "strange" licenses show up with "None" rather than "tap here to see the actual license".
* Submodules used to show up as "Something went wrong". Now they show up as "Unable to view file".
* Tabs don't actually line up to a character boundary.
Since you're here, a couple more that I haven't bothered to get around to submitting:
* There's a lot of places that could use search fields. The repositories list, the organizations list, notifications, individual repositories (i.e. code search/file search)…
* A view to see a list of commits would be nice.
* There's a text-field looking thing on my profile for a status that I cannot actually figure out how to put text into.
* It'd be nice if links had the option of opening in SFSafariViewController.
* Code viewing is a bit uncomfortable, especially on smaller screens. The font size is a tad large, line spacing is pretty big, and not being able to disable wrapping on demand is somewhat inconvenient.
* It'd be nice to be able to review multiple lines at once.
I have a bunch more but I can't really recall them at the moment, so I'll keep submitting feedback in-app and hoping that you can get around to taking a look at it. Thanks!
Thanks for this, and sorry you got bumped from the beta. We're still actively shipping to our beta and if you'd like to rejoin please just email me (bio).
I don’t understand why this couldn’t be a mobile site. Usually native mobile apps are a subset of the desktop site. Many lag in features and the apps get abandoned since their teams get re-orged.
GitHub, you could have shown the world what a truly responsive and progressive website GitHub is.
I second this, considering the fact that the two platforms have an equivalent feature set, there's also Drew Devault's platform: source hut (I think) which seems very good.
> I'm not installing a stupid app so Microsoft can collect data on me.
This is going far off topic, but I am currently consulting with a client that requested using Visual Studio Community Edition [2019] for the project. I was a month into development, when all of a sudden one morning, it was no longer possible to start Visual Studio. Why? Because I had not connected it to my Microsoft account, of course... I wonder how people put up with this..
Well in that case you are using a cloud-based service, it makes sense that you have to authenticate. But I was writing and building C++ code just fine locally, and I could have continued doing that if it wasn't for the dark pattern.
I personally prefer Octodroid. When last I used Fasthub, it felt more ~~polished~~ snazzy but in terms of actually use there was just way too much navigation chrome on the screen. It didn't get out of my way and let me engage with the content. That said, this was a couple years ago and it may have changed.
I can't recommend Octodroid enough. Been using it for years, and it already does all this stuff. It's easily the most well designed and engineered app on my phone.
I'm not even going to bother checking out this official app because Octodroid is perfect.
Why not open source it? It's code that runs on my phone, not on their servers. I have no reason to download an app that could just be a well designed web site. It being closed source makes me very suspicious of it. What does GitHub have to hide? It's not like the app is some breakthrough innovation.
...I mean that is true of a lot of apps on the App Store right now, I don't think developers are under any impression that they have to make every app open source.
True. This is why I don't install any apps. And you would think a company who's business model revolves around open source would be more likely to open source their app.
Does their business model revolve around open source? It seems to be the opposite. I don't have to pay anything to host open-source repositories. We get free repos now too, with caveats though.
I think an analogous questions would be, Does Google's ad business revolve around search? I expect most would say yes. They don't make any direct money off of organic links, but those are what drive millions of eyeballs to their ads every day.
Being the go-to place for open source code is what leads a lot of people/companies to GitHub's paid offerings.
Could someone explain to me why would anyone use GitHub on their phones rather than on a desktop computer? I can't seem to come up with a situation in which I'd reasonably need to interrupt anything I'm doing in order to check GitHub on my phone.
I was out of country without my workstation laptop and the company I was working for encountered the biggest fire of its relatively short existence, causing an all-hands-on-deck situation. In a pinch I helped by changing an nginx configuration and scaling settings on a mission-critical service from my phone in order to be more accepting of exceptionally-long request timeouts while the company chased down the root cause.
Nowadays I have slack on my phone and click links to open PRs occasionally.
Let’s set aside the word “need” and just go with “want.” Sometimes I want to use GitHub on my phone because I’m in bed and want to read over some code, or I’m on the bus to work in the morning and I want to get a head start on a PR a coworker sent me. I don’t really understand why GitHub is a crazier thing to do on one’s phone than, well, anything else really.
Seems like that, yeah. But again, I believe your issue is related to some non-optimized content for mobile. Perhaps the thing that crashes is syntax highlighting script, whereas on mobile they have something native. (just a guess..)
Definitely recommend installing the app by clicking on the link in the blog. The App Store’s search is so terrible that it’s basically impossible to find this by searching for “GitHub”.
I'm trying this out for code review on public transit.
My use case is that I batch a few small code reviews for the end of the day, and check on the status of some larger reviews that doing early reviews or working through edits.
I've previously been using the website on a mobile web browser, but it's not mobile optimized so touch points are fiddly, views need to be adjusted, long lines are hard to read, and I need to be wary about losing connection when adding a comment. Complex reviews sometimes take review of code in other files, jumping back and forth, so the mobile experience is lacking.
First impression is that the contrast for the red/green highlights seems a little low. I may just not be used to the color scheme though.
I'm having trouble understanding the use case here. If someone submits a pull request, don't I have to review that in a dev environment? Same for downloading / trying out a project. What is the utility of having access via mobile?
For a small change set with CI that runs automatically against PRs for both the branch and the result of the merge, I think this is a useful and safe option to quickly review something. Similarly if you do a lot of your project management through GitHub, having the ability to file and track issues from your phone is nice.
Thanks for this feedback, giving people more options for push notifications is on our roadmap! Including letting you set schedules for when you can receive them.
The single biggest gripe I have with GitHub on Android is that when I click on a GitHub link to a new repo, it asks if I want to open the repo in Chrome or GitHub. This happens for every. single. repo. I think they messed up their URL intent handler such that each repo counts as a different intent. It's super annoying.
Android recently rolled out a change which sometimes requires you to update the preference to "Always open *.com links in this app" in the application page in the system settings dialog. This might be what's causing this issue.
I'm not able to log in on Android. This is what I did:
1. click the install button in Google Play the app
2. open chrome and continue browsing HN
3. come across an HN post that's hosted on GitHub, and click on it
4. When prompted, tell Android that I always want to open GitHub links in the GitHub app
5. When the app opens, tap the sign in button
Expected: a form to enter my username
Actual: app disappears and I'm back at the launcher
Tried this to fix it:
- force quit the app
- clear storage and cache
Didn't work.
What I guess is happening: GitHub app is trying to redirect me to the system browser to log in, but Android intercepts the link as it's on the GitHub.com domain, so should be opened by the GitHub app. But around that time, the GitHub app decides it wants to background itself and wait to be reopened by an intent, once the browser completes the auth process.
I'm not all that interested in being able to use Git itself on my phone or even tablet. It's not practical, and there already exists several decent apps for doing so.
I'd much rather have Github provide an app that shows me trends and analytics that only they have access to. There are (or were) a few sites and apps that provided a way to see most starred repos by various criteria like all-time vs last week, language, company, search term, etc., but they're hit or miss, and often die when Github changes their API.
Not only is it very helpful for my career, but I also personally enjoy seeing what is becoming very popular out there, and what I might be able to use on future projects.
I think Github is missing out on some money if they don't end up monetizing their knowledge of what projects are most popular (beyond just stars and forks) - any project lead or architect who is still using sales teams, marketing, etc. to decide on what tools and frameworks to use is going to be left in the dust by the ones who keep up to date on what's trending at Github, especially for higher level projects related to Kubernetes, clustering, DB scaling, etc.
I find GitHub's app strategy incredibly bizarre: On the desktop, where there are tons of git clients already (not to mention the command line) GitHub's app is just another git client. Here I'd expect them to emphasize their social features because that's what would differentiate it from other git clients, and it's what differentiates their entire product from other git hosts.
Then on mobile, where there's very little git client competition, pretty much just Working Copy, they don't make a git client, and instead emphasize the social features...
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.
Interesting! I was thinking that GitHub had moved away from native mobile apps. Source code for the old GitHub Android native app: https://github.com/github/android
I'm not able to log in on Android. Clicking "Sign in" opens browser (Firefox Preview in my case) where I get the standard GitHub login flow with 2FA. But after logging in it goes back to app and the Sign in button is still there and nothing happens.
Installed it on iOS to try it out. Soon after, browsing HN on Safari I click on a link to an interesting-looking repo, which switches me to the GitHub app and shows me the raw text of the readme.md. Uninstalled it straight away.
What's the problem with that, or what do you expect? GitHub mobile web truncates the README so you'd have to click twice (which always annoyed me about GitHub mobile web!).
I would expect it to show me the readme rendered, same as visiting it in a browser does. There didn’t appear to be a way to show it rendered at all either. Which is a massive problem if it’s going to hijack my browser so I cannot see it rendered at all from my mobile.
I use the main site on mobile. My browser, Opera, automatically makes the site "responsive" when I zoom in. The main Github repo view is very well designed.
This is probably links within the readme (like #installation in a table of contents). Known problem that we didn't get to fixing, but we're going to fix this soon. Thanks for the report.
Not really ironic in either way... Github's features themselves are not open-source, and not sure if their desktop apps are open either.
I try not to do too much on my phone regarding Github, I feel like anything with lots of what should be preformatted text on a phone is just horrible in general.
It appears that Facebook for programmers now has an official app which has finally surfaced on the App Stores.
However, this may be terrible news for other third-party apps since Apple, Microsoft and Github can work together to forcibly shut down any unauthorised clients with legal action due to this release.
Well, I see no third party apps for having a full client for Snapchat, Instagram, Facebook or Discord at least on the iOS App Store due to this rule [0], but I certainly won't be surprised if they do the same for Google Play if they succeed on the App Store with Apple.
GitHub can easily file a complaint and Apple will happily remove any infringing app off of the App Store.
> If your app uses, accesses, monetizes access to, or displays content from a third-party service, ensure that you are specifically permitted to do so under the service’s terms of use.
GitHub provides an API to access all of these things.
True, but the same was said for Instagram and Twitter. They both still have a public API for developers and then cracked down on the third-party apps and clients on the App Store with a policy change. Sure, developers can still use these public APIs as long as they don't release an app that is a full clone of their official apps.
If Instagram, Snapchat, Twitter and Discord can draw the line on third-party clones, with the release of the official GitHub apps, they can also do this too.
Crazy to me that they've released this without a way for organizations to disable using it with private repos... in no way shape or form do I want engineers using this app to access company IP on their personal phones.
For example, I do quite a few code reviews on my Pixel 2, but what drives me crazy is that the lines in the diffs wrap! On top of that, the code font it uses is pretty large, so wrapping happens often and makes reviewing much harder.
The support for per-commit code review (which is only so-so in the desktop web experience) is even harder to use on mobile.
The main activity feed from / is nowhere to be seen, even though this is something I use daily on my laptops (long-standing pet peeve, since this is also non-existent in the mobile web view).
If you follow a link to particular issue comment (for example, from the bottom of a notification email), the Android app will just land you at the top of the issue.
So, having the app is an improvement over the mobile web experience (particularly since the PR review approval button was impossible to hit in the mobile web view without zooming), but IMO there's still a lot to be done here, and I hope they keep executing on it.