iPhone Dictation Not Working in GitHub? 10 Fixes That Work

Short answer: If iPhone dictation is not working in GitHub, tap inside the comment box until the keyboard appears, then tap the mic key. GitHub's comment boxes have no dictation of their own, and the mic lives on the keyboard. Dictated comments stay unposted until you post them or submit your review.

A lot of GitHub work now happens away from a desk. A notification arrives about a failing check or a question on your pull request, you open the GitHub app on your iPhone, and you want to answer properly. Saying the reply is far quicker than thumbing it out, which is why it is so annoying when there is no mic to tap, or your words arrive in a search field, or the careful review you dictated on the train turns out to be visible to nobody but you.

Four facts about GitHub on iPhone explain almost all of it. First, GitHub's comment boxes have no dictation of their own. On iPhone the mic lives on the keyboard, the keyboard only appears when a text box has the cursor, and most of a GitHub screen is something you read, not something you type into. Second, every comment box reads Markdown, so symbols in your text change how it looks once posted, and a few of them mention people or link issues. Third, nothing you write is visible to anyone else until you post it, and review comments wait until the whole review is submitted. Fourth, the iPhone keyboard was built for sentences, not code, and it can quietly change the quotes, dashes and capital letters that code depends on.

So most GitHub dictation problems on iPhone are about getting a cursor into the right box and making sure your words are actually posted, not about your microphone. This guide goes through every cause in order, starting with the most common. If dictation is failing in every app on your phone and not only in GitHub, start with our complete guide to iPhone dictation not working instead. The same fixes apply to GitHub on iPad.

How dictation reaches GitHub on iPhone

You can use GitHub on iPhone in two ways: the GitHub app, or github.com in Safari or another browser. Neither has a dictation button in its comment boxes. Dictation comes from the keyboard. You put a cursor in a comment box, the keyboard slides up, you tap the mic key and speak, and the words arrive at the cursor as if you had typed them. GitHub cannot tell the difference, and it applies all of its usual rules to what you said.

That gives you a simple rule for almost everything below. If there is no keyboard on screen, there is no mic to tap, and the question is why no text box has the cursor. If the keyboard is up and the mic is missing or does nothing, the question is about the keyboard and the phone. If the words arrive but come out wrong, or never appear for anyone else, the question is about what GitHub did with them. One more thing to keep apart: any row of formatting buttons sitting just above the keyboard belongs to GitHub. The mic belongs to the keyboard underneath it.

The 30-second Notes test

Before you change anything, open the Notes app, create a new note, tap in the body so that the keyboard appears, then tap the mic key and say a sentence.

• If dictation fails in Notes too, the problem is dictation on your iPhone, not GitHub. Go to fixes 2 and 10.
• If it works in Notes but there is no keyboard in GitHub, go to fixes 1 and 3.
• If Apple's keyboard took over and has no mic, go to fix 4.
• If nobody else can see what you dictated, go to fix 5.
• If the posted comment looks wrong or has words missing, go to fix 6.
• If someone was mentioned, an issue was linked or an issue closed, go to fix 7.
• If code, commands or names came out changed, go to fix 8.
• If your words went into search or the wrong box, go to fix 9.

The 10 fixes, in order

1. Tap into a comment box, not just the issue

This is the cause behind most "there is no mic in GitHub" reports. Opening an issue or a pull request shows you the conversation: the description, the timeline of comments, labels, checks and commits. All of that is for reading. The keyboard stays down until you tap into a box that takes text, and the mic is on the keyboard.

Look for the comment field at the bottom of the conversation and tap it. Depending on the screen, the first tap may open a larger composer, and you may need to tap once more inside it before the cursor appears. When the keyboard slides up, the mic is there.

A few other places work the same way:

• Line comments in a pull request. In the changed files, you comment on a particular line by tapping that line first. The comment box only appears after that.
• Replies to a review thread. A reply goes in the box that belongs to that thread, not in the main comment box at the bottom of the conversation.
• Your own description or comment. Text that is already posted is not a text box. To change it, open the menu on that comment or description, choose to edit it, and tap into the edit box.

If a word is highlighted when you start speaking, the first thing you say replaces it, exactly as typing would. Tap once more so that only the cursor remains.

2. Get a keyboard with a mic on screen

Once a cursor is in the box, the keyboard is up and the mic should be on it. If it is not, check which keyboard you are looking at. If you have more than one installed, the globe key cycles between them, and a long press on it shows the list. Apple's keyboard shows its mic when dictation is enabled. Many third-party keyboards have no mic of their own, and one that does usually needs Full Access switched on before its mic responds. Our guide to enabling Full Access for an iPhone keyboard explains what that permission does.

On iPhones without a Home button, Apple's mic sits in the bottom corner of the screen, below the keys, and it is easy to overlook under a row of formatting buttons. If Apple's keyboard is showing and still has no mic, dictation is switched off or restricted on your iPhone. Fix 10 covers the settings, and our guide to a microphone button missing from the iPhone keyboard goes through every cause.

3. Check that you can comment here

Sometimes there is no comment box to tap, and no keyboard setting will bring one back.

• The conversation is locked. Maintainers can lock an issue or pull request, and then only people with write access to the repository can comment.
• The repository is archived. An archived repository is read-only. You can read its issues and pull requests, but you cannot add to them.
• Interaction limits are on. Owners can temporarily restrict who can comment, for example to people who have contributed before.
• Your organization requires single sign-on. Until you authenticate, its private content stays out of reach, and you are asked to sign in through your organization first.
• You are using a different account. If you have a personal and a work GitHub account, check which one you are signed in with before you look for a box that only the other account can see.
• It is a picker, not a text box. Labels, assignees, reviewers, projects and milestones are chosen from lists. There is nothing to dictate into, so pick them by hand.

A new issue can also be a form. Some repositories replace the single description box with several fields, some of them dropdowns or checkboxes. Dictation only goes into the field that has the cursor, so tap into each one in turn, and watch for required fields that keep the issue from being created.

4. Get past sign-in, password and code screens

Whenever a password field has the cursor, iOS replaces any third-party keyboard with Apple's own, and dictation is not offered there. That is a security feature of the phone, not a fault in GitHub or in your keyboard. GitHub produces a fair number of these moments: signing in, a two-factor code, a prompt to confirm access before a sensitive change, and your organization's single sign-on page. A field that only takes a code may show a number pad instead, and a number pad has no mic either.

Type the password or code, finish the sign-in, and then tap back into the comment box. If your usual keyboard does not come back on its own, tap the globe key to switch to it. Our guide to an iPhone keyboard that keeps switching back to the default covers this in more detail.

5. Post the comment, and submit the review

Dictation fills the box. It does not post. This fix settles the most confusing reports, because from your side everything looks finished.

• The comment was never sent. Text sitting in the composer is a draft. Tap the button that posts it. In a comment box, Return starts a new line rather than posting.
• Your review comments are pending. When you comment on lines of a pull request as part of a review, each comment is held as pending and only you can see it. Nothing reaches your teammates until you submit the review, with Approve, Request changes or Comment and an optional summary. Reviews belong to GitHub, not to the device, so a review you started at your desk can still be waiting for you to submit it when you add to it on your phone.
• An edit was not saved. After changing an existing comment or description, save the edit. Backing out of the edit screen can discard it.
• The draft was lost. Leaving the composer, jumping to another notification or closing the app can throw away text you had not posted. Do not count on it being there when you come back.

For anything long, such as a pull request description or a detailed bug report, dictate it in Notes first and paste it in when it is ready. Whatever happens in the app, the draft survives. Our guide to dictating pull request descriptions and review comments has a workflow for exactly that.

6. Check how Markdown changed your words

Every comment box on GitHub reads Markdown, so certain characters are instructions, not text. iPhone dictation writes these characters when you say their names, and GitHub formats them by its own rules once you post.

• A line that starts with a hash sign and a space becomes a heading.
• A line that starts with a hyphen, or with a number and a full stop, becomes a list item. A spoken "one", "two", "three" at the start of lines can come out as a numbered list.
• Asterisks or underscores around words make them italic or bold, and the symbols disappear.
• Text in angle brackets that looks like an HTML tag is treated as HTML, and in most cases it is removed. A type name written with angle brackets can vanish from the posted comment.
• Anything between HTML comment markers is hidden. Many repositories pre-fill a new issue or pull request with a template whose instructions sit inside those markers. If your cursor was inside one when you spoke, your words are saved but never shown.

If a preview is offered, check it before you post. Otherwise, read the comment once it is up and edit it if something is missing. Put code, logs and error messages in backticks or a fenced code block, where nothing is formatted. On Apple's keyboard, the backtick is on the numbers and symbols layer, in the menu that opens when you press and hold the apostrophe key. Dictation is good at sentences and poor at symbols, so type or paste the literal parts and dictate the explanation around them. Our guide to dictating quotes and special characters covers how to say symbols when you do want them.

7. Watch for mentions, issue links and closing keywords

Three characters reach out of your comment and touch other people or other issues.

• The at sign. An at sign followed by a name mentions that account, if it exists, and the person may be notified. Package names and email addresses that begin with an at sign are the usual way to mention a stranger by accident.
• The hash sign. A hash sign followed by a number links to the issue or pull request with that number. If dictation writes "number 12" as a hash sign and a 12, your comment now points at issue 12.
• The colon. A word between two colons can turn into an emoji.

One rule deserves particular care. In a pull request description, the words fixes, closes or resolves in front of an issue reference link that issue to the pull request, and the issue closes automatically when the pull request is merged into the default branch. A casual spoken sentence that comes out as "fixes #12" can close an issue you never meant to touch. If a number is not an issue reference, write it without the hash sign or put it in backticks. Text inside backticks is never turned into a mention or a link.

8. Stop the keyboard changing code, commands and names

The iPhone keyboard is tuned for sentences, and GitHub is full of text that is not made of sentences. Several keyboard features change characters as they go in:

• Smart Punctuation turns straight quotes into curly ones, and a double hyphen into a single long dash, as you type. In prose that looks tidy. In a command, a flag, a JSON snippet or a line of code it breaks things, and the result still looks right at a glance.
• Auto-Capitalization capitalizes the start of each sentence and each new line, which turns a lowercase function name, branch name or command at the start of a line into something else.
• Autocorrect replaces identifiers it does not recognize with ordinary words.
• Text Replacement expands any shortcut you have set up, wherever it appears.

You can switch each of these off under Settings, General, then Keyboard. If you only write code on your phone now and then, a simpler habit is to dictate the explanation and paste the literal code from a source that kept it exact, then check the posted comment for curly quotes before anyone copies your command.

Names are the other half of this. Library names, service names and teammates' handles are the words dictation mishears most. Our guide to why iPhone dictation gets words wrong covers the causes.

9. Find words that landed somewhere else

If your words arrived but not where you meant them to, look in these places:

• The search field. If you searched for a repository, an issue or a person, the search field can keep the cursor, and your words become a search.
• The title. Issue and pull request titles are a single line. If the cursor was in the title when you started, your whole description went into it.
• A filter box. Lists of issues, pull requests and files have filters that take text too.
• A different thread. A pull request has a main comment box and a separate reply box for every review thread, and each belongs to a different place in the discussion.
• The Copilot chat. If your GitHub app includes Copilot, its prompt box is another text field, and words dictated there become a question to Copilot, not a comment.
• Safari instead of the app. A link from an email or a chat message may open github.com in Safari rather than in the app. The site works too, but it is a separate place, with its own sign-in and its own unsent drafts. Our guide to iPhone dictation not working in Safari covers the browser side.

If you dictated into the wrong box, select the text, cut it, tap into the right box and paste.

10. Free up the microphone, and check dictation on your iPhone

Dictation needs the microphone. A phone or FaceTime call, a video meeting in another app, or a recording app still running in the background can hold on to it, and dictation may refuse to start until they let go. End the call or stop the recording, then try again. If the mic key does nothing, or dictation starts and gives up at once, disconnect your Bluetooth headphones and test with the iPhone's own microphone. Our guide to iPhone dictation not working with AirPods walks through the headphone side.

If dictation failed in Notes too, check the settings. Open Settings, go to General, then Keyboard, and make sure Enable Dictation is on. If the switch is missing or greyed out, check Screen Time: under Content & Privacy Restrictions, open the allowed apps list and make sure Siri & Dictation is allowed. A work iPhone may also restrict dictation through its management profile. Make sure the keyboard language matches the language you are speaking, install any pending iOS update, update the GitHub app from the App Store, and if nothing else has worked, restart your iPhone.

GitHub quirks that look like broken dictation

• Dictation ends mid-sentence. Apple's dictation stops when you go quiet for a moment, and working out how to phrase a review involves exactly that kind of pause. Anything that puts the keyboard away ends it too, such as scrolling up to reread the diff. Our guide to why iPhone dictation keeps stopping explains what you can do about it.
• The keyboard is covering the words. In a long comment, the line you are dictating can sit just out of sight behind the keyboard. Scroll before you start, not while you speak.
• Your comments say Pending. They belong to a review you have not submitted. See fix 5.
• The whole description is blank after posting. It went inside a template's hidden comment block. Edit the description and move your text outside the markers. See fix 6.
• Every comment starts with a capital and ends with a full stop. iPhone dictation adds punctuation automatically, which suits sentences better than short commit-style notes. You can turn off Auto-Punctuation under Settings, General, then Keyboard.
• A command you posted does not run when someone copies it. Smart Punctuation turned its quotes or hyphens into curly quotes or a long dash. See fix 8.

Quick triage

• The issue is open but there is no keyboard: no cursor in a text box. Tap the comment field. Fix 1.
• Keyboard is up, but no mic: the wrong keyboard, Full Access, or dictation is off. Fix 2.
• No comment box at all: locked, archived, restricted, single sign-on or the wrong account. Fix 3.
• Apple's keyboard took over and has no mic: a password or code field. Fix 4.
• Nobody can see your comment: not posted, or part of a pending review. Fix 5.
• Headings, lists or missing words: Markdown. Fix 6.
• Someone was mentioned, or an issue was linked or closed: an at sign, a hash sign or a closing keyword. Fix 7.
• Curly quotes, long dashes or capitals in code: keyboard features. Fix 8.
• Words in search, the title or the wrong thread: fix 9.
• Fails in Notes too: the microphone or iPhone dictation settings. Fix 10.

GitHub on iPhone versus GitHub on a Mac

On a Mac you start dictation with a keyboard shortcut, not a mic key, so there is no on-screen keyboard to go missing. There, the usual trap is that GitHub treats single keys as shortcuts when no box has the cursor, so stray key presses can jump to search or open a file finder. On an iPhone without a hardware keyboard there are no single-key shortcuts to trip over, but everything runs through the on-screen keyboard, so the first question is always whether a keyboard appeared at all, and password screens switch you to Apple's keyboard. The rest carries across: Markdown, mentions, closing keywords and pending reviews behave the same everywhere, because they are part of GitHub and not of the device. Our guide to Mac dictation not working in GitHub covers the desktop side.

If your team tracks work in other tools as well, the same kinds of problems turn up there with their own twists. We have guides to iPhone dictation not working in Jira and in Slack.

A dictation workflow that suits GitHub on a phone

• Speak the why, type the what. Dictate the explanation, the reasoning and the question. Type or paste the identifiers, numbers and code. Each method does what it is good at.
• Use the phone for triage. A phone is well suited to clearing notifications: a quick answer, a request for more detail, a thank-you on a merged fix. Save long design discussions for when you can see the whole diff.
• Know which kind of comment you are writing. A plain comment in the conversation is visible as soon as you post it. If you start a review, remember to submit it.
• Read it back once. A quick pass catches a misheard library name, an accidental mention or a curly quote before your teammates see it.

It is worth getting right, because speaking is much faster than typing. Most adults type around 40 words per minute on a full keyboard, and even professional typists usually sit around 80 to 100, while normal speech runs at 130 to 150 words per minute. On a phone keyboard the gap is wider still. A bug report with the steps, the expected result and what you have already ruled out is exactly the kind of writing that gets cut short on a phone, and exactly the kind that is easy to say. Our guide to dictating bug reports has a structure that works well out loud, and for the basics, see how to dictate in GitHub.

A keyboard with a mic for every repository

Apple's dictation is free and built in, but it stops when you pause, it depends on settings that are easy to switch off by accident, and fixing a misheard word on a small screen means selecting and retyping by hand.

Voice Keyboard Pro is a custom iPhone keyboard with a built-in mic button for dictation in any iOS app, the GitHub app included. Tap into a comment box, tap the mic and speak, and your words are added at the cursor. Because it is a keyboard and not a feature of one app, it works the same way in the GitHub app, on github.com in Safari, in Slack and everywhere else you type. Like any keyboard, it only appears once a text box has the cursor, and iOS swaps it for Apple's keyboard in password fields, so fixes 1, 3 and 4 still apply. GitHub still reads what arrives as Markdown and waits for you to post it, so fixes 5 to 7 apply too.

A few features help with code review in particular:

• Voice Edit lets you speak a change to fix text, so you can correct a misheard library name without selecting and retyping it on a small screen.
• Two-way translation while dictating, across 24 languages, lets you speak in one language and write in another. That helps if you contribute to a project that discusses everything in English and you think more easily in another language.
• Swipe typing is there for short replies and for the moments when speaking out loud is not practical, such as a quiet office or a meeting that is still going.

Setup means adding the keyboard in Settings and allowing Full Access so that it can reach the transcription service. On privacy, our servers store only operational pings. No audio and no transcript content is stored, which matters when an issue describes an unreleased feature or a security problem. There is a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. On a Mac, the same product lives in your menu bar: hold a hotkey, speak, release, and the text appears at your cursor in GitHub or anywhere else, with Smart Vocabulary to keep your project's names spelled the way your team writes them.

Frequently asked questions

Does the GitHub app have voice typing?

Its comment boxes have no dictation button of their own. You dictate with the mic on your iPhone keyboard, which types into whichever box has the cursor, exactly as if you had typed the words.

Why is there no keyboard when I open an issue?

Opening an issue or a pull request shows the conversation, which is for reading. The keyboard only appears when you tap into a text box, such as the comment field at the bottom. Tap it, and the keyboard and its mic slide up.

Why can't anyone see the review comments I dictated?

They are part of a review that has not been submitted, so they are pending and only you can see them. Submit the review, and they become visible to everyone.

Does the GitHub app need microphone permission for dictation?

No. Dictation belongs to the keyboard, not to the app, so the GitHub app does not need access to the microphone for you to dictate a comment. If the mic key is missing, check the keyboard and your iPhone's dictation settings.

Why did a command I posted from my phone stop working?

Smart Punctuation probably turned its straight quotes into curly ones, or a double hyphen into a long dash. Edit the comment, retype those characters with Smart Punctuation off, and put the command in backticks or a code block so it is shown exactly.

Does this work the same way on iPad?

Yes. GitHub on iPad works the same way, so every fix here applies. With a hardware keyboard attached, the on-screen keyboard may stay hidden, and github.com in a browser can react to single key presses the way it does on a Mac.

What to do next

Run the 30-second Notes test, then work through the fixes that match what you saw. For most people it is one of the first five: no cursor in a comment box, the wrong keyboard, a conversation you cannot comment on, a password screen, or a comment that was never posted. If the comment is up but looks wrong, check the Markdown, the mentions and the quotes. And if you want dictation that works the same way in GitHub and every other app on your phone, try Voice Keyboard Pro's free tier on your next review.