(4) Building iOS and Mac apps in Zed: Make builds as fast as Xcode. Plus, better support for Mac apps.
2026-02-20
This is part of a series on how to build, run and debug iOS and Mac apps in Zed instead of Xcode.
This makes me so happy.
I much prefer building Apple apps in Zed to Xcode, but it's always been a bummer that builds are slower. Those multiple seconds spent doing SPM stuff every. single. build. get a bit painful, especially when you go back to Xcode for some reason and see your incremental builds just fly by.
Well, no more: xcede has a new option that makes it build as fast as Xcode. Put this in your
.xcrc:
This makes xcede build with Xcode via Applescript, rather than using xcodebuild. Does that sound
kind of janky? Well, it turns out it's not – Xcode stays in the background, and you see progressive
build output (beautified of course) just like you did before. But now, it's faster.
If Xcode isn't running, or doesn't have your project open, xcede will take care of that for you.
And how's the speed? It's only a few hundred milliseconds to trigger the build in most cases, so
essentially the same as Xcode. And Xcode really is faster – behind the scenes it leaves its build
server running, so there's a bunch of stuff that simply doesn't need to be repeated every build.
xcodebuild on the other hand has to start from scratch every time.
So shouldn't this be the default?
It's early days for this feature, but I like it so much I wanted to get it out to people as soon as possible. Still, there's something about relying directly on Xcode that makes me cautious about it being the default behaviour. Let's see how it goes.
Better support for Mac apps
xcede's default behaviour is to launch Mac app executables directly,
e.g. .../DelayDrop.app/Contents/MacOS/DelayDrop. That's often ok, but in fact it exists in some
no-man's-land where it's not quite a real app. This can mess with user permission prompts and the like,
with TCC targeting Zed rather than your app.
So now we have this new option:
and again, you might wonder why this isn't the default. Well, it means you don't see standard output
and error, so if you rely on those for logging, you now need to convert your app to OSLog if you
want to see your log messages. xcede has support for that; see xcede run --help for details.
Postscript
HEADLINE: Person uses LLM to write some code
Not exactly news, is it? But I'm not the most likely person to do such a thing, for some of the usual reasons. I won't repeat those here, except to say that if you have sufficient imagination and enough of a grip on reality to step back, see the bigger picture and project forward a bit, there are some fairly appalling results likely on multiple fronts if we select the "most code is written by LLMs" path of our particular global adventure.
All the same, I got an LLM to write the JXA (aka Javascript sending Apple Events). Look, I had no interest in the actual work, and it probably wouldn't have happened if I'd had to do it myself. Personally I find it fairly painful work even without the crucible that is Applescript; these are skills I have no interest in acquiring. So I asked the machine to do the basic task, and then thought let's see if it can manage the scheme and run destination, and then open a suitable project given certain rules, and then choose the right Xcode, and then there was a (hopefully) release-worthy addition to the tool – one I wouldn't have bothered writing manually.
I'm still not sure that my soul isn't in peril though.
@lxmn@mastodon.social