I considered chiplets but I probably dismissed them prematurely based on my understanding that they introduce some efficiency loss, and it would be un-Applelike

I considered chiplets but I probably dismissed them prematurely based on my understanding that they introduce some efficiency loss, and it would be un-Applelike to make their iDevice cash cow less efficient in order to serve the Mac niche. They do open up a ton of flexibility in using different nodes, configs, improved yields, etc. Seems they're actively researching various methods [1], and the whole semi field is moving that way, so I agree with you if they work well that's probably the way they'd build chips for MED and HIGH use cases. I revise my assessment after further thought :) There's definitely software work that would need to make Intel chips co-processors, but I'm not sure it's a monumental task. There's already some of this happening today with T2 chips handling video encoding/decoding in certain apps, and of course discrete GPUs already act as co-processors with their own resources for many tasks, so this approach isn't unprecedented. In this co-pro idea I'm proposing, the OS is run by arm64, and depending on the binary they route to either x86 or arm64. Developers would have some control over that, and legacy x86 binaries would automatically run x86 on machines that had Intel chips. Discrete GPU wouldn't require significant driver work if discrete GPUs were only available on machines that had Intel chips. That might be a good practical point to differentiate if the chiplet approach lets them design even higher powered GPUs for LOW and MED products. Again I don't see this much as a cost-issue, but as a strategic issue. They can spread costs over 5 million Macs in multi-year transition, and this would be partially or fully offset by cheaper hardware & ability to ship differentiated hardware that better suits markets Apple wants to pursue. Unless costs are massive, it seems like not a hard thing to justify. Personally I just can't see x86 instruction set becoming more important in the next decade+ when already it's been eroded from mobile & server fronts and less important because of improved software tooling, and Intel is perpetually floundering. Feels like a bad bet. The simplest path / null hypothesis to disprove is LOW/MED get A-series chips, HIGH get Intel + dGPU + T-series, and multiple versions of macOS & multiple binaries of apps are shipped. That's only acceptable for a few years I think due to higher maintenance cost. If the Intel co-processor approach is not difficult software-wise, that seems beneficial because it might simplify OS/kernel/system maintenance as that would now just run on A-series chips. Putting Intel in an easily-removable VM-like corner would give Apple more flexibility to ship future products that serve different market segments (e.g. the oddball Mac Mini), and potentially extend decision if/when to drop them. The point about frequency/voltage is an interesting one. I figured there'd be at least 10-30% possible difference, accepting efficiency loss at higher frequencies (less an issue on larger chassis). At least in the past, A9 ran at 1.85ghz and A9X at 2.26ghz, but A10 v A10X and A12 v A12X [2] are equivalent, so perhaps you're right that on leading edge nodes they're just going to optimize for max efficient freq. Anyway, that's all single-thread CPU, and as A-series chips get closer to desktop in IPC, differentiator for larger machines is primarily more threads/ram/gpu. Good chatting, thank you for insights. [1] https://www.macrumors.com/2018/06/12/apple-3d-chip-packaging-patents/ https://www.macrumors.com/2018/06/12/apple-3d-chip-packaging... [2] https://www.anandtech.com/show/13661/the-2018-apple-ipad-pro-11-inch-review/4 https://www.anandtech.com/show/13661/the-2018-apple-ipad-pro...