I've been using essentially this process (with Claude Code) for about six months. There are a couple of places where I've opened xcode; mostly to update the simulators for new betas of xcode 27, and once to add a target for Apple Watch.
Interestingly, since about Opus 4.6, Claude has been able to reason its way into this process on its own. It was clunky until 4.7, and in 4.8 it's managed to find its way around every reason I had to open xcode myself.
> I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks.
Even though the text we're reading is Claude talking to us as well :)
Also it was weird to see the mention of "ask your LLM" at almost every stage in the blog post:
> point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out
> When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway.
> The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do.
> Again, if in doubt, ask Claude Code or your LLM of choice to create this for you.
> Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow.
It seems too concise to be AI. My (conscious) heuristic for AI writing is how much context is squeezed into a sentence. LLMs seem to be pretty bad at the kind of elegant compression of meaning humans can do when they have done a lot of writing practice.
If I had to guess, I would say this is the human summarised conversation(s) with a bot.
Sorry if my speculation was bad! When I wrote it I meant it as a compliment. Raw LLM output is awful and really needs a human to "translate" the useful content to something worth reading.
Thank you for your service. Xcode gets a bad rap from developers but for beginners, it doesn’t overwhelm them, giving them a great entry experience into app development.
Thank you for your comment. Prior to Apple, I worked on the Visual Studio team for 10 years. Now that is a complex app now matter how experienced you are. ;-)
This is cool but also makes me worried about the tendency with llms for all of us to make bespoke solutions rather than building a better community tool or extending an existing tool to solve the problem. fastlane exists to solve exactly this problem in the mobile space.
Also, shell scripts as part of a build are usually a little worrying. I'd at least want the build steps to be all integrated into my Makefile or CMakeLists.txt
Bespoke solutions are better in many cases. They do exact things required for the project without taking extra dependency. Reducing dependencies is beneficial, because dependencies require management. So with llms economy of taking dependency shifted.
everything has tradeoffs, on the one hand you are right you have one less dependency, on the other hand the maintenance of said dependency is now on you. many times app store connect has changed some api and fixing our release process was a matter of updating fastlane because the community had already dealt with it, that's on you if you have a bespoke delivery solution.
The llm is the better community tool. The important change is that you don't have to settle with someone developing a monolithic tool that happens to do what you need it to do. That was the way things used to need to be done because of the cost.
Xcode does have (or had, haven't checked for a while) a lightweight "command line tools only" installer. Unfortunately, that installer omits a lot of the actual useful command line tools, like the notary and stapler tools. I also recall that the command line tool only installer leaves out things like the metal compiler, too. Not sure what the point of it is.
My only familiarity with it is because it's needed by brew. I honestly never looked into exactly what is in the package, but I assumed things like what is installed with -devel packages of yum/apt-get/dnf/etc. Lots of repos have common list of things to install like gcc/make/etc. Again, just guessing, but it's one of the first things I've always run on a new Mac to get it usable for CLI usage.
If it's okay to mention my own complementary open source project, Axiom¹ does a good job of helping coding harnesses know how to do this effectively for Apple OS development.
In addition to a deep roster of skills and agencts, Axiom includes several for-LLM tools². xclog, xcprof, xcsym, and xcui are designed to be used by LLMs, and expose capabilities in a token-efficient way. These tools are equally helpful for non-Axiom skills/agents.
Silly question, but do you reckon it'll function decently in a Kotlin multiplatform codebase? There's swift native code, but I'm not sure how it would perform with some logic being shared.
Not silly at all. For Compose Multiplatform, Axiom won't do much for code review or generation. It might be useful for operations on the built app: console capture, crash symbolication, simulator UI/accessibility driving, CPU profiling, plus the whole shipping layer (signing, privacy manifests, submission).
I just set up my pipeline to do this exact thing for both the Apple and Android ecosystems, dispatching loads to my mac studio or Linux box accordingly. I moved the runners off GitHub because uptime for GitHub actions has been trash lately, and the Apple Silicon runners are pricey.
Claude was great at figuring out what was broken when and either fixing it, or clicking as far as it could until it needed me.
You could say I'm mostly just IRL hands for the AI now.
Being outside of the approved development loop has rough edges. How do you keep the app from putting up that permission to access documents folder all the time while you rebuild it?
What could go wrong? Might Apple change something across five ecosystems and leave you in the lurch, and now you have to go through all the slop to try to fix it?
I've used opencode on a plane with local models to make small updates to local MacOS apps. It's not fast or amazing, but it does work well enough to do trivial changes.
Making your app buildable from the CLI is not something I do personally to use on my Mac but it is very useful when you're automating your CI. If you have GitHub Actions set up to build your app, so can Claude, assuming you have the right signing setup on your machine.
Oh god, the app store does not need more slop. If you can't be bothered to open XCode (which I agree is a dumpster fire, but), you shouldn't be bothered to submit an app that a person has to review and another person has to filter out of their search results.
Counterpoint: XCode is such slop that an app made by a developer with the taste to avoid it has a higher probability of being less "sloppy" than average.
I don't know if that's really practical unless you're full-on-vibe coding or you avoid all the native frameworks. You kinda need XCode for a lot of things. I personally really dislike XCode after having to use it for like a decade and having it crash six times a day, so I feel people's pain in wanting to avoid it, but I also think slopping up the app store with vibe code monstrosities is not something that should be encouraged. Bad ideas are better made inconvenient..
I’ve been doing the same except that my linux installation is via WSL on Windows. I’ve been using sideloadly to move my IPA over to my phone. Works great.
So you can develop ios apps, run it on a real iphone that is activated without going through app store as a native app? But, you have to reinstall it every week?
Check also Sweetpad CLI. It’s basically wrapper around xcodebuild, but humans and agents. It’s my next project after Sweetpad VSCode extension for developing iOS/Swift applications in VSCode. Cli is still in beta, but I see on my own project that it’s already quite pleasant to use
Wait, I am not aware that I've done ANY of those setup steps, yet I'm building iOS and macOS apps without XCode. Both Claude and Codex handle it just fine and didn't ask me for any setup steps.
I went to build an open source app from GitHub and was pretty surprised that it requires Xcode and that Xcode can't really be installed without an apple id. I do not want to make one and I certainly will not sign my computer into one.
I did end up somehow installing Xcode via some shady download and was on my way. But the whole ordeal left a very sour taste.
Though the primary way of installing Xcode is via MAS (requiring Apple ID login), Xcode can be downloaded from the Apple Developer website without an ADP membership, though you do have to log in to the website with an Apple ID. You don’t have to log into the Mac with an Apple ID though, you can then install and use it on a Mac without an Apple ID (though you will need one inside Xcode to sign apps to get them to run on an iOS device).
Tangentially, I despise Xcode and love the Expo ecosystem and all the lovely tooling that they have built. It is React Native but Expo honestly makes it so trivial to build stuff from the CLI without ever needing to open that abomination of an app. And with AI, I have built a lot of side project apps onto my iPhone, like a homelab app for monitoring my cameras with push notifications whenever someone is at the door, starting my irrigation and a whole lot more. Plus Tailscale of course. Kind of a crazy world that we live in now.
As someone who tried my very best to not open Xcode for building and shipping Mac and iOS apps, I agree, there are things there are literally no way around opening the GUI, not even terminal utilities for. You cannot do this 100% headless, which is what I attempted at first.
204 comments
[ 3.2 ms ] story [ 46.6 ms ] threadInterestingly, since about Opus 4.6, Claude has been able to reason its way into this process on its own. It was clunky until 4.7, and in 4.8 it's managed to find its way around every reason I had to open xcode myself.
> I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks.
Even though the text we're reading is Claude talking to us as well :)
Also it was weird to see the mention of "ask your LLM" at almost every stage in the blog post:
> point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out
> When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway.
> The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do.
> Again, if in doubt, ask Claude Code or your LLM of choice to create this for you.
> Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow.
If I had to guess, I would say this is the human summarised conversation(s) with a bot.
I am getting a little tired of every single HN comment being about how the linked article is written by an LLM.
I'm not getting that vibe from this one; I'd bet money on it at least being substantially human edited. What are the tells you're seeing?
My only familiarity with it is because it's needed by brew. I honestly never looked into exactly what is in the package, but I assumed things like what is installed with -devel packages of yum/apt-get/dnf/etc. Lots of repos have common list of things to install like gcc/make/etc. Again, just guessing, but it's one of the first things I've always run on a new Mac to get it usable for CLI usage.
I’m not defending Xcode (I hate it), just clarifying.
In addition to a deep roster of skills and agencts, Axiom includes several for-LLM tools². xclog, xcprof, xcsym, and xcui are designed to be used by LLMs, and expose capabilities in a token-efficient way. These tools are equally helpful for non-Axiom skills/agents.
¹ Axiom: https://charleswiltgen.github.io/Axiom/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/
Claude was great at figuring out what was broken when and either fixing it, or clicking as far as it could until it needed me.
You could say I'm mostly just IRL hands for the AI now.
* and giving Anthropic all your secrets, env vars, certificates and your source code to them.
Anthropic isn't great at keeping stuff private as we saw with the Claude Code leak. The more information they get access to the bigger the risk.
But also yes this is a real concern.
https://rubynative.com
“From bundle install to your phone in minutes. To the App Store and Google Play without a line of native code.“
Surprisingly, it's very easy. This works like a charm: https://github.com/xtool-org/xtool
You do not need to upload to TestFlight or the App Store; you can just the app locally to your iPhone via usb -- even from Linux!
When in doubt, just ask your coding agent of choice to help you create and upload a Hello World iOS app. It's really easy.
This is the perfect use case for a skill: one person takes the hit to create the skill and then anyone else who wants the tool can use the skill.
So you can develop ios apps, run it on a real iphone that is activated without going through app store as a native app? But, you have to reinstall it every week?
1. https://sweetpad.hyzyla.dev/
2. https://github.com/sweetpad-dev/sweetpad
The most useful one is a little weather sparkline to show local temperature forecasts. Useful every day.
I did end up somehow installing Xcode via some shady download and was on my way. But the whole ordeal left a very sour taste.