Hot reloading is typically considered to be concept of swapping out an implementation rather than literally unloading the code from memory. Objective-C is mildly limited by its C heritage but one can go pretty far with runtime trickery to get a similar effect. The other features were removed because they were not fully fleshed out and too unreliable to use.
For iOS, we used some runtime trickery to access private APIs. Was needed to access calendar invite details. Could see how a less benign developer could sneak malicious code past Apple's review process.
A famous example of self-modifying code was Microsoft's AARD code, which was decrypted on the fly to check if the user was running a competitor's OS. [1]
I always wondered if the perceived threat of runtime method constructors was an incentive for Apple to push for Swift.
Self-modifying code is prohibited on iOS by codesigning. However, achieving Turing complete execution capable of calling any API not behind an entitlement is very feasible and regularly passes App Store review for simple cases. The more complicated ones might too, but they aren't delivered via the store very often ;)
If you can convert data into an API call, then it becomes an issue of steganography. The only way to trust a binary is through 100% code coverage through all possible inputs, which is intractable.
Code signing and a secure enclave may help protect against local use cases, like ransomware, but doesn't protect against hybrid attacks, like granting access to 3rd parties.
Maybe this means that all binaries in 2040 should be derived from open source with AI doing the threat detection.
