Technical limitations aren’t excuses for a bad design. If it’s not a good design due to a technical limit, the answer isn’t to sacrifice security for functionality.

If it really isn’t technically possible (which I think you might be able to do in a Darwin VM), then maybe this approach isn’t a good idea.

> Technical limitations aren’t excuses for a bad design.

Tomorrow Apple might decide it is safe to chroot with SIP enabled (I actually do not understand why they restrict it, chroot is a tool to increase security). Does that suddenly convert bad design into a good design? But this is exactly the same design.

Design operates within the contexts of a system. A perfectly viable design can be made bad by a change in the system for which it was designed.

Does this current design require disabling SIP? Then I don’t think it is worth my effort to use (for my use case). If Apple changes the system in the future, my opinion might change.

But a design cannot be judged as good or bad outside of the context for which it was designed.

If you feel this is a better way to tackle the problem, then talk to Apple about it.