Mac Dictation Not Working in Xcode? 10 Fixes That Work

Short answer: If dictation works in other Mac apps but not in Xcode, click inside the source editor so the cursor is blinking in a comment, not in a navigator, the Find bar or the debug console. Then dismiss any completion list, fill in selected placeholders, and check Vim mode is off.

You are in Xcode, about to write a documentation comment or a commit message, and you would rather say it than type it. You press your dictation shortcut, speak, and nothing appears. Or the words appear in a search field instead of your file. Or they land in the middle of a function call and the editor fills with red errors. Or the first sentence arrives as a tidy comment and the rest becomes a line of code that does not compile. Or dictation works in every other app on your Mac and does nothing at all in Xcode.

Xcode is not a document. It is a window full of separate panes, most of which are not text at all, wrapped around a source editor that reads everything you type as code. Dictation, whether it is Apple's or a dictation app's, delivers text to whatever has keyboard focus, as if you had typed it. Xcode then does what it always does with typed text: it offers completions, replaces placeholders, closes brackets, re-indents lines and checks the result against the compiler.

So most Xcode dictation problems are about where your words landed and what Xcode did with them, not about your microphone. This guide works through every cause in order, starting with the most common one. If dictation is failing in every app on your Mac and not only in Xcode, start with our complete guide to Mac dictation not working instead.

How dictation reaches Xcode

Apple dictation is built into macOS. You start it with the dictation shortcut, usually the microphone key or whichever shortcut is set in System Settings under Keyboard, or, in most apps, from Edit, then Start Dictation in the menu bar. It sends its text to whichever control has keyboard focus. Xcode has no microphone button and no dictation setting of its own, and it does not need microphone permission for Apple dictation to work inside it.

Menu bar dictation apps, including ours, look much the same from Xcode's side. They put text at your cursor, and many of them deliver it the way a paste does. They need their own Microphone permission, plus Accessibility permission to put text into other apps, under System Settings, then Privacy & Security. Xcode itself still needs nothing.

That leaves one big rule: dictated text goes to whatever has focus, and in the source editor it is treated as code unless the cursor is inside a comment or a string. A sentence in a comment is a sentence. The same sentence one line lower is a syntax error.

The 30-second test

Before you change anything, open TextEdit, create a blank document, start dictation and say a sentence. Then go back to Xcode, open any source file, click at the end of an empty line, type two slashes and a space to start a comment, and dictate the same sentence.

• If nothing appears in TextEdit either, the problem is dictation on your Mac, not Xcode. Go to fixes 9 and 10.
• If TextEdit works but nothing appears in Xcode, even in a comment, go to fixes 1, 5 and 7.
• If your words appeared, but in a search field, a file name or the console, go to fixes 1 and 8.
• If your words arrived with extra code around them, or replaced something, go to fixes 2 and 3.
• If the first line is fine and the rest is covered in errors, go to fix 4.
• If the same text appeared in several places at once, go to fix 6.

Command-Z is your friend throughout this guide. Xcode's undo takes back dictated text like any other edit, so if a sentence lands somewhere it should not, undo it before you try to repair it by hand.

The 10 fixes, in order

1. Click inside the editor until you see the cursor

This is the cause behind most "dictation does nothing in Xcode" reports. An Xcode window has navigators on the left, inspectors on the right, a debug area along the bottom, a toolbar, a jump bar, and often a preview canvas beside the code. Only one of them has keyboard focus at a time, and it is frequently not the one you are looking at.

Clicking a file in the Project navigator opens it in the editor, but focus stays in the navigator. Letters typed there are used to select a file by name, so a dictated sentence makes the selection jump around the file list and nothing reaches your code. If a file name happens to be in rename mode, your sentence can end up as the file's new name.

Search fields are the other common hiding place. After Command-F, focus is in the Find bar at the top of the editor. After Shift-Command-F it is in the Find navigator, and after Shift-Command-O it is in Open Quickly. Each of these is a real text field and will take every word you say. The filter fields at the bottom of the navigators do the same. Dictation worked. It just filled in a search.

Click in the source editor, at the exact spot where you want the text, and look for the blinking insertion point before you speak. If you have the editor split into several panes, check that the cursor is in the pane you mean. If a SwiftUI preview is open, remember that clicking in the canvas moves focus out of the code, and in an interactive preview a text field in your own app's interface can take the words instead.

2. Dismiss the completion list, and check your completion settings

Xcode suggests completions as you type code. When a list of suggestions is open, the Return and Tab keys accept the highlighted suggestion rather than doing what they normally do. If your dictated text reaches Xcode as typing rather than as a paste, a line break in it can accept whatever suggestion happened to be highlighted, and a symbol you never asked for appears in your file. Press Escape to close the completion list before you start speaking.

Xcode also adds closing characters for you. Type an opening brace, bracket or quote in code and the matching one can appear after the cursor, so dictated text that contains quotation marks may arrive with an extra one. Both behaviours live in Xcode, then Settings, then Text Editing, in the Editing tab, under names such as "Suggest completions while typing" and "Automatically insert closing braces". If your version of Xcode offers predictive completion that proposes whole lines in grey text, that is in the same place. You can switch any of these off, but you rarely need to. They matter in code, and they mostly stay out of the way inside a comment, which is one more reason to follow fix 4.

3. Fill in or remove placeholders before you speak

When you accept a completion for a function call, or insert a code snippet or a documentation template, Xcode leaves placeholders in the text: rounded tokens that stand for an argument or a description you still need to supply. The first placeholder is selected for you, and anything typed while a placeholder is selected replaces it.

That is exactly what you want when you are filling in an argument. It is not what you want when you thought the cursor was two lines up in a comment. Your sentence replaces the placeholder and now sits inside a function call. Undo, then deal with the placeholders first, either by filling them in or deleting them, and click where you actually want the text.

Documentation templates are the helpful version of the same behaviour. Put the cursor on a declaration and press Option-Command-/ and Xcode inserts a documentation comment with a description placeholder already selected. Dictate, and your sentence replaces it, in the right place and already inside a comment. Press Tab to move to the next placeholder and dictate the next part.

4. Start the comment first, and keep line breaks inside it

Dictation does not know it is talking to a compiler. It will not type comment markers for you, and it has no idea where a comment ends. Two habits prevent nearly all of the red-error surprises.

First, type the comment marker yourself and then dictate. Two slashes for an ordinary comment, three for a documentation comment, or a // TODO: or // MARK: prefix if that is what you are writing. With the cursor after the marker, everything you say on that line is a comment and Xcode leaves it alone.

Second, watch line breaks. A comment that begins with two slashes ends at the end of the line. If you say "new line" or "new paragraph" partway through, or your dictation app delivers several lines at once, the text after the break may arrive without a comment marker in front of it, and Xcode reads it as code. That is the classic symptom: a clean first line, then a second line underlined in red. Xcode may continue a documentation comment for you when you press Return yourself, but text that arrives all at once gets no such help.

There are three easy ways around it:

• One line at a time. Dictate a line, press Return, type the marker, dictate the next.
• Comment it afterwards. If several lines have already arrived as bare prose, select them and press Command-/ to turn them all into comments in one step.
• Use a block comment. Type /* and */, put the cursor between them and dictate as many lines as you like. Everything between the markers is a comment, line breaks included.

Our guide on how to dictate code comments goes further into phrasing comments well, and our guide on how to dictate in Xcode covers the day-to-day workflow once everything is working.

5. Turn off Vim mode, or get into insert mode

Xcode has a Vim mode, switched on from Editor, then Vim Mode in the menu bar. While it is on, the editor opens in normal mode, where letters are commands rather than text: d starts a delete, x deletes a character, u undoes and i switches to typing. Depending on how your dictated text arrives, a sentence sent to normal mode can be carried out as a string of commands, and the editor jumps around or deletes text instead of adding your words.

Look at the bar along the bottom of the editor, which shows the current mode when Vim mode is on. Press i before you dictate so the editor is ready for text, and press Escape when you are done. If you did not mean to have Vim mode on at all, untick it in the Editor menu. It is an easy setting to turn on by accident and forget about, and it stays on between launches.

6. Check for extra cursors and Edit All in Scope

Xcode can edit in several places at once. Control-Shift-click adds another cursor, and dragging with the Option key held down creates a column of them. Whatever you type is then typed at every cursor, and so is whatever you dictate. If one sentence turned up on five lines, this is why.

Edit All in Scope does something similar: it selects every use of a symbol in the current scope so that you can rename them together, and while it is active, text goes into all of them. Renaming through the refactoring tools works the same way across a whole project. Symbol names cannot contain spaces, so a dictated sentence here makes a mess quickly.

Click once in the editor to go back to a single cursor, undo the stray text, and try again. If you rely on multiple cursors, get into the habit of glancing at the editor for more than one blinking line before you speak.

7. Make sure the thing you clicked can be edited

Sometimes the cursor is in the right pane, and the pane will not take text. Xcode shows several things that look like editable source and are not:

• Generated interfaces and framework headers. Jump to the definition of a system type and Xcode shows you a generated interface. You can read it and select text in it, but you cannot type in it, so dictation does nothing there.
• Locked or read-only files. A file you do not have permission to change, or one that has been locked, will refuse edits or ask whether you want to unlock it first.
• Table-style editors. Property lists, build settings, string catalogs and similar editors are grids of rows. Clicking a row selects it. You usually need to double-click a value to put it into edit mode before it will accept text.
• Interface Builder. A storyboard canvas is a layout of objects, not text. Double-click a label to edit its text in place, or use the field in the Attributes inspector.

If the insertion point is not blinking in a field, there is nowhere for dictated text to go. Put the item into edit mode first, check for the cursor, then speak.

8. Know where the debug console and the Simulator send your words

When your app stops at a breakpoint, Xcode comes to the front and focus often moves to the console in the debug area. The console is a text area, but it is not a document. While the app is paused, the console is a debugger prompt, and a line of text followed by Return is run as a debugger command. Dictate a sentence there and the debugger tells you it is not a valid command. While the app is running, text typed in the console is sent to your app as standard input. Either way, your comment did not go into your file. Click back in the source editor before you dictate.

The Simulator is a separate app with its own rules. When it is in front, your Mac's keyboard input goes to the simulated device, if the Simulator is set to use your hardware keyboard in its I/O menu, and it goes to whichever field is active in the simulated app. Dictated text from a Mac dictation app may reach that field, may take a moment to arrive, or may not arrive at all, depending on how the text is delivered and on the Simulator's keyboard and pasteboard settings. For typing test data into a simulated app this is occasionally useful. For writing code, make sure Xcode, not the Simulator, is the front app.

9. Give your dictation app its permissions, and clear what blocks it

A dictation app needs two permissions under System Settings, then Privacy & Security: Microphone, so it can hear you, and Accessibility, so it can put text into Xcode and every other app. If either is off, the app may record and have nowhere to deliver the result. After you grant a permission, quit the app and open it again, because macOS does not always apply a new permission to an app that is already running.

Next, think about Secure Input. While a password field is active, macOS stops other apps from reading or sending keystrokes, and development work produces more password prompts than most people notice: signing in to an Apple account in Xcode's settings, a keychain prompt during code signing, a sign-in dialog for a source control host. While one of those is waiting for you, a dictation app may not see its hotkey or may not be able to deliver its text. Finish or cancel the prompt and try again.

Then check the microphone. A video call, a screen recorder, or an app you are running from Xcode that records audio can keep hold of it, and dictation opens, hears nothing and gives up. Stop the app or end the call rather than muting it. If you use a headset, check which input your Mac is listening to, especially after unplugging a device or switching Bluetooth audio. Our guide to Mac dictation microphone problems covers the input side in detail.

10. Check dictation on your Mac

If dictation failed in TextEdit too, Xcode is not the problem. Open System Settings, go to Keyboard, and make sure Dictation is on. Check which shortcut it uses, and make sure the dictation language matches the language you are speaking.

Shortcuts deserve a second look for Xcode users in particular, because Xcode has a very large set of key bindings and lets you customise them in Xcode, then Settings, then Key Bindings. If you have assigned your dictation shortcut's key combination to an Xcode command, Xcode may act on it first. Our guide to a Mac dictation shortcut that is not working walks through finding conflicts.

Then restart your Mac, which clears stuck dictation services in one step. If dictation stopped working straight after an upgrade, our guide to Mac dictation not working after a macOS update covers what tends to change.

Xcode quirks that look like broken dictation

• Red errors appear the moment you speak. Xcode checks your code as you edit, so prose that lands outside a comment is flagged immediately. Nothing is broken. Undo it, or select the lines and press Command-/ to comment them.
• Holding your hotkey and clicking opens a help popover or jumps to another file. In Xcode, Option-click shows Quick Help for a symbol and Command-click acts on it. If your dictation hotkey is one of those modifier keys, click to place the cursor first, then hold the key.
• Symbol names come out as ordinary words. Dictation writes English. A method name spoken aloud arrives as separate lowercase words, not as one identifier. Type identifiers by hand, or see our guide to voice coding with camelCase and snake_case.
• A capital letter and a full stop appear where you did not want them. Dictation punctuates for human readers. In a comment that is welcome. In a string literal or an identifier it may not be, so read those back.
• The indentation changed. Xcode can re-indent text when it is pasted, according to the Indentation tab of its Text Editing settings. A dictated comment may shift to line up with the code around it. That is Xcode tidying up, not dictation misplacing your text.
• Text arrives late. During a build, or while Xcode is indexing a large project, the editor can be slow to respond. Let the text appear before you start typing a correction, or the two can end up mixed together.
• Nothing happens in the commit view. When you commit from Xcode, the list of changed files can have focus rather than the message field. Click in the commit message field, check for the cursor, then dictate.

Quick triage

• Works in TextEdit, nothing in Xcode: focus is in a navigator or another pane. Fix 1.
• Words went into a search field: the Find bar, Find navigator or Open Quickly had focus. Fix 1.
• A symbol you never asked for appeared: a completion was accepted. Fix 2.
• Your sentence is inside a function call: a placeholder was selected. Fix 3.
• First line fine, second line red: a line break ended the comment. Fix 4.
• The editor jumped around or deleted text: Vim mode in normal mode. Fix 5.
• The same sentence on several lines: extra cursors or Edit All in Scope. Fix 6.
• Cursor will not appear in the file: a generated interface, a locked file, or a row that is not in edit mode. Fix 7.
• "Not a valid command" in the debug area: the console had focus. Fix 8.
• Dictation app does nothing while a password prompt is open: Secure Input. Fix 9.
• Fails in TextEdit too: Mac dictation settings. Fix 10.

Where dictation earns its place in Xcode

Nobody should try to dictate Swift syntax. Brackets, generics and operators are faster and safer on the keyboard. What dictation is good at is everything written in sentences, and there is more of that in a project than most people expect:

• Inline comments. The reason a workaround exists, said the way you would explain it to a colleague.
• Documentation comments. Summaries, parameter descriptions and discussion sections, which are tedious to type and easy to skip.
• TODO, FIXME and MARK notes. A full, clear sentence instead of three cryptic words.
• Commit messages. A summary line, then what changed and why.
• Markdown files. A README or a documentation article is plain prose in Xcode's editor, with no code completion to work around.
• Assistant prompts. If your version of Xcode has a coding assistant panel, its prompt box is an ordinary text field, and a detailed request is far quicker to say than to type.
• Everything beside Xcode. Pull request descriptions, issue comments and review notes in your browser. Our guide to dictating pull request descriptions covers that side.

The rule that keeps all of it tidy is simple: type the syntax, dictate the words. For the bigger picture of where speaking helps with programming work, see our hub on dictation for coding.

It is worth getting right, because speaking is much faster than typing. Most adults type around 40 words per minute, and even professional typists usually sit around 80 to 100, while normal speech runs at 130 to 150 words per minute. The explanations in a codebase are exactly what people cut short when they have to type them, and exactly what the next person to open the file needs most.

Xcode versus other editors

The same principles apply in every code editor: focus decides where words go, and the editor treats them as code unless told otherwise. The details differ. Our guide to Mac dictation not working in VS Code covers that editor's panels and settings, and if you spend part of your day at a shell prompt, our guide to Mac dictation not working in Terminal covers pagers, prompts and editors that read letters as commands.

Dictation that works in every pane

Apple dictation is free and built in, but it stops after a pause, it depends on settings that are easy to switch off by accident, and fixing a misheard word means going back and editing by hand.

Voice Keyboard Pro is a menu bar app for Mac. Click where you want the text, hold your hotkey, speak, and release. The text appears at your cursor, system-wide, in Xcode's editor, in the commit message field, in your browser and in every other app you use. The microphone stays live while you hold the key, so a pause to think does not end the session. Like any dictation app, it puts text wherever focus is, and Xcode still decides what that text means, so fixes 1 to 8 still apply.

A few features help with development work in particular:

• Smart Vocabulary is a personal dictionary with replacement rules, so framework names, type names, product codenames and acronyms come out spelled your way every time.
• Meeting Mode, with speaker detection and AI notes, captures standups and design reviews, so you are not reconstructing decisions from memory afterwards.
• Calendar meeting detection notices when a meeting on your calendar is about to start.

On privacy, our servers store only operational pings. No audio and no transcript content is stored, which matters when what you are dictating describes code and systems you are responsible for. There is a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. On iPhone, the same product is a custom keyboard with a built-in mic button, so you can dictate in any iOS app too.

Frequently asked questions

Does Xcode have its own dictation setting?

No. Xcode relies on the dictation built into macOS or on a dictation app. Both deliver text to whatever has keyboard focus, and there is nothing inside Xcode to turn on.

Why does dictation work in TextEdit but not in Xcode?

Almost always because focus is somewhere other than the source editor: a navigator, a search field, the debug console or a preview. Click in the editor until you see the cursor. If the cursor is there and text still does not appear, check whether Vim mode is on or whether the file can be edited at all.

Why did my dictated comment turn into compile errors?

A comment that starts with two slashes ends at the end of its line. If your dictation included a line break, the text after it arrived without a comment marker and Xcode read it as code. Select those lines and press Command-/ to comment them, or dictate inside a block comment.

Why did my sentence appear in several places at once?

You had more than one cursor, or Edit All in Scope was active. Click once in the editor to return to a single cursor, undo, and dictate again.

Can I dictate Swift code?

You can, but it is rarely worth it. Type the syntax and the identifiers, and dictate the comments, documentation and commit messages around them. That split is faster and produces far fewer errors.

Does Mac dictation work in the Simulator?

The Simulator is a separate app. When it is in front, keyboard input goes to the simulated device, and whether dictated text arrives depends on how it is delivered and on the Simulator's keyboard and pasteboard settings. To test a dictation feature in your own app, use a real device.

What to do next

Run the 30-second test, then work through the fixes that match what you saw. For most people it is fix 1: the cursor was not in the editor, and the words went to a navigator or a search field. If your words arrived and something strange happened, it is almost always fix 2, 3 or 4: a completion, a placeholder or a line break did what Xcode told it to. And if you want dictation that stays out of your way in Xcode and everywhere else on your Mac, try Voice Keyboard Pro's free tier on your next documentation comment.