CHERI is very ambitious but also very different what we have now in a lot of subtle ways. TL;DR: CHERI changes how pointer work and needs both hard and softwar

CHERI is very ambitious but also very different what we have now in a lot of subtle ways. TL;DR: CHERI changes how pointer work and needs both hard and software support _all through the stack from kernel over drivers to your end user application. Companies will be very careful (slow) about evaluating and adapting it, there are many challenges both technical and organizational(people). TL;DR2: CHERI is experimental both in software and hardware I think there isn't even a python interpreter which works with the fully enforced (pure-capability) CHERI. Now to be clear how much your software needs to change depends a bit on weather you use the pure-capability API or the hybrid API but if you use the hybrid API and don't recompile your code in a way which might require code changes you are not getting any security benefit and at least the kernel (and in turn in-kernel drivers) should all work in pure-capability mode. But that means your pointers now all are 128bit consisting of an address and a tag. And while a lot of pure C/C++ standard compatible code not doing anything fancy will work, a lot of C/C++ code does fancy things and will not work. E.g.you can't cast a CHERI pointer to a int and back and expect it to work as the int only represents the address but not the tag (through doing so is anyway highly problematic due to pointer provenance). C/C++ programs written using a "C is just high level assembly" or a "pointers are just memory addresses" or a "data is just bits in RAM" approach already cause a lot of issues today due to UB and with CHERI this approaches work even less. And even if you program does work, due to 128bit pointer size it might have performance problems it didn't had before needing optimizations it didn't need before. And non of this is even considering weather or not it can effectively be integrated in the current Apple ARM hardware without causing layout or performance issues (it might but it might also not, I think only apple can answer that properly. I mean it definitely is possible but it comes at a (work time=money) cost which might be not so small). If I would be Apple I would wait for the adoption until the ecosystem around CHERI becomes more mature and when it start showing signs of success help it actively to become more mature. But for that you need: - non experimental ARM ISA extensions - better language support (I don't think there is any Swift CHERI support) - more experience with porting large software stacks to it - porting of their Kernel, drivers - porting of their core libraries (for simplicity lets assume iOS), notably here is e.g. their JavaScript VM - adopting their current iOS specific security mechanisms to CHERI - creating a lot of tooling to make migration for developers feasibly (no less effort then they had to go through for the x86->ARM migration) and even then they still would need to support running apps in a compatibility mode for many years as they can't expect existing apps to be made compatible with CHERI as they can't expect all of the software stack that apps use to be made compatible. They might simple not care for smaller devs and force them but they can't do so for many of the larger companies core apps people expect. And all of this steps have supper funny surprise issues as there is code you can't make work with pure-capability cherry as it's too much designed around "clever tricks" which do not work with cherry. Like how does it affects JITs/AOTs and could there be cases where you can't make it work with pure-capability mode in a performant way. Like e.g. can you even make WASM AOT work with CHERI and if not can you require browsers to now have CHERI-WASM and non CHERI-WASM???