←back to thread

Claude Sonnet will ship in Xcode

(developer.apple.com)
485 points zora_goron | 9 comments | 29 Aug 25 00:44 UTC | HN request time: 0.001s | source | bottom
Show context
Lammy ◴[29 Aug 25 04:47 UTC] No.45060316[source]▶
Interesting to think about how Apple get to make product decisions based on Gatekeeper OCSP analytics now that every app launch phones home. They must know exactly how popular VSCode is.

Facebook got excoriated for doing that with Onavo but I guess it's Good Actually when it's done in the name of protecting my computer from myself lol

replies(2): >>45060370 #>>45060628 #
wahnfrieden ◴[29 Aug 25 04:57 UTC] No.45060370[source]▶
This won't make a dent. It still doesn't support any agentic operation.

The real news is when Codex CLI / Claude Code get integrated, or Apple introduces a competitor offering to them.

Until then this is a toy and should not be used for any serious work while these far better tools exist.

replies(1): >>45060481 #
alwillis ◴[29 Aug 25 05:17 UTC] No.45060481[source]▶
I just installed it—definitely not a toy.

Compared to stock Claude Code, this version of Claude knows a lot more about SwiftUI and related technologies. The following is output from Claude in Xcode on an empty project. Claude Code gives a generic response when it looked at the same project:

    What I Can Help You With

    • SwiftUI Development: Layout, state management, animations, etc.
    • iOS/macOS App Architecture: MVVM, data flow, navigation
    • Apple Frameworks: Core Data, CloudKit, MapKit, etc.
    • Testing: Both traditional XCTest and the new Swift Testing framework
    • Performance & Best Practices: Swift concurrency, memory management

    Example of What We Could Do Right Now

    Looking at your current ContentView.swift􀰓, I could help you:
    • Transform this basic "Hello World" into a recovery tracking interface
    • Add navigation, data models, or user interface components
    • Implement proper architecture patterns for your Recovery Tracker app
replies(4): >>45060512 #>>45060594 #>>45060806 #>>45069026 #
1. manmal ◴[29 Aug 25 05:36 UTC] No.45060594[source]▶
If a bunch of markdown files forced into the context is “knowing”, then yes. They are usually located at /Applications/Xcode-beta.app/Contents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/AdditionalDocumentation

You are free to point Claude Code to that folder, or make a slash command that loads their contents. Or, start CC with -p where the prompt is the content of all those files.

Claude Code integration in Xcode would be very cool indeed, but I might still stick with VSCode for pure coding.

replies(2): >>45060830 #>>45068128 #
2. brailsafe ◴[29 Aug 25 06:22 UTC] No.45060830[source]▶
> Claude Code integration in Xcode would be very cool indeed, but I might still stick with VSCode for pure coding.

I'm sticking with VSCode too, but it's a bit silly to suggest that anyone is using XCode because it's their preferred IDE. It's just the one that's necessary for any non-trivial Apple platform development.

Adding a code generator isn't a marketing ploy to get people to switch editors, it's just a small concession to the many hapless souls stuck dealing with Apple on the professional side, or masochistically building mac SwiftUI apps just to remind themselves what pain feels like.

replies(2): >>45061477 #>>45065199 #
3. manmal ◴[29 Aug 25 08:09 UTC] No.45061477[source]▶
I mean you can stay in VSCode for most activities if you hate Xcode that much (I can relate btw). Plugins like Sweetpad make this possible. My approach now is to develop all logic in small Swift packages and run swift test in VSCode (or Claude Code), so I only absolutely need Xcode for debugging and building releases. Every once in a while I try SwiftUI previews, but those are usually broken anyways.
replies(1): >>45070036 #
4. wahnfrieden ◴[29 Aug 25 15:12 UTC] No.45065199[source]▶
I actually continue to use Xcode (in vim mode now that they have that) purely because of the way tabs work… in Vim and Xcode I’m able to have the same file open across multiple tabs and window-tabs, allowing me to arrange sets of files for particular tasks. But in VS Code it sends me to another window when I want to view a file next to another one, just because it’s already open elsewhere. I can’t stand this behavior as it slows me down and breaks my ability to see the files I want to see next to each other without many extra steps to rearrange things over and over. A ticket requesting this behavior change has been open for years with no progress.
replies(1): >>45069981 #
5. alwillis ◴[29 Aug 25 19:08 UTC] No.45068128[source]▶
No, this isn't a bunch of markdown files, has been in the works since at least May and has been dogfooded inside Apple [1]: "Apple Partners With Anthropic for Claude-Powered AI Coding Platform"

[1]: https://www.macrumors.com/2025/05/02/apple-anthropic-ai-codi...

replies(1): >>45069279 #
6. wahnfrieden ◴[29 Aug 25 20:53 UTC] No.45069279[source]▶
What is special about it besides the IDE integration? It is a bunch of markdown files with a search tool. It has no agentic capability so it is far behind state of the art dev tooling. Apple devs internally use Claude Code.
7. brailsafe ◴[29 Aug 25 22:09 UTC] No.45069981{3}[source]▶
That's an interesting auper apecific detail that I think I've encountered once or twice. I'm reminded of one niche reason I also chose XCode for non-apple stuff, which was to print code on paper. I don't remember why I struggled to do it in VSCode at the time, but XCode was the solution.
replies(1): >>45070731 #
8. brailsafe ◴[29 Aug 25 22:14 UTC] No.45070036{3}[source]▶
Ya I was considering a similar workflow last time I was steeped in SwiftUI. I don't dislike it that much actually, maybe just how slow the compile and error alerting is/was last time. I mainly found mac SwiftUI performance to be lacking, along with the transparency and documentation of the api. Swift itself is fine, and I give a xcode a lot of credit for somehow functioning as well as it does with so much accumulated functionality/complexity/bloat.

SwiftUI previews were... manageable but not great.

9. wahnfrieden ◴[29 Aug 25 23:57 UTC] No.45070731{4}[source]▶
I typically have 5-6+ panes open per window tab representing an area of work. In Xcode I can also make new window tabs that inherit the same set of tabs/splits/panes allowing me to "fork" and tweak a view of files. I use these features continuously throughout the day and hit jarring blocks trying to work this way every session in VS Code which makes it impossible to have more than one arrangement at once. I've been using this workflow for 15+ years in Vim before Xcode.