Dictating Code in Xcode: A Voice Workflow for iOS and macOS Developers

You can't dictate Swift. But you can dictate everything around Swift — and it turns out that's a surprisingly large fraction of the words a developer writes in a day. Code comments, commit messages, PR descriptions, documentation strings, Slack threads with teammates, Linear tickets, README files: none of this is code, all of it is prose, and all of it can be dictated faster than typed.

This is a workflow guide for iOS and macOS developers using Xcode who want to use voice dictation without disrupting their development environment. It covers what to dictate, what not to dictate, how to configure the experience for technical vocabulary, and how to integrate it into the standard Xcode + Git + GitHub flow.

---

What Developers Actually Dictate (and What They Don't)

The mental model that stops most developers from trying voice dictation is: "I'd have to dictate variable names and braces." You don't. The most productive approach is to dictate prose and type code — and use each for exactly what it's good at.

Dictate these:

• Code comments (// This handles the edge case where...)
• Documentation strings (/// Fetches the user profile from the cache if available, otherwise...)
• Commit messages (git commit -m "..." — the message, not the command)
• PR titles and descriptions
• Inline TODO / FIXME / MARK: notes
• README sections and documentation pages
• Error messages and user-facing strings in LocalizedStringKey
• Slack messages, Linear tickets, GitHub issue descriptions
• Terminal commands you know by heart but are slow to type

Don't dictate these:

• Swift syntax (guard let, @Observable, generics)
• Symbol names you haven't trained into your custom dictionary
• Multi-line code blocks
• Anything where exact spelling matters and the cost of a correction exceeds the savings

Once you internalize this boundary, the mental overhead disappears. Cursor in the comment? Dictate. Cursor in the function body? Type.

---

Setting Up Your Custom Dictionary

The single highest-leverage setup step for developer dictation is building a custom dictionary. Without it, Whisper will guess at technical terms and get them wrong — UIKit becomes "you I kit," SwiftUI becomes "swift you I," and your framework names are mangled in documentation strings.

ParlaParla's custom dictionary feature lets you define corrections: "when I say X, insert Y." For iOS and macOS development, start with these categories:

Apple framework names:

• "swift UI" → SwiftUI
• "UI kit" → UIKit
• "app kit" → AppKit
• "core data" → Core Data
• "core ML" → Core ML
• "vision framework" → Vision
• "combine framework" → Combine
• "swift data" → SwiftData

Common Xcode terms:

• "xctest" → XCTest
• "xcode cloud" → Xcode Cloud
• "test flight" → TestFlight
• "app store connect" → App Store Connect

Your project's domain vocabulary: Product names, internal service names, class prefixes your team uses. These are the ones that matter most for documentation accuracy and are impossible for any generic model to get right without training.

Build this list incrementally — spend five minutes after each session adding the terms that were transcribed incorrectly. Within a week, accuracy on technical content will be dramatically better.

---

The Commit Message Workflow

Commit messages are where most developers notice the biggest time savings from dictation. The average commit message is 8–15 words — short enough that typing feels negligible but long enough that voice is consistently faster, and the quality of your commit history improves because the friction of writing a good message decreases.

The workflow:

1. Stage your changes in Xcode's Source Control navigator (or the terminal)
2. Open the commit dialog or your terminal commit line
3. Hold Fn, dictate the commit message, release
4. Text inserts at cursor — review, adjust if needed, commit

If you follow Conventional Commits, dictation works naturally: "feat colon add offline cache for user profile" → feat: add offline cache for user profile. The colon may need a manual keystroke depending on your AI enhancement settings, but the body of the message dictates cleanly.

For longer commit descriptions with bullets, use full Polish mode or a custom prompt. A custom prompt like "Format as a git commit message with a concise subject line followed by a bullet list of changes" will structure your rambling verbal description into a clean, conventional commit.

---

Xcode DocC Documentation Strings

DocC documentation strings are one of the highest-value dictation targets in Xcode. They're entirely prose, they benefit from complete sentences, and they're easy to skip when you're in flow — which means most developers write them in a rushed batch at the end, or not at all.

The voice workflow changes this. Position cursor just above the function signature, dictate the documentation string in full sentences, and let AI cleanup mode handle punctuation. For a function like:

/// Fetches the cached user profile for the given identifier.
/// Returns nil if the identifier is not found or if the cache has expired.
/// - Parameter identifier: The unique user ID to look up.
/// - Returns: The cached UserProfile, or nil if unavailable.
func cachedProfile(for identifier: String) -> UserProfile?

You dictate something like: "fetches the cached user profile for the given identifier returns nil if the identifier is not found or if the cache has expired parameter identifier the unique user id to look up returns the cached user profile or nil if unavailable."

The DocC syntax (///, - Parameter:, - Returns:) you type manually or via a snippet — it takes two keystrokes. The prose content dictates cleanly.

---

Pull Request Descriptions

PR descriptions are where developer dictation pays the biggest return. A well-written PR description — context, what changed, why, testing approach — typically takes 5–10 minutes to type and gets abbreviated because of that cost. Voice cuts that to 60–90 seconds.

The natural workflow: after pushing your branch, open the GitHub PR creation page (or the Linear PR field), hold Fn, and walk through your changes verbally:

"Added offline caching for user profiles. The main change is in ProfileRepository where we now check the cache before making a network request. Cache TTL is 24 hours, configurable via FeatureFlags. The cache is keyed by user ID and stored in Core Data. Testing: wrote unit tests for the cache hit and miss cases, tested manually with airplane mode."

With Full Polish mode active, this arrives as formatted prose with proper punctuation. With a custom prompt set to "Format as a GitHub PR description with a Summary section and a Testing section," it arrives as a structured markdown document.

The quality of your PR descriptions will improve noticeably — not because your voice generates better text, but because speaking is lower-friction than typing, so you include more context.

---

Linear, Jira, and GitHub Issues

The same logic applies to issue descriptions. A good bug report has: reproduction steps, expected vs. actual behavior, environment details, and any relevant context. Most bug reports are abbreviated because writing all that out takes time. With voice dictation, a complete bug report takes about the same time as an abbreviated one.

Dictation also makes it easier to file issues in the moment — when you notice something buggy mid-session, hold Fn, describe what you observed, and have a filed issue in 30 seconds without breaking your flow. The alternative (context-switching to write a ticket later) means many bugs go unfiled.

---

Terminal Integration

ParlaParla works in Terminal.app and iTerm2 — it inserts text at cursor the same way it does in every other app. This means you can dictate commands directly into the terminal prompt.

Caveats:

• Long commands with flags are error-prone — --force-with-lease is a mouthful and Whisper may mis-transcribe it
• Commands you type from muscle memory are probably faster to type than to dictate
• Commands you have to think about — complex git log filters, jq pipes, awk patterns — can be dictated and corrected faster than composed from scratch

The most reliable terminal use case is dictating arguments to commands you know: git commit -m "", then dictate the message. Or git checkout -b "", then dictate the branch name following your team's naming convention.

---

Using the Translation Feature for Multilingual Teams

If you work with a distributed team where code comments or documentation need to be in a second language — German, Spanish, French — ParlaParla's translation mode lets you dictate in your native language and receive text in the target language.

Speak in English, write German documentation. Speak in Danish, write English commit messages. This is Whisper's translation feature: the same model that transcribes 57 languages can translate as it transcribes, inserting text in a different language than the one spoken.

Setup: select Translation in the AI enhancement dropdown, then choose the output language. Everything else works identically.

---

AI Enhancement Modes for Code Contexts

ParlaParla offers five AI enhancement levels, and the right one depends on context:

• Raw — verbatim transcription with no corrections. Good for dictating exact strings, error messages, or localized text where you want precise control.
• Light cleanup — fixes filler words and obvious errors. Good for commit messages and TODO comments where you want natural-sounding text but not heavy transformation.
• Full polish — produces clean, complete sentences. Good for PR descriptions, documentation strings, README content.
• Custom prompt — you define the transformation. Good for format-specific outputs: "Format as a conventional commit message," "Write this as DocC markdown with Parameter and Returns sections," "Format as a Linear ticket description."
• Translation — transcribes in one language, inserts in another.

For most developer contexts, Light cleanup handles commit messages well, and Full polish handles documentation and PR descriptions. Custom prompt is worth setting up once for your most common structured formats.

---

A Typical Developer Session with Dictation

Here's what a realistic 2-hour development session looks like with voice dictation integrated:

1. Start of session: dictate the day's plan into a notes file or Linear comment — 30 seconds instead of 2 minutes
2. During coding: when you add a code comment, hold Fn, dictate the comment, release — stays in flow, no mode switch
3. After a logical unit of work: stage changes, dictate commit message — 15 seconds
4. Notice a bug mid-session: hold Fn, dictate the issue description into GitHub — 30 seconds, filed, back to work
5. End of session: write the PR description verbally — 90 seconds for a complete, well-structured description
6. Slack standup update: hold Fn, summarize what you did and what's next — 20 seconds

The total time spent dictating in a 2-hour session is maybe 5 minutes. The words produced in those 5 minutes would have taken 15–20 minutes to type — and the quality is often better because speaking reduces the friction of writing complete thoughts.

---

Setup Checklist for Xcode Developers

1. Install ParlaParla from the Mac App Store and add your OpenAI API key
2. Set the global Fn shortcut — hold to record, release to insert
3. Add your project's framework names to the custom dictionary (SwiftUI, UIKit, your app name, key class names)
4. Set up two enhancement modes: Light cleanup as default, one Custom prompt for PR descriptions
5. Try it first on commit messages — lowest risk, immediate feedback on accuracy
6. Expand to DocC strings and PR descriptions once you're comfortable with the flow

The whole setup takes about 10 minutes. The payback in reduced typing friction shows up within the first session.

---