How to Integrate Codex Directly into Xcode — Plus the Best SwiftUI Skills

Xcode can now host Codex directly inside its Coding Assistant. That changes the workflow completely: instead of keeping an AI agent in a separate terminal or desktop window, you can start a Codex conversation beside your source code, give it project context, review edits in place, and let Xcode expose native capabilities such as building and testing.

This guide covers the settings-level integration, the separate MCP route for external Codex sessions, and a careful way to add third-party SwiftUI and Swift Concurrency skills.

Before you start

Use a current Xcode release that includes Intelligence settings and the Coding Assistant. Availability can depend on the Xcode release, region, account, and managed-device policy. Update Xcode first, then open a project that already builds successfully. Commit or create a Git checkpoint before asking any agent to edit the code.

1. Install Codex from Xcode Settings

  1. Choose Xcode > Settings.
  2. Select Intelligence in the sidebar.
  3. Under Agents, find Codex and click Get.
  4. Review the installation sheet and click Install.
  5. Open the Codex agent settings. In the Account row, click the More button and follow the sign-in flow if you want to use your account.

Xcode can update downloaded agents automatically when possible. Before using an agent on proprietary code, read the privacy information linked from Intelligence settings. The selected agent may receive project files and other context needed to process a request.

2. Open Codex in the Coding Assistant

Open the Coding Assistant with its toolbar button or press Command-0. Start a new conversation and choose Codex as the agent. The selected agent runs in Xcode’s conversation workspace, where you can keep the transcript, source, and generated artifacts visible together.

For a focused source-editor request, select code and use the coding tools popover, or press Command-Option-0. Starting from a selection is especially useful for explaining unfamiliar code, adding documentation, or refactoring one type without inviting a repository-wide rewrite.

A good first prompt is:

Inspect this project without editing files. Identify the active app target, deployment target, test targets, concurrency settings, and the safest build-and-test plan. Report any assumptions before making changes.

3. Configure permissions deliberately

Agents can become much more useful when they may run build tools, tests, formatters, and project-specific scripts. They also become more powerful, so treat permissions as part of the project’s security model.

In Xcode > Settings > Intelligence, open the Permissions row under Agents. Review previously allowed commands and tools. Add only the command-line tools the project actually needs, such as a formatter or a project-owned test script.

A sensible starting policy is:

  • Allow read-only project inspection and normal builds.
  • Allow the project’s tests and formatter.
  • Require review for dependency changes, scripts downloaded from the internet, signing changes, and destructive commands.
  • Do not grant broad shell access merely to avoid an occasional approval.

4. Customize Codex specifically for Xcode

Xcode keeps agent-specific configuration in subfolders beneath:

~/Library/Developer/Xcode/CodingAssistant

Codex configuration used only when Codex launches inside Xcode belongs in:

~/Library/Developer/Xcode/CodingAssistant/codex

This separation is useful: settings for Codex inside Xcode do not have to affect every Codex session on your Mac. You can set an appropriate model, add MCP servers, or provide Xcode-specific guidance while keeping external workflows independent.

Also place an AGENTS.md file in the repository root for project rules that should travel with the code:

# Apple project guidance
- Use SwiftUI and modern Swift Concurrency.
- Assume strict concurrency checking.
- Prefer async/await, actors, and structured concurrency over GCD.
- Preserve bundle identifiers, signing, capabilities, and entitlements.
- Do not add dependencies without approval.
- Run the app target build and relevant tests before finishing.
- Use availability checks and fallbacks for newer platform APIs.
- Keep views accessible with Dynamic Type and VoiceOver.

5. Add SwiftUI and concurrency skills

Agent skills are focused instruction packages that teach an agent a repeatable workflow or domain-specific rules. In current Xcode releases, agentic coding plug-ins can contain skills, subagents, and MCP servers.

  1. Open Xcode > Settings > Intelligence.
  2. Choose the Plug-ins row under Agents.
  3. Click Add Plug-in.
  4. Choose an import method. For a repository, select the URL option and paste its GitHub URL.
  5. Review the components, select only the skills you need, and click Install.

Not every repository is packaged as an Xcode-compatible agent plug-in. If Xcode does not accept it, use the project’s documented Agent Skills installation method for an external Codex workflow instead of forcing it into Xcode.

Popular skills worth evaluating

  • SwiftUI Pro by Paul Hudson — covers modern SwiftUI APIs, state management, navigation, layout, performance, accessibility, and common model mistakes.
  • Swift Concurrency Pro by Paul Hudson — targets async/await, actors, Sendable, task groups, structured concurrency, and newer language behavior.
  • SwiftUI Expert by Antoine van der Lee — emphasizes modern APIs, view composition, invalidation and performance, lists, localization, Liquid Glass, and Instruments traces.
  • Swift Concurrency by Antoine van der Lee — includes Swift 6 migration, actor isolation, async sequences, testing, performance, and concurrency triage.
  • Swift iOS Skills by Daniel Pearson — a broad collection with focused skills for SwiftUI, concurrency, SwiftData, StoreKit, accessibility, networking, testing, and Apple frameworks. Install only the modules you use.

For an external Codex installation, many of these repositories document a command such as:

npx skills add https://github.com/twostraws/swiftui-agent-skill --skill swiftui-pro
npx skills add https://github.com/twostraws/swift-concurrency-agent-skill --skill swift-concurrency-pro

These commands install third-party code and instructions. Review the repository, license, recent maintenance, SKILL.md, scripts, and permissions before running them. Prefer a pinned release or commit for a team workflow, and retest skills after major Xcode or Swift changes.

6. Use external Codex with Xcode’s MCP bridge

Installing Codex inside Xcode and connecting an external Codex session are two different workflows. If you want the Codex CLI or desktop workflow to use the open Xcode project and its tools, enable Xcode’s MCP bridge:

  1. Choose Xcode > Settings > Intelligence.
  2. Under Model Context Protocol, turn on Allow external agents to use Xcode tools.
  3. In Terminal, run:
codex mcp add xcode -- xcrun mcpbridge
codex mcp list

Keep the intended project open in Xcode before prompting the external agent. Xcode displays when an external agent connects and when it is active.

This route is ideal when you prefer the Codex app or CLI but still want Xcode-native build, test, project, and simulator capabilities. The in-Xcode agent route is better when you want conversations, diffs, and source context inside the Xcode workspace.

7. A modern Swift Concurrency prompt

Skills work best when the task still states the target and proof clearly:

Use the Swift Concurrency skill to review this feature for Swift 6 strict-concurrency issues. Check actor isolation, Sendable conformance, task lifetime, cancellation, and accidental unstructured concurrency. Do not silence diagnostics with unchecked conformance. Make minimal fixes, build the app, run focused tests, and explain any remaining warnings.

For SwiftUI, ask the skill to inspect data ownership, @Observable flow, ForEach identity, view invalidation, accessibility, navigation, and availability checks. Do not ask it to “modernize everything” in one pass; separate correctness, migration, and performance work.

Pro tips

  • Use one skill per concern. Loading every iOS skill wastes context and can produce conflicting advice.
  • Keep skills advisory. Your deployment target, architecture, and product requirements outrank generic rules.
  • Review generated project-file changes. Treat edits to project.pbxproj, entitlements, capabilities, build settings, and signing as high risk.
  • Ask for evidence. Require the build command, test result, changed files, and remaining diagnostics.
  • Create checkpoints. Xcode conversation rollback is helpful, but Git remains the durable source of truth.
  • Audit updates. A popular skill can still become outdated or compromised. Re-review changes before updating a shared installation.

Official references

The strongest setup is intentionally small: Codex enabled in Xcode, carefully scoped permissions, a concise AGENTS.md, one SwiftUI skill, one concurrency skill, and a build-and-test loop you trust.

How to Configure Codex for Xcode: A Practical Setup and Pro Tips

Codex can be a remarkably effective partner for iOS and macOS development, but there is one important detail to understand first: you do not configure it as a native Xcode extension. The best workflow is to let Xcode remain your visual editor, signing environment, preview canvas, and debugger while Codex works directly with the same project folder from the Codex app or CLI.

Once both tools point at the same repository, Codex can inspect Swift and SwiftUI code, make focused edits, run builds with xcodebuild, analyze compiler errors, write tests, and help debug simulator issues.

1. Prepare the Xcode project

Start with a project that builds successfully in Xcode. Resolve signing errors, select the intended scheme, and run the app once on your preferred simulator. This gives Codex a clean baseline and avoids confusing an existing project problem with an AI-generated change.

If the project uses Swift Package Manager, let Xcode finish resolving packages first. For workspaces, open the .xcworkspace rather than the .xcodeproj when CocoaPods or another tool generated the workspace.

2. Open the same repository in Codex

In the Codex desktop app, create or open a project that points to the folder containing the Xcode project or workspace. If you prefer the terminal, change into that directory before starting Codex. Keeping the repository root as the working directory gives the agent access to source files, tests, configuration, assets, and project instructions.

A useful first prompt is:

Inspect this Xcode project without changing files. Identify the app target, scheme, deployment target, test targets, package dependencies, and the safest xcodebuild command for a simulator build.

Ask Codex to inspect first, then make changes. That small habit prevents many incorrect assumptions about schemes, destinations, and project structure.

3. Establish a repeatable command-line build

Codex is most reliable when it can verify work without depending on clicks in the Xcode GUI. Ask it to list available schemes:

xcodebuild -list -project MyApp.xcodeproj

Then establish a simulator build command, for example:

xcodebuild \
  -project MyApp.xcodeproj \
  -scheme MyApp \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' \
  build

For a workspace, replace -project with -workspace MyApp.xcworkspace. Simulator names vary by installed Xcode version, so let Codex query available devices instead of hard-coding one blindly.

4. Add project instructions with AGENTS.md

Create an AGENTS.md file at the repository root. Codex reads this file as project-specific guidance, making it the ideal place to record conventions that should survive across tasks.

# Project guidelines
- Use SwiftUI and Swift Concurrency.
- Support iOS 18 and newer.
- Prefer @Observable for new shared state.
- Do not add dependencies without approval.
- Keep views small and extract reusable subviews.
- Run the app scheme build and unit tests before finishing.
- Never modify signing, bundle identifiers, or entitlements unless asked.

Include real commands for formatting, linting, tests, and code generation. The more deterministic the verification loop, the more useful Codex becomes.

5. Give Codex focused tasks

Good tasks include the desired behavior, constraints, and the proof required before completion. Instead of saying “fix the settings screen,” try:

Fix the settings screen layout on compact-width iPhones. Preserve current behavior and accessibility identifiers. Build the app for an available iPhone simulator, run the relevant tests, and summarize every changed file.

For risky refactors, ask for a plan first. For small visual tweaks, keep the task narrow and request a screenshot or simulator verification when available.

Pro tips for experienced Xcode users

Use a dedicated derived-data directory

Give automated builds their own derived-data path. This makes cleanup predictable and reduces interference with an Xcode session:

xcodebuild ... -derivedDataPath .build/DerivedData

Add the directory to .gitignore.

Prefer structured compiler output

Long build logs consume attention and context. Use a formatter such as xcbeautify if it is already part of the project, or ask Codex to focus on error: and warning: lines. Do not let it hide the original exit status.

Separate build, test, and UI-debug loops

A fast compile loop should not always launch the simulator. Use three explicit commands: one for building, one for unit tests, and one for UI or simulator debugging. Codex can then choose the least expensive proof for each change.

Protect signing and project metadata

Changes to project.pbxproj, entitlements, capabilities, and signing settings deserve extra review. Tell Codex not to touch them unless the task requires it, and inspect those diffs carefully before committing.

Use worktrees for parallel experiments

When exploring multiple implementations, use Git worktrees or separate branches so each Codex task has an isolated checkout. This avoids overlapping edits and makes it easy to compare approaches before merging one.

Add XcodeBuildMCP for deeper automation

Advanced users can add an Xcode-focused MCP server such as XcodeBuildMCP. It can provide a more structured bridge to schemes, builds, simulators, screenshots, and UI automation. Treat third-party MCP servers like development tools: review their permissions, pin versions where possible, and start with the narrowest access that works.

Ask for evidence, not confidence

The best final prompt is often simple: “Show me the build command, test result, remaining warnings, and the exact diff.” A successful build and focused tests are much more valuable than a confident explanation.

A practical daily workflow

  1. Open the project in Xcode and confirm the current branch builds.
  2. Open the same repository in Codex.
  3. Ask Codex to inspect the relevant files and propose a short plan.
  4. Approve a focused implementation.
  5. Let Codex build and test from the command line.
  6. Review the diff in Codex or Xcode.
  7. Run the final UI check, previews, signing, and archive flow in Xcode.

This division of labor works well: Xcode remains the authoritative Apple development environment, while Codex handles codebase navigation, repetitive edits, tests, build diagnostics, and carefully scoped automation.

Official resources

Tip: keep the first version of your setup deliberately simple. A reliable xcodebuild command plus a clear AGENTS.md file delivers more value than a large collection of tools that nobody maintains.

Automate your Xcode workflow / Dev tools with keyboard shortcuts

Hardware

As developers, we start and switch a lot between common developer applications each day. You can buy some external hardware keyboards to achieve this, like for example with these USB Mini 3-Key Keypad, or the HUION Keydial, 9-Keys USB Mini Keypad, Programming Macro Pad. They work fine but you must always pack them in your bag when going to your workspace, but make sure before purchasing them, that they have macOS software drivers.

macOS Shortcuts

Personally I have the Huion, and use it for general Xcode keyboard shortcuts — like show / hide panes, delete current line, Run, Stop, etc, and to save keys I use macOS Shortcuts to launch applications like Xcode.

To achieve this do the following:

  1. open Shortcuts
  2. tap on the + in the title bar
  3. In the categories tab on the right, select Open App, and drag it on the canvas
  4. Click on App, to select Xcode
  5. Click on the info circle top right > Add keyboard shortcut > Control+Option+Command+x
  6. If you see on the canvas, Receive input from, deselect all
  7. Tap on the default name in the title: Open App, to change it to Open Xcode, and you can optionally assign an icon, but this is not really needed.
  8. Now comes the confusing part, there is no save, you just close this window with the red x
  9. Close Shortcuts
  10. Test by tapping Control+Option+Command+x

Other Dev tools

Now you can repeat this process for your most common developer tools like SourceTree, Interactful, Slack, enjoy!

Recover your old Pixelmator version in macOS Sonoma

I’m a long term Pixelmator user, it has supported me very well during the times I’ve been developing and needed some image trickery.

Until recent it would not start anymore — after I upgraded to macOS Sonoma 14.x. I found out that the product has been revamped to Pixelmator Pro now, but I didn’t want to pay the license again, I’ve one for my current version.

After some long searches in the inter webs fora, I found a reasonable solution.

  1. Open Terminal
  2. cd ~/Library/Containers
  3. rm -rf com.pixelmatorteam*

Now the app starts again at least, and it saved me another 60 Euros. I’ve still one issue with gradients, when I open the gradients tool, the app crashes, and I’ve to type the terminal commands again to get it booting again. But so far I can live with that. Somewhere along the way I need to purchase a new license I know, but until then I’m happy to have it back for basic image manipulation and icon creation.

MacOS Tips: Expand all in Finder

In the Finder when you are using List Views, when you open a folder, the content of the folder is collapsed by default. You have to manually click on each folder to expand its content as well.

There is a faster method of expanding all the underlaying folders in one click and that is with: Option-Click on the triangle.

Note this also works in other applications like XCode for example.

Default behaviour
Option-Click behaviour