There's been many examples in the past enforcing specific types of properties or immune to entire classes of attack. A few survived years of NSA pentesting. I'll give a simple example: Burrough's 1961 product with a tag on memory words. One bit said it's a pointer that processor hardware protects against forgery or improper modification. Array's were bounds-checked by hardware. One bit said something is code, execute but don't modify, enforced by processor. Function calls arguments were validated by compiler during installation and hardware during procedure call. This combination makes almost every code injection attack I've ever heard of fail while using very little hardware overhead. One exception to overhead is runtime procedure checks. Leave it out & you still knocked out almost every way to take over systems with software vulnerabilities.
There's dozens of designs doing similar things in academic literature, on the web (see crash-safe.org or Cambrige's CHERI), in government (see Sandia Secure Processor), and even commercial (see CodeSEAL architecture). Yet, the tiniest modifications (pointer/array/code protection) would give attackers considerable headaches. This must be integrated with other security methods, of course, along with toolchains (esp compilers) modified to use it and any custom software (esp assembler) modified to use it. Those changes are well within Apple's budget. They also bought an ARM license and a fab deal, meaning they can do the hardware mod.
At this point, there's no excuse for our machines to be vulnerable to pointer, buffer, or memory-based attacks given 1960's technology was immune to these by design. And we could adopt such methods relatively inexpensive today. And academic prototypes running FreeBSD and Linux only cost a few mil versus Apple's tens of billions available. Yes, it has been done, can be done, and is simply not done as usual.
> I'll give a simple example: Burrough's 1961 product
But the key there is "simple" - I imagine that's a tiny fraction of the size and complexity of a modern smartphone ecosystem. Scaling it up to a device that can be manufactured at a profit and will sell hundreds of millions is surely more involved than "we could adopt such methods relatively inexpensive today".
That was a mainframe, actually. They're quite complex. The mechanism is simple. I have designs that apply it to a smartphone by a tiny change to the processor and its I/O system. Far as the hardware, that's it. For the software, the C (or Objective-C) compiler just has to use the appropriate tags or instructions when generating the binary. Any hand-written assembler, a tiny portion of the program, must do the same. That's it for the pointer & code protection. On a smartphone, this is the main SOC, drivers, part of the compiler, and any assembler functions. That's it.
There's no need to speculate, though. Several academic projects involving a few amateurs with six to seven digit funding have (a) modified processors for security, (b) modified toolchain to support it, and (c) ported BSD/Linux to it. Others did it for embedded systems. Their schemes are usually much more complex (see Cambrige CHERI processor). Unrealistic to think Apple can't do with 9+ digits less than what academics do with 6-7.
That does rather imply that such a thing is possible and the entire history of computer science would indicate that it isn't (yet.)