Xcode 26.3 – Developers can leverage coding agents directly in Xcode

Original Article ↗ Hacker News Discussion ↗

Reaction to Apple’s “agentic coding” in Xcode

  • Many were surprised Apple moved this fast, but others saw it as inevitable given industry trends.
  • Some see the branding as hype for capabilities that were already possible via CLI tools and external agents.
  • A few view integrated agents as “huge news” and necessary for Xcode’s future; others call it more AI bandwagoning while core issues go unfixed.

What Xcode 26.3 actually adds (vs 26.2)

  • Key change cited: exposure of capabilities through the Model Context Protocol (MCP), allowing “any compatible agent or tool” to plug into Xcode.
  • Xcode now uses the Claude Agent SDK, promising “full Claude Code” power in-IDE (subagents, background tasks, plugins) and SwiftUI preview capture.
  • Several users are unclear what’s new because 26.2 already supported Claude; 26.2’s agent UI was described as clunky, slow, and even crash-prone.
  • Some report that AI features require newer macOS (Tahoe), with the “intelligence” settings pane missing on older releases, but details remain somewhat unclear.

MCP, openness, and local models

  • MCP support is widely called the “real story”:
    • Not locked to Claude; developers can in theory bring any MCP agent, including local models.
    • People hope Instruments and more tools will expose MCP endpoints next.
  • One commenter notes this is a shift from Apple’s Siri-era “do everything in-house” approach and praises it as thoughtful for privacy‑minded or local‑only workflows.

AI in the IDE vs external tools

  • Some prefer separate tools (Claude Code CLI, OpenAI Codex app, Zed’s ACP, XcodeBuildMCP/Axiom) to keep AI clearly “outside” the editor and under manual control.
  • Others welcome deep in-IDE integration for human‑in‑the‑loop refactors, debugging loops, and using Xcode’s semantic context.
  • There’s disagreement on whether AI is now “key” to software engineering: some say its absence would be existential risk for Xcode; others argue it’s overhyped or even a net negative.

Xcode quality, UX, and priorities

  • Large portion of the thread is a long-running Xcode gripe-fest:

    • Performance: slow launch, sluggish debugging and stepping, long SwiftUI preview times, heavy simulator overhead.
    • Debugger: especially weak for C++, flaky with lambdas, slow or empty variable views, random hangs.
    • UI/UX: rigid layout, awkward sidebars, no integrated terminal, confusing tabs, poor Git UI, clumsy documentation viewer.
    • Project system: fragile .pbxproj merges, odd sorting behavior, duplicated dependencies, opaque configuration files.
    • CLIs (xcodebuild et al.) seen as unreliable and noisy; Xcode is perceived as working around its own tools instead of fixing them.
    • Complaints that Xcode and macOS updates hijack file associations and consume disk with simulators and runtimes.

  • Counterpoints:

    • Some long‑time users say Xcode has steadily improved and works well for them; issues are overblown or just different workflows.
    • Others argue every large IDE has warts, and many criticisms are subjective or reflect unfamiliarity.

Privacy, lock‑in, and ecosystem concerns

  • Multiple people ask what data is sent to Anthropic and whether “entire codebases” are uploaded; the thread doesn’t provide a clear answer.
  • Some insist AI must be strictly opt‑in, with no code leaving the machine until explicitly enabled.
  • Others note that because Xcode is effectively required for App Store deployment, it faces no real “existential risk,” which they argue reduces Apple’s incentive to prioritize bug‑fixing over headline AI features.