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
Building and shipping Mac and iOS apps without opening Xcode
151–160 of 248 posts
Re: Building and shipping Mac and iOS apps without opening Xcode
#152Earlier 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.
On "Hacker" News of all places :)
Re: Building and shipping Mac and iOS apps without opening Xcode
#153Re: Building and shipping Mac and iOS apps without opening Xcode
#154Earlier 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?
Re: Building and shipping Mac and iOS apps without opening Xcode
#155Earlier 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 :)
vs
> vibe code your own wrapper around the OS API
Re: Building and shipping Mac and iOS apps without opening Xcode
#156Earlier 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.
Re: Building and shipping Mac and iOS apps without opening Xcode
#157Earlier 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
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
#158Everyone 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 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
#159One 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…
Re: Building and shipping Mac and iOS apps without opening Xcode
#160Xcode 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.