Live data from Hacker News

Building and shipping Mac and iOS apps without opening Xcode

scottwillsey.com

151–160 of 248 posts

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

#151
post #35

Earlier quoted context omitted.

Claude telling us to point Claude to a web site written by Claude so that we can use Claude to create a build environment...

yo dawg

Claudius Claudianus (aka Claudian)

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

#152

Earlier quoted context omitted.

Of course, if you're not comfortable with reading or designing code, or don't feel like tinkering, you can use an existing project and they work great But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers

Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.

Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes

On "Hacker" News of all places :)

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

#154

Earlier quoted context omitted.

This is more challenging for macOS.

I've been doing it just fine on macOS for awhile now. What's challenging about it?

I think particularly for iOS development. I was all in on sandboxed approaches...until I went to build an app, and now unfortunately convenience won

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

#155

Earlier quoted context omitted.

Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.

Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes On "Hacker" News of all places :)

> don't do anything new, god forbid you may actually learn something

vs

> vibe code your own wrapper around the OS API

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

#156

Earlier quoted context omitted.

> require you to run the agent on your Mac instead of in a Sandbox You don't have to! All recent Macs come with nearly zero perf cost virtualization. You can easily run Mac or Linux VMs assuming same architecture. Use it all the time for development and whatever. Use Tart [1] or VirtualBuddy [2], both open-source, for a packaged solution. Or in the spirit of this post, vibe code your own wrapper around the OS API [3]…

>> I feel like we're back to 1990's security here. > vibe code your own wrapper around the OS API Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.

all community projects (specially the ones maintained or opensourced by model owners) will certainly have the security-convenience trade offs set all the way to convenience while advertising all the (off by default) security features

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

#157
post #155

Earlier quoted context omitted.

Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes On "Hacker" News of all places :)

> don't do anything new, god forbid you may actually learn something vs > vibe code your own wrapper around the OS API

In fact, I suggest reviewing the documentation to assess your own level:

https://developer.apple.com/documentation/virtualization/run...

If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial

  virtualMachine.start(completionHandler: { (result) in
      if case let .failure(error) = result {
           fatalError("Virtual machine failed to start with \(error)")
      }
  })

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

#158

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…

I’m chiming in here to say I did pretty much build an entire iOS app with agents, and it launched it on the App Store for me, along with a social push.

I only used Xcode to preview the builds on my device and then guide the prompts more

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

#159

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…

A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?

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

#160
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 auto-accept it), but Xcode 27 is such a huge leap forward in the ergonomics of vibe coding with Xcode that I've actually stopped dealing with the MCP and (after an afternoon of futzing) have started using the app's own agent UI for driving Codex because that harness better steers the model to take advantage of the tools available.

All of this redounds to two things: faster feedback and more robust verification. The two things that matter most.

Post reply on HN