It is important and interesting to notice the different use cases you mention. You don't have millions of software updates you have to sign every day (or second for that matter). For SSL connections, however, you may have millions per second. Given the two use cases, it makes sense that the way you would protect the keys would be different.
We don't know (AFAIK) how apple protects their OS signing keys. But, one good way to do it would be to store them on a separate computer that is locked in a highly secure room and not connected to any network. Only a few select people have access to that room. When a new OS version comes out, you take it into that room on a USB drive (or something like that). Signing the software requires two or more passphrases to unlock the private signing key. That way no single person can do this by themselves. Once two people have entered their passphrases, the private key is decrypted, used to sign the new OS updates, then wiped from the machine.
For the SSL use case, that private key has to be used millions of times per second. It is a very different use case. At this point you must rely on the security of the software (hopefully no one can exploit services running on your system), OS provided protections (making the private key only readable to the users/groups that need it), etc. You can also use hardware to help. Things like hardware security modules. These systems store the private keys in hardware and only provide a well defined cryptographic interface to them. That way if an attacker breaks into the machine, they cannot extract the private key. These may be useful in both use cases, but I would argue that they are more useful in the SSL use case.