331–340 of 348 posts
Earlier quoted context omitted.
I still haven't found a useful way to replicate preview when iterating quickly on a view (though it's an edge case)
XcodeMCP (Native MCP added in 26.3) Implements this with RenderPreview RenderPreview: Builds and renders a SwiftUI #Preview, returns snapshot
When do you actually need to open Xcode if you have XcodeBuildMCP [0]? 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.
Multiple config files of Xcode projects are not publicly documented as far as I remember and personally I have preferred to require my agents not to modify them out of fear it might break something and be hard to fix. I don't know how agentic programming will work in Xcode but I would expect it to do it using a safer approach, so that's also another case where it might have an advantage. Your workflow looks very inte…
Tuist generates the code project from a simple swift confiuration file similar to Package.swift. I don't know why apple can't just throw away the proprietary and ugly Xcode project files and provide a sane build system that would work in any IDE, on the command line, in CI and now with AI agents.
They could open up the instruments format while they are at it for the same reason, do they really gain anything by making it proprietary?
I built an entire iOS app without opening Xcode UI even once. Why so many iOS engineers prefer XCode?
As MKBHD would say, welcome to 2026, Apple.
MCP support is the real story here Means you're not locked into Claude or Codex Can plug in whatever agent you want
100% I hope they open more of the tooling to MCP, Xcode Instruments with real MCP support would be huge.
Earlier quoted context omitted.
> This means you've learned to work around its shortcomings. All software of comparable size and complexity have shortcomings that everyone learns to work around. And a great many of those shortcomings are actually just highly subjective personal preferences. More than half of the complaints in this thread are, to me, a terrible idea.
> All software of comparable size and complexity have shortcomings that everyone learns to work around. This is part of the issue IMO. Is this size and complexity warranted? Rust for example; its a complex language, can target pretty much all platforms under the sun, and yet it's configured with just text files, builds with just terminal commands, and works great with any text editor. I've seen people in big tech wor…
Nobody is saying not to use Xcode if you like it, but there should be a choice like there is for almost every other modern platform.
Earlier quoted context omitted.
Honest question. I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points. They are definitely fixing bugs. I make software for iOS, macOS, car play, and apple watch. Sure sometimes I've got to reset or clear a cache, but this has never stopped my day. What is so horrible about XCode?
If nothing else, an update to the pbxproj file format would be life changing. Most of my time fighting git is dealing with project file merges.
Earlier quoted context omitted.
> (Context: I was an iOS dev for 10 years on well known, large iOS apps - I can't explain how much I dislike Xcode). Since you’re pretty new to mobile dev, count yourself lucky with the amazing dev tools you have today. Nothing like doing a bit of J2ME, Symbian S60 or BlackBerry development to learn to appreciate how far we’ve come.
lol... people that complain about XCode don't know how well they have compare to what it was before. I started my work on the J2ME era as well. Had to use textpad for development, and maybe eclipse at some point (which was pretty decent). Tools and simulators were all over the place.
It’s so funny when people complain about the $99 fee for the Apple development program being developer-unfriendly. Back in the day, RIM/BlackBerry wasn’t so much developer-unfriendly as much as actively hostile towards developers. Basically, if you weren’t a fortune 500 company you could fuck right off.
(Context: I was an iOS dev for 10 years on well known, large iOS apps - I can't explain how much I dislike Xcode). 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 -…
(Context: I was an iOS dev for 10 years on well known, large iOS apps - I can't explain how much I dislike Xcode). 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 -…