Building and shipping Mac and iOS apps without ever opening Xcode

One down-side to this is that it does require you to run the agent on your Mac instead of in a Sandbox. I do this too and there are lots of problems I can't solve in a sandbox. I know a lot of you are throwing your hands up at the years of security practices we're throwing out the window when we do that.

The fact that xAI uploaded someone's home directory, including their SSH keys, is giving me serious pause at my choices here.

Generally, I don't worry about my machine being "blown up". I don't have a TON of unreproducible stuff on my machine. Everything is backed up, committed to git, and the like. I can restore most of it in a couple hours.

That said, I really, really don't want my .SSH directory sent to an AI agent and it's silly to prompt your way around that. You need to block it at the system level. I'm considering a separate user and then 700 permissions on my home directory.

I feel like we're back to 1990's security here. The double-edged sword is that it's helping us get things done at a pace like never before.

I'm not throwing shade here, I'm among the guilty.

I've been building and testing my iOS app just for fun via Linux only.

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 install 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.

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.

¹ Axiom: https://charleswiltgen.github.io/Axiom/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/

It's kind of funny to be reading this:

> 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.

Shameless plug: I've been working on strudel [0], a CLI that uses a lot of the same ideas in this post and allows you to build/sign/notarize Mac (and iOS) apps without touching Xcode. It has a dry run mode so you can see the actual commands being run, which was important to me to have so there's no mystery about what's happening.

I should blog about more this, but I also went to some effort to add support free iOS provisioning with just an Apple ID (using internal APIs); and creating a nice DMGs for macOS app distribution (reverse engineered .DS_store files for this). And there's also a built-in command to install skills for coding agents, which was fun.

This [1] is an example app I built with it, a simple utility to manage macOS file extension handling.

[0] https://github.com/octavore/strudel

[1] https://github.com/octavore/tots.app

Technically, you are using Xcode.

Xcode is a [buggy as hell] GUI wrapper for a lot of system-level UNIX utilities and apps [which are generally, not so buggy].

Using CLI to release apps is a pretty old practice; at least as long as I've been doing it (I released my first Xcode app in 2012).

Xcode 27 which is in beta ships a much better codex integration. There are problems in Xcode that are frustrating . Also, git integrations are a nice touch that allow you to force push too. Would be interesting to find out how well this works in a team based setting.

Everyone will still need to use Xcode for at least some debugging, no way around that.

As for the builds, your agent probably already knows how to do a lot of this from the command line, although explicit suggestions can help it build faster for different situations.

As for XcodeGen, you may find it unnecessary overhead if you're already using Xcode file system synced groups.

For iOS my biggest suggestion would be to enable App Store Connect skills for your agent (https://github.com/rorkai/App-Store-Connect-CLI).

With this not only do you not need Xcode all the time, you also don't even need to be near a MacBook.

Just make changes via Codex on your iPhone, the tell asc to build and upload to TestFlight, download and run the new version, iterate.

I have one weird trick for people who are exploring this vein. I last opened an Xcode project about five years ago so I could be way behind the times.

Having spent many years fighting with Xcode professionally, I was thrilled when swift build came out, and then appalled at how badly Xcode adopted it. Eventually I realized that you can set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` (or whatever you want to call it) function in your package.

I cannot remember exactly but there was something annoying about setting up a new project; I think by default Xcode assumes that you want a swift package to be treated as a dependency that is checked out from git, but there was a way to drag and drop a local dependency in the same project directory and then it worked.

What this buys you is that files are no longer tracked by Xcode, so renames/merges no longer trigger project.pbxproj surgery. Instead you specify the swift package directories and are done.

I used this for some large personal projects and was very happy with it.

At one point I also wrote my own build tool that imitated all of the steps that Xcode took so that I could truly be Xcode-free. That also worked (and was not even that hard) but I went back to Xcode because the debugger UI was better than what I could get out of VS Code at the time, and especially because I was playing around with the Metal debugger.

In my experience, the better long-term choice if you're going to vibe code an app is to use Expo.

Its basis is React, so the code output quality is much higher than Swift because there is much more React code in LLM training data.

Everything is in the command line, and debugging is a breeze because it's a web view. But once it's compiled to native iOS, it feels like any other native app.

Expo + Fastlane = fully automated iOS submission and deployment. I issue one command and see a new version in the App Store.

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

1. https://sweetpad.hyzyla.dev/

2. https://github.com/sweetpad-dev/sweetpad

Interesting this is coming across as novel. This is how CI build machines for Apple’s platforms have been setup in perpetuity.

Regardless of the vibe coding aspect, there's good information here for anyone new to the mac/ios build/distribution workflows.

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.

The main iPhone app I maintain for work is 100% claude edited now ... I don't touch the code anymore ... I do occasionally look at it. It does a way better job than I could. I do have Xcode open as claude does its thing ... and I occasionally sign and deploy with Xcode. No coding though.

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 (and I think something for HealthKit).

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 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.

I find it hard to believe xcodegen is in a state where it would reliably generate xcodeproj for all edge states (widgets, watchos app, notification extensions …) - it certainly wasn’t when I last tried it for Weathergraph few years ago.

That said, it might be well enough for simpler apps.

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.

Or use https://swiftbundler.dev/ ?

built cable detective like this https://apps.apple.com/at/app/cable-detective/id6765963737?l... and the soon to come https://aifcc.franzai.com/ which is more ambitious

honestly would not even know what to do / click in xcode

You can as well make it simpler and use those skills:

https://github.com/software-mansion/argent

or

https://github.com/callstack/agent-device

both callstack and swmansion are mostly react native shops but those should work even in native ios/android as well

Having to have Xcode installed is more than half the problem. It makes Visual Studio look lightweight.

Shout out to fastlane! I would have loved to have found it sooner in my app shipping journey.

In addition to the challenged Xcode, just using Swift seems to require a lot more tokens for both coding and dealing with build/platform quirks. Probably not super significant on indie scale but for anything more robust, it builds up quickly.

React Native and Flutter seem to be much more predictable for the bots (and more fun for humans, since they have actual hot reload).

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.

Doesn't that mean you need to distribute the app (TestFlight) before you can preview your app? How do you test locally without the simulators?

I’ve done this forever on Foqos. Have a makefile, never even open Xcode and the instructions are in the agents md

I've built a few small MacOS dock widgets now by just telling Claude/OpenCode to build them. Works well enough if you're very explicit.

The most useful one is a little weather sparkline to show local temperature forecasts. Useful every day.

I thought this would be a flutter post. Love flutter, ... , well I like flutter compared to Kotlin and Swift

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 prefer Tuist (writing Project.swift) to XcodeGen but otherwise, yeah, this tracks

Thought this was going to be about the new Ruby Native!

https://rubynative.com

“From bundle install to your phone in minutes. To the App Store and Google Play without a line of native code.“

> Without Ever Opening Xcode

"Next, open Xcode"

The thing is, in a perspective, who would need any apps at all? Users will get what they want from AI directly.

I do something similar in GitHub actions. Every new app is setup in a few minutes to star getting rejected by iOS and Android.

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?

Although this has been well known for years and documented.

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.

Skimmed the article. Pretty close to my workflow using fastlane with tauri.

Useful sanity check!

I spent seven years as a dev on the Xcode team and this is pretty much my exact workflow these days.

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.

You still have to open Xcode (to get the certs), and you still have to accept the Xcode EULA. Title is quite misleading if not outright false.

By using "Claude Code"*

* and giving Anthropic all your secrets, env vars, certificates and your source code to them.

Don't make apps for iOS. The apple ecosystem is horrendous

[flagged]

[dead]

[dead]