Building and shipping Mac and iOS apps without opening Xcode

Article URL: https://scottwillsey.com/building-and-shipping-mac-and-ios-apps-without-ever-opening-xcode/

Comments URL: https://news.ycombinator.com/item?id=48896665

Points: 497

# Comments: 211

Hacker News 讨论

497 points · 211 comments · 查看原帖

codazoda
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 fe
kxxx
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.
CharlesW
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/
Tiberium
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
ChrisMarshallNY
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).
octavore
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
searls
I've been using agents to develop Mac and iOS apps for over a year now and I would say this post is bad advice, particularly because the excellent Xcode MCP requires Xcode to be running. The MCP tool gives you faster, better access to a number of functions for which xcodebuild is much slower and much chattier and a number of others (like the #Preview generation and rendering) that aren't possible at all while Xcode is closed. Also, in Xcode 27, the MCP & built-in agents are able to drive simulators with DeviceHub extremely well. (If you haven't been following, DeviceHub replaces Simulator.app and as far as I can tell, it's actually scrutable by agents without relying on hacking at the accessibility APIs with tools like axe.) Xcode MCP is not perfect, by any stretch (stupidly, it issues a permission prompt on every single agent launch—something I defeated with a Keyboard Maestro hack to a
gen2brain
I have a nice setup on my Linux for iOS apps. I compiled the OSXCross toolchain, and also copied iPhoneOS.sdk and iPhoneSimulator.sdk from the macOS VM. With some wrappers, I can compile iOS apps (Obj-C) on my Linux machine, sign them with zsign, and use go-ios to install them on the device. At first, I just used simulator builds to test (and debug) on the macOS VM, in the simulator, but that was slow and painful. Finally, I bought a used iPhone, all bruised, just so I could test it on a real device. The main issue for me was signing, one cannot register a macOS VM (maybe with some kext hacks?), I managed to enable developer mode on the phone (crazy process, but it worked with Xcode in a VM), I registered the phone on the website, and paid those damn 99$. I used that for my cross-platform UI library with native controls, based on IUP. Now, future users of the UI toolkit do not need to ca