Short answer: Xcode is macOS only. Put the cursor in a /// DocC block, TestFlight What to Test, App Store Connect release notes, or the Coding Intelligence chat, press ⌃+⌥+R, speak, press again. AICHE inserts cleaned text at the cursor. There is no Windows or Linux Xcode build; this page is Mac-only.
The Problem
Xcode is the only way to ship for iOS, macOS, watchOS, tvOS, and visionOS. The editor is fast, the symbolic links are great, and the Coding Intelligence panel can write routine Swift with connected AI models. What it does not do is write your DocC comments, your TestFlight What-to-Test notes, your commit messages, or your prompts to Claude, GPT, or a local model inside the Intelligence panel. Those are still your job, and they still happen at typing speed.
A SwiftUI view with five subviews and three state branches deserves a real /// comment that renders properly in Quick Help. A submitted TestFlight build deserves notes that tell the tester what to actually exercise. A prompt to the Coding Intelligence assistant deserves enough context to land good code on the first pass. None of that gets written when each one means three minutes hunched over the keyboard inside a tiny comment block.
What Changes
Speaking lands at around 150 WPM. Typing is closer to 40. A 200-word DocC block that takes five minutes to type takes about 80 seconds to speak. The Intelligence prompt you would have shortened to save typing time becomes the full-context version, which lands better Swift on the first try.
The workflow:
- Open your project in Xcode.
- Put the cursor where the text should land - a
///comment, a.doccmarkdown file, the Coding Intelligence chat, the commit message field, the "What to Test" box, or a Playground markup cell. - Press ⌃+⌥+R.
- Speak.
- Press ⌃+⌥+R again. AICHE transcribes, cleans up filler, and inserts at the cursor.
- Add the DocC markup that needs to be exact (
- Parameter:,- Returns:,- Throws:) by hand. Xcode's snippet completions cover this.
Heads-up: AICHE transcribes prose. It is not a Swift dictation grammar. For literal code, use Xcode's predictive code completion or the Intelligence panel. For everything around the code, voice is the faster path.
DocC Comments That Actually Render
Xcode parses /// and /** */ blocks as CommonMark and renders them in Quick Help (Option-click any symbol) and in the DocC archive you get from Product > Build Documentation. The markup is forgiving: prose paragraphs render as paragraphs, backticks render as code, and the specific Quick Help fields (- Parameter name:, - Returns:, - Throws:) become structured sections in the popover.
That means almost all of a good doc comment is plain English. Put the cursor above a function, type /// to open the block, hit ⌃+⌥+R, and describe the function the way you would to a teammate: what it does, when to call it, what to pass, what comes back, the non-obvious case that broke production six months ago. AICHE inserts the prose. You then add the structured - Parameter: lines by hand on top.
SwiftUI views are the high-leverage case. A view with a body of nested VStack, HStack, and conditional modifiers reads as code but describes as space. Voice handles space well: "renders a card with rounded corners; an avatar on the leading edge, name and status stacked on the trailing edge, a chevron on the far trailing edge that animates on tap". Eight seconds to speak, far clearer in Quick Help than asking the next reader to mentally execute the body.
For views with state, dictate each branch: "When isLoading, shows a centered progress view. When items.isEmpty, shows the empty-state illustration. Otherwise, shows the list." The branches map back to the switch or if in the body, and the comment tells the reader which UI to expect before they trace the code.
Prompts to Coding Intelligence
Xcode's Coding Intelligence panel is a sidebar where you connect ChatGPT, Claude, or a local model and ask it to write Swift, fix errors, generate tests, or explain code. Agentic versions of the same workflow can plan, edit across files, and run the build.
Both modes reward longer, more specific prompts. The difference between "make a settings screen" and "make a settings screen with three sections - account, notifications, advanced; pull the current values from SettingsStore.shared; use the same .formStyle(.grouped) look as ProfileView; expose a Binding<Bool> for the analytics toggle so the parent can observe it" is the difference between three rounds of edits and one good pass.
Click into the Intelligence chat, press ⌃+⌥+R, and talk through the requirement as if you were briefing a contractor. Constraints, existing patterns to match, the file the new code should live in, what the tests should cover. Press the hotkey again. The full prompt lands in the input. Hit Return.
Voice removes the cost of long prompts. Long prompts produce code that compiles and matches the project's conventions on the first try.
TestFlight What-to-Test
The "What to Test" field is what testers see when they open the new build in TestFlight. Most teams ship it blank or with "bug fixes and improvements", which trains testers to ignore the build. A real note tells them which flow changed, which device or OS to focus on, and what counts as a regression.
Two places to dictate it:
- The "What to Test" box in App Store Connect, after the build finishes processing.
- A
TestFlight/WhatToTest.en-US.txtfile in your repo root, picked up automatically by Xcode Cloud and submitted with each build. One file per locale.
Click into either, press ⌃+⌥+R, and talk through the build: what shipped since the last TestFlight, which screens to open first, what the known issues are, what feedback would be most useful. Two minutes of speaking gives you a note that doubles the useful feedback rate. The file-based approach means every Xcode Cloud build ships with notes without anyone touching App Store Connect.
Commit Messages and PR Descriptions
Xcode's commit sheet (Cmd+Option+C) shows the diff alongside the message field. That is the right surface for a real commit message, because you can scan the changed files while speaking. Click into the message box, press ⌃+⌥+R, and explain what changed and why - the constraint that forced the refactor, the failure mode the fix prevents, the migration step a reviewer should look at first. AICHE inserts. The diff is still on screen, so corrections are quick.
Same workflow in the PR description box on GitHub or GitLab, in whatever browser you have open next to Xcode. The cursor is the only thing AICHE cares about.
Playgrounds and DocC Tutorials
Xcode Playgrounds support inline markdown between code blocks (//: for a single line, /*: ... */ for a block). DocC tutorial files (.tutorial) use a richer markup with @Section, @Step, and @Code. Both are mostly prose, and prose is what voice does well.
Open the Playground or tutorial file, position the cursor in a markup block, dictate the explanation, the rationale, the "try changing X and see what happens". You get tutorial-style Playgrounds and DocC chapters that read like documentation instead of code-with-stub-text-on-top.
Localization Catalog Notes
Xcode 26 redesigned the localization catalog. Each string can carry a comment for translators - context that tells them whether "Open" is a verb or an adjective, whether a placeholder is a number or a name, what the screen looks like. Translators with comments produce better translations. Strings without them produce the worst kind of bug, the one you only notice in a screenshot from a user in Berlin.
Click into the comment column for a string, press the hotkey, and describe the context the translator needs. One line of voice replaces a back-and-forth thread.
What You Get
- Unlimited voice notes with AI cleanup - filler removed, paragraph breaks added, the "uhs" gone.
- Software Development profile (Pro) - recognition tuned for Swift, SwiftUI, Apple framework names, and the way developers actually pronounce
NSAttributedString. - Custom vocabulary - drop in your module names, internal frameworks, brand names, codenames.
- System-wide hotkey - same ⌃+⌥+R in Xcode, Safari, Slack, App Store Connect, Terminal, the Intelligence panel.
- Multilingual voice input - speak Mandarin, German, Japanese, whatever your brain runs in; transcribe in that language or auto-translate to English.
- Zero-retention audio - audio discarded immediately after processing, within 1 second.
Plans start at $3.99/mo (annual) with a 7-day free trial, no credit card. See pricing.
Common Questions
Q: Does AICHE work inside the Coding Intelligence panel?
A: Yes. AICHE inserts wherever the cursor sits. The Intelligence chat input is a normal text field, so the hotkey lands the prompt there the same way it lands a DocC comment.
Q: Will the hotkey collide with Xcode's ⌃⌥⌘R (Run Without Building)?
A: No. AICHE is Control+Option+R (no Command). Xcode's binding is Control+Option+Command+R. They do not conflict.
Q: Is there a plugin or Source Editor extension?
A: No. AICHE runs as a native macOS app and registers the hotkey at the system level, so it works in every Xcode panel without a plugin - editor, Intelligence chat, commit sheet, Organizer notes, Playground markup, localization catalog.
Q: Apple shipped Voice Control with Swift dictation in Xcode 26. Why use AICHE?
A: They are different tools. Voice Control aims at navigating Xcode and dictating literal Swift syntax. AICHE aims at the prose around the code - DocC, TestFlight notes, Intelligence prompts, commit messages, localization comments. Many developers run both.
Q: My DocC comment needs - Parameter foo: and - Returns: lines. Will AICHE format that?
A: AICHE inserts the prose. The structured DocC fields are exact-syntax markup, so add those by hand on top of the dictated paragraph. Xcode's snippet completion (docc, param) gets you the scaffolding.
Q: Can I dictate Swift source itself?
A: You can, but Xcode's predictive code completion and the Intelligence panel are better at literal code. AICHE's leverage is in everything that is not Swift - the comments, the prompts, the release notes.
Q: Does it work alongside Xcode Cloud and TestFlight/WhatToTest.*.txt?
A: Yes. Open the file in any editor (Xcode, Cursor, VS Code), put the cursor in it, dictate, save. Xcode Cloud picks it up on the next build.
Result: DocC blocks above SwiftUI views that render usefully in Quick Help. TestFlight builds that ship with real "What to Test" notes. Coding Intelligence prompts long enough to land code that compiles on the first try. The Apple-platform half of the job - the part that is not Swift - written at speaking speed.
Try it now: open any undocumented SwiftUI view, type /// above the struct declaration, press ⌃+⌥+R, and describe what the view shows and how its states change. Option-click the struct name and watch the Quick Help fill in.