For everyone complaining about Apple taking away something or other that was important to you: please consider what SIP&#x2F;&quot;rootless&quot; actually is.<p>What Apple have done here is not anything like the &quot;dev mode&quot; switch on Android, or the Gatekeeper &quot;signed code only&quot; setting. This change <i>isn&#x27;t</i> another of the litany of changes that expand the gap between developers and regular users. This change is, instead, about creating a different <i>model</i> for how OS modifications happen.<p>For a while now, there have been two copies of OSX on a Mac: the &quot;regular use&quot; one, and the &quot;recovery&quot; partition. Both are full OSX, and can run arbitrary OSX software; it&#x27;s basically like having a copy of the Linux Live CD you installed Linux from copied to your disk alongside the actual Linux install.<p>With SIP&#x2F;rootless, Apple has effectively made it so that instead of the actively-running copy of the OS ever modifying <i>itself</i>, the OS will only ever modify <i>the other copy of the OS</i> on-disk. So you need to have the recovery OS running to modify the files of the &quot;regular use&quot; OS†; and you need to be running in the &quot;regular use&quot; OS to apply a <i>recovery update</i> (i.e. an update to the recovery OS.)<p>The procedures for <i>getting around</i> SIP by disabling it and then running things, are as arcane as they are because they&#x27;re quite divorced from the <i>reason</i> for SIP. SIP isn&#x27;t supposed to be a system for blocking and whitelisting kernel-hooking apps; it&#x27;s a mechanism for making the OS into something more like CoreOS or the Wii&#x27;s IOS: a system with two separate on-disc OS images, where at least one is always a Last-Known-Good configuration, and where you reboot into the &quot;spare&quot; one when you want to replace the previously-&quot;active&quot; one. You never fiddle with the &quot;in-use&quot; OS image; you consider it locked.<p>You still have root on the computer. You just have to be in OS-A to do root-level things to OS-B, and vice-versa.<p>An analogy: remember how it was impossible (and still is, on some OSes) to resize the boot partition you&#x27;re running from, requiring you to instead boot from a USB to do that? That&#x27;s basically what is happening here, except without the need for the USB. You can&#x27;t do stupid things to the active OS; it&#x27;s locked. You modify the OS by mounting it as a slave from another copy of the OS.<p>---<p>† I&#x27;m not actually sure how system updates from the &quot;regular use&quot; side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it.<p>I would guess they work like iOS updates do: the update package gets downloaded by the running OS, and then a UEFI flag is written to tell the OS to reboot into the recovery OS in &quot;update&quot; mode. The recovery OS then unpacks and shoves the update, and reboots back.<p>If there <i>is</i> an exception in SIP for the Installer, it was likely considered more as an optimization over the above process—something to avoid making OSX feel like Windows XP, rebooting five times to get anything done.