Alex: Welcome back. Today we're taking GitHub off the big screen and into your hand with GitHub Mobile on iOS and Android.

Jamie: I like this topic because mobile GitHub can sound like a compromise. Like, sure, I can check something quickly, but can I actually do useful work there?

Alex: You can, as long as you pick the right kind of work. GitHub Mobile is good for issues, pull requests, notifications, code browsing, and lightweight code review. It is not meant to replace every desktop workflow, but it can keep you connected when a review request, mention, or issue update needs attention.

Jamie: So install first, then learn what belongs on mobile and what should wait for the web or desktop.

Alex: Exactly. On iPhone or iPad, get GitHub from the App Store. On Android, get GitHub from Google Play. After you install it, sign in with your GitHub account, and seriously consider enabling notifications when the app asks, because that is one of the places mobile really shines.

Jamie: And once you're in the app, the main map is the bottom tab bar, right?

Alex: Right. There are five main tabs: Home, Notifications, Explore, Pull Requests, and Profile. Home is your personalized activity feed, Notifications is where mentions and review requests land, Explore helps you discover repositories, Pull Requests gathers PRs connected to you, and Profile has your account, repositories, stars, and settings. Low vision learners should also know that GitHub Mobile respects system text sizing, supports dark mode through system or app settings, and uses smaller-screen layouts instead of trying to copy the desktop page exactly.

Jamie: Let's start with iOS. If someone is using VoiceOver, how do they get oriented without feeling like the app is just a wall of unlabeled stuff?

Alex: First, turn on VoiceOver the way you normally would. On many iPhones, triple-click the side button; on older models, triple-click the Home button. You can also go through Settings, Accessibility, VoiceOver, and turn it on there.

Jamie: Once VoiceOver is on, are the gestures the usual ones?

Alex: Mostly, yes. Swipe right to move to the next element, swipe left to move to the previous one, and double tap to activate what has focus. A two-finger swipe up reads from the top, a two-finger tap pauses or resumes speech, a three-finger swipe left or right can move between screens, and the two-finger scrub gesture, like drawing a Z, goes back.

Jamie: The rotor is the part a lot of people know exists but forget to use. Where does it help in GitHub Mobile?

Alex: Open the rotor by rotating two fingers on the screen as if you're turning a dial. In GitHub Mobile, Headings can jump through sections in an issue or pull request, Links can move to linked issues, commits, or web pages, Form Controls can help you land on a comment field, and Actions can expose choices like assign, label, or close when those actions are available.

Jamie: And for writing a comment, the basic flow is find the field, open it, type, and submit?

Alex: Yes. Swipe to the comment field, or use the rotor set to Form Controls if that is faster. Double tap to activate the field and open the keyboard, type or dictate your comment, then swipe to the Comment button and double tap. I usually recommend listening for the confirmation after submitting, because mobile screens can change quickly.

Jamie: Android has a similar story, but TalkBack has its own feel. How should someone start there?

Alex: Turn on TalkBack from Settings, Accessibility, TalkBack. If the shortcut is enabled on your device, holding both volume keys for about three seconds can also toggle it. Once TalkBack is on, you can move through GitHub Mobile with swipe gestures or by exploring the screen with a finger.

Jamie: Explore by touch is important on a phone. Sometimes you want to feel where the bottom tabs are instead of swiping through everything.

Alex: Exactly. Swipe right to move to the next element, swipe left to move to the previous one, and double tap to activate. Swipe up then down to scroll down, swipe down then up to scroll up, and swipe right then left to go back. A two-finger swipe down reads from the top, which can help when you open a new issue or PR and want the page context.

Jamie: Where does the TalkBack menu come in?

Alex: Open it with a three-finger tap, or with the gesture your device uses, often swipe down then right. From there you can change reading granularity, such as character, word, line, or paragraph, use reading controls, and copy text. For comments, find the field where TalkBack says something like "Edit text, double tap to edit," double tap, type with the keyboard or dictation, then find the Comment button and double tap to submit.

Alex: Notifications may be the best reason to keep GitHub Mobile installed.

Jamie: Because the mobile inbox is more linear than the web version?

Alex: Yes. The Notifications tab presents activity in a vertical list, and each row gives you context like repository, notification type, and title. Screen reader users can move through items one by one, and low vision users get system-sized text plus unread indicators, usually a blue dot on the row.

Jamie: What about triage? I don't want to open every notification just to clean up my inbox.

Alex: You don't have to. Swipe left on a notification to reveal quick actions like Mark as read, Archive, and Unsubscribe. Swipe right to mark something as done, and tap a notification when you need the full issue or pull request.

Jamie: And filtering is there too?

Alex: Yes. Use the filter icon near the top right of the Notifications tab. You can narrow by type, like issues, pull requests, or releases; by repository; or by reason, such as mentioned, review requested, or assigned. With VoiceOver or TalkBack, those filter controls are reachable as form controls, so open the panel, move through the options, and activate the filters you want.

Jamie: Pull requests on a phone feel risky to me. I can imagine approving something and later realizing I missed half the diff.

Alex: That is a fair concern. Mobile is best for quick PR work: checking status, reading a short description, approving a small change, or leaving a focused comment. If the change is large, security-sensitive, or depends on running the project locally, move to desktop or the web.

Jamie: When you open a PR in the app, what landmarks should you listen for?

Alex: A pull request is organized into sections such as Description, Commits, Files changed, and Checks. VoiceOver and TalkBack can announce these as headings, so use heading navigation when it is available. Description gives the PR body, Commits lists the commits, Files changed shows the diff, and Checks reports CI or automated test status.

Jamie: And leaving a review is not the same as just posting a comment, right?

Alex: Right. Move to the Review changes button and activate it. Choose Approve, Request changes, or Comment, add an optional review comment in the text field, and then activate Submit review. If you only write a regular conversation comment, that may not count as a formal review.

Jamie: How readable are diffs on a small screen?

Alex: The app uses a simplified single-column diff view in Files changed. Additions and removals are text-only rather than a wide two-column table, and screen readers generally announce lines as added or removed. Sighted users may see additions in green and removals in red, but you should not rely on color alone; listen or look for the added and removed labels.

Jamie: Issues are the other big workflow. Can you file an issue from mobile without fighting the interface?

Alex: Yes, especially for a clear, compact report. Navigate to the repository, open Issues, then use the plus button or New Issue. Fill in the title and body, and if the repository supports it, you may also choose labels, assignees, or a milestone.

Jamie: And finding your own issues?

Alex: You can find issues through repository issue lists, notifications, mentions, or the places in the app that collect activity connected to you. For a learner, a good mobile habit is to open the notification, read the issue title and latest comment, decide whether action is needed, and only then reply. That keeps you from typing into the wrong conversation.

Jamie: What about reading code? Is that realistic on a phone?

Alex: It is realistic for browsing, not for heavy editing. You can open a repository, move through folders and files, read small files, check a README, or confirm that a file exists. For longer source files, complex navigation, or anything where indentation and surrounding context matter, desktop tools are still safer.

Jamie: So where would you draw the line between mobile and desktop?

Alex: Use mobile for staying current and making small decisions. Notifications, quick issue replies, short PR reviews, checking CI status, scanning a README, and following a link from a mention are all good mobile tasks. It is also convenient when you are away from your desk and need to unblock someone.

Jamie: And desktop or web when the work needs more room.

Alex: Yes. Use desktop or the web for large diffs, multi-file reasoning, branch management, resolving conflicts, editing several files, running tests, or comparing behavior across tools. The phone is a strong companion, not the whole workshop.

Jamie: What accessibility limitations should people expect today?

Alex: Some screens can still be inconsistent. A screen reader might skip part of a PR description, a notification badge may not be announced reliably, the keyboard can cover a comment field, and small-screen diffs can still be tiring. Also, mobile apps change often, so if a label or button moves, use the current GitHub Mobile docs and the GitHub Mobile changelog as your source for the latest behavior.

Jamie: Let's talk fixes. If VoiceOver skips part of a PR description, what can someone try before giving up?

Alex: Use heading navigation to move away and back, try reading from the top with a two-finger swipe up, or open linked content in the browser if the app view is not reading well. If the PR is important and the description is not reliable on the phone, switch to the web before reviewing.

Jamie: What about TalkBack not announcing a new notification badge?

Alex: Open the Notifications tab directly and refresh or move through the list rather than depending only on the badge. For a keyboard covering the comment field, dismiss and reopen the keyboard, rotate the device if that helps, or move focus back to the edit field and review what you typed before submitting.

Jamie: I have also seen people write a review comment and then not find the submit button.

Alex: That happens. Move through the review panel slowly, use form or control navigation if your screen reader supports it, and listen for Submit review rather than just Comment. If the app freezes or crashes, force close it, reopen it, check for an update, and if sign-in or state seems broken, sign out from Profile and Settings and sign back in.

Jamie: So the takeaway is not, do everything on mobile. It is, know which GitHub jobs fit in your pocket.

Alex: Exactly. GitHub Mobile is excellent for awareness, quick responses, lightweight review, and code lookup. When the task needs deep context, lots of files, or careful testing, move back to a larger workspace. Used that way, the phone becomes part of an accessible contribution workflow instead of a frustrating backup plan.