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

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

> 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)")
      }
  })

Strong “I’ve never had to deal with serious security problems stemming from a weird edge case, so this all seems silly to me” vibes.

RYO is the best way to learn, if you have the time to learn. After building one own solution one is able to assess the strengths and weaknesses of what other more experienced people built. Without the learning phase those other solutions are incomprehensible black boxes. The trick is not to skip the phase in which one researches available solutions.

> RYO is the best way to learn, if you have the time to learn

The problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.

Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.

Honest question: is there anyone truly good at security who never made a potentially-disastrous dogfooding mistake while learning?

Not to decent mistakes or amateur brain surgery, but there has to be some level of risk tolerance among tinkerers.

Developing software that has the sole purpose of preventing something dangerous from happening is exactly when people should strive to be engineers, not tinkerers. Beginners often don’t know the difference.

Learning as you go is great if you’re not basing your core development workflow or data integrity on it.

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

Setting the convenience knob to very convenient in a system that has a lot more eyeballs on it will always be better than having something that one person who, let’s be real, probably doesn’t even have journeyman-level coding skills, estimates to be very secure based on what the model told them and a quick-skim code review.

It’s also a hell of an indictment of this community. FreeBSD is a community project. Qubes is a community project. SELinux is a community project. And people wonder why developers don’t take vibe coders seriously.

"Apple Containers"

I love how people say this like Apple finally created a native solution...

They didn't. It's just a linux vm running normal docker engine.

> It's just a linux vm running normal docker engine

OCI compatible, but not docker

https://github.com/apple/container/blob/main/docs/technical-...

Actually makes use of Virtualization.framework mentioned above.

How else do you want people to refer to Apple’s tool called container?

Does anyone actually use one of those for iOS development?

Linux VMs are not relevant here. For downloading Xcode and building apps, I believe one needs to sign in with their Apple account.

Does this work well with a macOS VM?

Yes! That is arguably the killer feature. You can virtualize macOS in macOS with (nearly) native speed and this is officially supported. Heck, even can run multiple of them at the same time.

See docs here: https://developer.apple.com/documentation/virtualization/vir...

And projects like Tart, VirtualBuddy, etc. provide convenient wrappers for these APIs.

The limit is two. You are not allowed to run more than two macOS VMs. Also Tart VMs have problems with signing into icloud and other things that need a real secureID enclave.