Live data from Hacker News

Building and shipping Mac and iOS apps without opening Xcode

scottwillsey.com

91–100 of 248 posts

Re: Building and shipping Mac and iOS apps without opening Xcode

#91

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 ch…

I've been working on a wrapper harness that runs claude as a separate user named `agent`. I tried this about a year ago and couldn't get it to work because of OAuth and the keychain, but took another pass recently and claude had enough self-knowledge about recent changes to say we could do it with CLAUDE_CODE_OAUTH_TOKEN. It has required building a some tooling around permissions setup with ACLs but it works on macOS today.

In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.

I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.

It is not currently published open source but I'm happy to talk about it with strangers.

Re: Building and shipping Mac and iOS apps without opening Xcode

#92

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

That's good to hear. I never even tried to make anything for macOS because I opened Xcode and.. well, you know.

Re: Building and shipping Mac and iOS apps without opening Xcode

#93

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 ch…

You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.

An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/

Re: Building and shipping Mac and iOS apps without opening Xcode

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

Re: Building and shipping Mac and iOS apps without opening Xcode

#95

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 ch…

Your sandbox can be a separate Mac user account.

You can also use native Mac VMs.

Many people have created Mac VM projects to do exactly this, I was working on one but was stalled too often because before I started using claude I bought a new laptop with what I KNEW was enough disk space.

The 100 GB or so I need to comfortably do the VM stuff just isn't available on my mac.

Re: Building and shipping Mac and iOS apps without opening Xcode

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

Re: Building and shipping Mac and iOS apps without opening Xcode

#97

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 ch…

I've been running my agents in a docker sandbox that automatically mounts the current directory. It's been a bit of a pain to figure out and maintain the set of tools I provision into the sandbox- but it's fun to watch codex go to the ends of the earth trying to figure out solutions using nodejs (the only runtime).

Re: Building and shipping Mac and iOS apps without opening Xcode

#98
post #80
post #8

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 n…

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

Re: Building and shipping Mac and iOS apps without opening Xcode

#99

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.

What's a not-simple app? I've had Claude generate:

* A Markdown viewer (obviously pretty simple)

* A menu bar Apple TV remote (surprisingly complicated)

* A menu bar and desktop temperature tracker for the silly Tapo temperature trackers I have all over my house (a little complicated because multiple user interfaces, a backing database, scheduling, and multiple local/remote protocol interfaces)

* A graphical CAS calculator frontend to Sage Math with LaTeX math rendering

* An LLMwiki implementation that uses macOS filesystem extensions to reflect a SQLite database into a local filesystem for agents to traverse (basically the new macOS way to do FUSE, fussy enough that the app has to run out of /Applications to work)

* An agent-driven Music.app replacement with AirPlay streaming support managing Apple Music catalogs and tracks

All of these have worked without me ever once touching the xcode UI, except one time to generate Apple Developer certificates, which I then drove exclusively from CLI tools.

These are all pretty modern SwiftUI applications.

Re: Building and shipping Mac and iOS apps without opening Xcode

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

Post reply on HN