362 points · davidbarker · 1 day ago
apple.comAJRF
OsamaJaber
mads_quist
Native app development is an evil necessity.
thought_alarm
Surprisingly, this version does not require MacOS 26 (Tahoe).
flohofwoe
cyrusradfar
Xcode being loaded on my computer causes something akin to a kernel panic.
Not the fun kind where you get to read a backtrace and feel something. The existential kind.
Every time it hijacks a .json or .xml file association, I experience a rage that hasn't been matched since the Emacs/vi wars ... and at least those were about editors that could open in under a geological epoch.
I just want to look at a text file with pretty print.
I do not need a 12GB IDE to render curly braces. cat has been doing this since 1971. Dennis Ritchie solved this.
Why, Apple, in 40 years, could you not ship a lightweight dev-oriented text viewer? You had NeXTSTEP. You had the DNA of the most elegant Unix workstation ever built.
And you gave us... this behemoth? An app whose launch time rivals a full Gentoo stage 1 install ( see: https://niden.net/post/gentoo-stage-1-installation )
TextEdit is not the answer.
I've used Xcode for native iOS development and honestly, once you get past the Stockholm Syndrome phase, it's just fine.
- The interface is learnable.
- The debugger mostly works.
But the load times -- on every high-end MBP I've ever owned -- suggest that somewhere deep in the Xcode binary, there's a sleep(rand()) that someone committed in 2006 and no one has had the courage to git blame.
FWIW, I fear someone here tells me I've been missing a launch flag. Alas, it's my truth and I can't hold it in anymore.
OGEnthusiast
meetpateltech
> Apple’s Xcode now supports the Claude Agent SDK
anupamchugh
I haven't opened Xcode in months. My terminal: Claude writes code. build_sim. launch_app_sim. screenshot describe_ui.
What still requires Xcode: Instruments profiling, Signing/provisioning
For UI iteration, describe_ui returning the accessibility tree might actually be more useful to an agent than a preview screenshot.
robofanatic
scosman
I feel like Xcode knows how to work around xcodebuild’s shortcomings, and instead of fixing them they just wrapped Xcode in an MCP server.
Better than nothing I guess, but reliable CLIs would allow a whole ecosystem of tools.
gdubs
I recently have pivoted to mainly working in either Claude of Codex on the command line, because their ability to run autonomously for long, extended periods wasn't possible in the turn-based Xcode intelligence features.
That, plus the fact that the agents could run command-line utilities and just generally be more "agent-y".
My way of working has really shifted this year. I've been experimenting with LLMs for coding for years now, but the models released in the past year really feel like they've hit a point where they write code much closer (sometimes indistinguishable) from how I would write it.
mikeocool
Beyond that, I'd just keep using Claude Code in the terminal.
cap10morgan
SirMaster
I wonder if they used this internally to write iOS 26? Would explain some things...
jon889
bytesandbits
r2vcap
https://xcodereleases.com hasn’t shown anything since last December, so I assumed Apple had taken a breather from Xcode development, but they released an RC build today?
Anyway, the Swift version seems unchanged (6.2.3), so is this update mainly for the so-called “Coding Intelligence” features?
In any case, Xcode isn’t my favorite IDE—it’s too slow and feels quite different from other major IDEs—so I probably won’t use it for day-to-day coding (though it’s fine for building and debugging).
OscarTheGrinch
apt-apt-apt-apt
classicsc
msvan
meisel
arjie
geooff_
avaer
[deleted]
xzel
willtemperley
thedangler
mohsen1
zwaps
Yet every week it assigns itself as default program for all sorts of files, from markdown to python modules.
So clicking on pretty much anything opens this.
Apple is just very bad at user interface. Whoever said Mac as better than Linux or even Windows is insane.
I hate it.
forrestthewoods
* text editor with intellisense * build system * visual debugger * CLI coding agent
It’s totally fine if those four things are different. In fact I actually probably prefer them to be different. Having an all-in-one IDE is a complete and total non-goal.
People have historically confused the first three as needing to be a single IDE. This has always been wrong. The number of people who think you can’t debug with Visual Studio if the exe wasn’t built from a .sln is shocking. They’re all independent!
nofunsir
mrtksn
Yesterday in few hours I released an update for my mac App that I haven’t been working on for over a year. The update easily performed as expected, did a few small manual touches on the UI and the app just got approved on AppStore(like minutes ago)[0].
This is very good because normally I would not remember much about the code, so doing an update for a long forgotten code becomes huge pain.
Good for Apple but I think I feel most comfortable on Codex app. I think I like having the AI separated from the IDE so I feel in control in the IDE.
[0] Codex implemented the functionality demo on the paywall, if you want to see it: https://apps.apple.com/us/app/crystalclear-sound-switcher/id...
mlajtos
va1a
enraged_camel
Iridiumkoivu
jonathanstrange
msie
hota_mazi
mrcwinn
HaloZero
Or is Xcode developed not using Xcode...
(I also 2nd the question about what's really the difference between this and the Xcode 26.2)
anthk
wahnfrieden
giancarlostoro
almosthere
factorialboy
cyberax
"Agentic this", "agentic that"... It's literally just an LLM in a while() loop with some exposed tools.
minimaxir
bigyabai
pjmlp
Oras
I recently started working for a startup, and they wanted an app.
What I shipped was a react native app (so I don't need to go in to Xcode to build), that renders a full screen web browser that points to our website. I've sprinkled in bits of injected JS to capture our cookies and local/session storage - which then gets saved to device storage and reinjected on app startup.
There are a few native-ish bits sprinkled in - onboarding, notifications, error screens, loading indicators, etc - but for the most part we don't need to worry about our API borking old versions (which is moving extraordinarily fast).
The only semi tricky bit was native auth integration - that needs treated with a bit more care, and stored securely, but it took a few days.
I ship the app to TestFlight and the AppStore using Fastlane from the command line, match handles the certs, and I never have to open Xcode.
It is honestly bliss, and i've heard a lot of app developers moving to this model (interestingly it normally follows a failed SDUX implementation)