{"id":28786,"date":"2020-04-23T15:12:45","date_gmt":"2020-04-23T19:12:45","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28786"},"modified":"2020-05-18T16:56:45","modified_gmt":"2020-05-18T20:56:45","slug":"bloomberg-arm-macs-in-2021","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/04\/23\/bloomberg-arm-macs-in-2021\/","title":{"rendered":"Bloomberg: ARM Macs in 2021"},"content":{"rendered":"

Mark Gurman at al.<\/a> (tweet<\/a>, Hacker News<\/a>, Slashdot<\/a>, AppleInsider<\/a>, MacRumors<\/a>):<\/p>\n

The Cupertino, California-based technology giant is working on three of its own Mac processors, known as systems-on-a-chip, based on the A14 processor in the next iPhone. The first of these will be much faster than the processors in the iPhone and iPad, the people said.<\/p>\n

Apple is preparing to release at least one Mac with its own chip next year, according to the people. But the initiative to develop multiple chips, codenamed Kalamata, suggests the company will transition more of its Mac lineup away from current supplier Intel Corp.<\/p>\n

[…]<\/p>\n

The first Mac processors will have eight high-performance cores, codenamed Firestorm, and at least four energy-efficient cores, known internally as Icestorm. Apple is exploring Mac processors with more than 12 cores for further in the future, the people said.<\/p><\/blockquote>\n

This is another good reason to postpone or scale back macOS 10.16. We want the software to be in as good a shape as possible before a big hardware transition. Apple will have even less time to fix bugs, and developers less time to work around them.<\/p>\n

I expect the ARM transition to be accompanied by removal of lots of APIs, so developers will have to contend with that, as well as porting and testing their own code, and dealing with any dependencies that have broken.<\/p>\n\n

Gus Mueller<\/a>:<\/p>\n

\n

I don’t think unifying the chip architecture would make the app ecosystem any more unified. Apple could do this today if they really wanted to, fat binaries (where different cpu architectures are combined in the same application) have been around forever. Major frameworks are already on both architectures, which is the biggest hurtle. I think the problem is more philosophical, or maybe Apple just lacks the will or vision to actually get it done today, if ever.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n