Kuo: MacBooks With Apple-Designed Processors Coming Late 2020 or Early 2021, All-New Design to Follow in Mid 2021

[satchmo]

How long will Adobe take to transition their Creative Cloud?

When Adobe apps aren't even optimized for the current hardware, I'm not hopeful.
The numbers of installed ARM devices will be so small that it won't be a high priority (despite what any Adobe exec trotted out at a keynote announcement).
Compare that to the millions of installed Windows user base.

 

[thejadedmonkey]

If MBP become ARM, that would be disaster for some software developments, especially those that needs bootcamp....

Windows runs just fine on ARM. The CPU changeover shouldn't be an issue.

 

[oneMadRssn]

The first ARM MacBook should be the realization of the dream that the 12" Macbook failed to achieve (because Intel's ultra low power chips weren't fast enough or cheap enough).

I disagree with this premise. The 12" Macbook did not fail. It hit the mark exactly at the time and the 2017-models are still highly regarded. It was never meant to be a low-end and low-cost Mac - that is what the Air was for and still is. The 12" Macbook was high-end ultra-portable, and it does that very well.

 

[CWallace]

The Air will get the ARM chips. Switching the Pros would screw the Pros.

If Apple does not release a new model ("MacBook / iBook") with an ARM chip, the Air getting it would be the next logical choice (and more logical if the small MacBook Pro goes to 14.1" as rumored) as it uses the Y-series CPUs that the 2015-2019 MacBook did and an Apple A-Series CPU would be capable of offering similar or better performance emulating x86 code and far better performance running native ARM code.

 

[cmaier]

NOTHING has come from Apple about this. NOTHING.

right. Again, why would it?

 

[theluggage]

Windows runs just fine on ARM. The CPU changeover shouldn't be an issue.

Well, not quite - it is still very dependent on an x86 emulator to run 'legacy' apps which is, apparently, a less-than-thrilling experience - and I'm guessing that a lot of people running Windows on Mac hardware will be doing it specifically to get at that legacy, x86-binary, software.

In theory, most of what I've said in my earlier post about the relative ease of moving "modern" MacOS apps to ARM should apply to Windows - moreso because "modern" Windows code uses .net bytecode. However, there are two important reasons why MS can't force Windows onto ARM the way Apple can with MacOS:

1. Apple sells 99% of Mac hardware (assuming, for no good reason, 1% Hackintosh) and is even ~#4 in terms of global personal computer sales - so if they do say that Macs are going to be all-ARM from 2022 then it will happen and Mac developers will have to adapt or die.

Microsoft don't even make the top 5 in global PC sales and just don't have that kind of influence on the hardware market. There are currently a very few ARM windows machines, and AFAIK all of them are tablets/2-in-one's aimed at "personal productivity". Pro Windows application developers won't be falling over themselves to support these.

2. Microsoft has the huge change-averse corporate sector holding it back. For MS, its not just getting the publicly available applications onto ARM, there's a mass of bespoke, in-house-written business software that companies depend on (and who, of course, have fired the original developers and outsourced support to the lowest bidder). Apple can reasonably contemplate maybe completely dropping MacOS x86 support in - say - 5 years time, as they did with 68k, PPC, x86-32 and ARM 32 on iOS. MS Windows on ARM only? Ain't gonna happen - they've just dropped support for Windows 7 (8 years old) despite the fact that Windows 10 can still run 1995 binaries...

So, while its feasible that you'll be able to run ARM Windows on ARM Macs, that's probably not going to scratch your x86 Windows itch, and it could be the biggest single downside of ARM Macs. Question is, how important is it really?

Going forward, things like tax/accounting software (one commonly cited reason for running Windows on Mac) are likely to increasingly switch to web and mobile apps (e-banking is increasingly putting its new development into mobile). The need to continually test web apps on IE is greatly reduced now MS has switched to Chromium. The remainder - well, the big difference between Apple and MS is that Apple are prepared to periodically throw groups of users under a bus - that's partly why MacOS is like MacOS and not Windows.

 

[persuasiveghost]

Switching to RISC processors solely, imo, would be horrible for higher-end complex tasks that we use these machines for and compatibility for the whole software ecosystem and as others have said: software development.

 

[pearvsapple]

So it’ll be a gigantic iPhone in a laptop form factor. kthxbye RIP Macs

 

[theluggage]

that is what the Air was for and still is. The 12" Macbook was high-end ultra-portable, and it does that very well.

I think people were expecting the 12" to be the "new Air" and follow the same path as the original: start off as a premium-priced ultra-portable but evolve into the new entry-level. The (just) "Macbook" name suggested that, too.

Only Apple knows what the sales were like. They did have a bit of a pile-up at the low end with the 12" MB, the Air and the entry-level 13" "formerly known as non-touchbar" MBP (which is arguably the real 'Just MacBook' rather than a 'Pro').

I think the issue with the 12" is that Apple clearly want to position the iPad Pro as 'more than a content-consumption tablet' so the two products are really in contention, especially with touchpad keyboards, mouse support and full Photoshop lined up for iPad.

 

[God of Biscuits]

Adobe’s iOS development efforts don’t necessarily prepare them for ARM Macs.

Adobe’s move to OS X was slow because it was a different set of frameworks. ARM Macs will have the same frameworks. Same developer tools. Apple already requires 64-bit apps, already requires linking against iOS 13 and will require linking against Catalina for compatibility with ARM Macs.

intel chips were significantly faster than PPC chips across the entire Mac line back then. I don’t think that’s the case now.

 

[Mr. Dee]

...and I bet a lot of the effort is going into the 'reimagining' bit - the whole user interface needs to be re-designed to work well on a touch-only device, and although the iPad pro is impressively powerful for a tablet, its specs are quite limited c.f. what you'd expect from an ARM Mac. Photoshop for ARM Mac doesn't need a re-written UI.



Why? x86-on-ARM emulators have existed since the 1980s. Microsoft already has a "modern" x86-32 emulator for ARM as part of its ARM version of Windows. The only issues are legal ones which, unlike the laws of physics and mathematics, can go away if you throw money and lawyers at them. In any case, its only ever been a stop-gap, and the performance won't be special. However, 15 years on from the last switch, the software world has moved on and more applications should be in the ideal "tick 'ARM' and re-compile" class than ever before.



Do you mean the messy end of the PPC era - which was caused by Apple being totally dependent on Motorola and IBM producing the new processors it needed - like a mobile G5 for the PowerBook? Because the #1 point in Apple switching to ARM would be to lose their dependence on Intel, who are now causing them similar problems (not just Intel's current supply and die-shrink problems, but also their regular delays in releasing the particular power/cores/iGPU combo that Apple need).

There seems to be a bit of revisionist history going around suggesting that Apple switched to Intel to get Windows compatibility. They switched because development of G5 had dried up, whereas Intel had just dumped the whole Pentium-4 space heater dead end and started making decent processors (the Core series). It was hackers (in the good sense) who first showed how the x86 Macs could run Windows - the first x86 Macs didn't even include the EFI BIOS emulator module needed to run Windows, which the hackers had to find and install. Bootcamp and Parallels followed later.



Only if (a) Microsoft/Apple make ARM Windows available for Mac and (b) your applications work with the x86-32 emulator in ARM Windows.



By charging more. Remember, that the Xeon processors in the Mac Pro run from $1200 to $7500 "recommended customer price".

You may have missed the recent announcements of 64- and 80- core ARM chips from multiple sources. Not saying that those are drop-in options for the Mac Pro as they're designed for server workloads (although even the Intel Mac Pro depends on mooooar corrres!!! for its performance), but they show that you don't have to be Intel to develop high-performance, custom ARM chips.

Still, yeah, the Mac Pro is going to be the biggest challenge.



They need developers to start porting their programs, and an iPad Pro running MacOS might not quite cut it.



(Assuming by "platform" you mean "hardware platform" rather than "Operating system")

Linux, as with all Unix-like OSs, has always been focussed on source-code compatibility rather than binary compatibility, and the majority of the big open-source projects are already up and running on ARM Linux. Heck, I was using Unix on ARM (RiscIX) back in the early 90s - it took me an afternoon to get the then-standard HTTP server up and running, and that was due to a minor difference in Unix dialects rather than the CPU.

MS's current preferred development tools - whatever they're calling .net these days - compile to bytecode which runs in a virtual machine (Common Language Runtime). Of course, Windows has a "legacy" software problem beyond the dreams of Mac users - the 32 bit version still runs Windows 95 binaries.

Apple have spent the last several years persuading developers (via App Store rules) to use standard frameworks like Metal, Accelerate, Core-whatever etc. rather than use hardware-dependent code. Any new-ish Mac software written to Apple guidelines is likely to re-compile for ARM with little if any changes. The last big change - the move to 64-bit (which can affect data types and structures in source code and is a potentially bigger deal than switching CPU) - will have mopped up a lot of potential problems with ARM64.

Then you've got the huge increase in applications developed using web technology - HTML5/Javascript - which are genuinely truly platform independent (its not just websites/online apps - MS Visual Studio Code is mostly Javascript running on a bundled version of the Chromium browser).



What people just don't seem to get is that the vast majority of modern software is written in high-level-language, and only uses hardware-specific code where absolutely unavoidable . Modern operating systems have built-in hardware abstraction frameworks (e.g. Metal, Accelerate in Mac OS) designed to avoid that need. Even drivers can be mostly written in high-level language (as is most of the OS itself).

Supporting multiple operating systems is a major pain because it usually means a completely re-written UI and different frameworks (e.g. Metal vs. DirectX). Supporting the same/similar operating system on multiple CPU architectures is a breeze by comparison.

Once you've fixed any issues that stop your MacOS x86 application running on MacOS ARM there will usually be no need to maintain separate sets of code for x86 and ARM - you'll just build it as a universal binary (it might even be possible to use bytecode, in which case the App Store builds CPU-specific binaries). It won't be zero work - you'll need to do some testing (oh, wait, what am I saying? Its 2020 and everything is beta) on both platforms - but its nothing compared to supporting multiple OSs - even MacOS and iPadOS.

Yes, there will be exceptions - a small number of special cases where you have to use CPU specific code (maybe some game engines are still written in lovingly hand-coded assembler?) but far fewer than there were at the time of 68k-PPC or PPC-Intel - the last being a switch from big- to little-endian which can also affect high-level code). ARM is 64 bit, little endian (well, technically bi-endian) just like Intel. It will be using the same compiler front-end so there shouldn't be any C/Swift dialect quirks or different data sizes. Nothing like this is ever trivial but there's no reason for it to be much worse than the usual annual OS release or the 64 bit switch.

My point is, Photoshop for iPad starts the hard work of porting it to A-Series. It’s better to start it now with the iPad than wait at the last minute when Apple comes out with the A-Series Mac in 2021. Also, keep in mind, the code base itself for Photoshop has been through multiple transitions and its takes years to target a new CPU architecture. The first version of Photoshop that became optimized for Cocoa wasn’t until about 2012 with CS6. Thats 8 years after the Intel transition and 6 years after the first Intel version, CS3. So, this is a long journey and it likely won’t be complete even when macOS moves to A-Series, its just that Adobe won’t be caught off guard this time. Then again, I ra Photoshop CS2 on my Hackintosh for years with minimal impact on performance. Rosetta was magic.

 

[God of Biscuits]

ARM on Macs...

99% of all researchers and scientists: Bye Apple....

you have no basis for that.
[automerge]1584027254[/automerge]

If this happen, it's gonna run iPadOS. An iPad with a fixed keyboard. The world isn't ready for an ARM notebook.
And I bet it's gonna be a fiasco

This makes no sense.
[automerge]1584027295[/automerge]

When Adobe apps aren't even optimized for the current hardware, I'm not hopeful.
The numbers of installed ARM devices will be so small that it won't be a high priority (despite what any Adobe exec trotted out at a keynote announcement).
Compare that to the millions of installed Windows user base.

‘it’s about platform, not processor.

 

[jerryk]

Who’d they hire from Intel?

A number of my friends and neighbors from processor divisions (cpu and networking processors) have gone over in the last few years. Intel is not considered one of the hot places to work in the Valley.

 

[theluggage]

Switching to RISC processors solely, imo, would be horrible for higher-end complex tasks that we use these machines for

I don't know why people think this is a thing. RISC vs CISC is a 1990s debate that is almost irrelevant with modern CPU designs. Spoiler: RISC won, even modern x86 is a RISC-like core fed by an x86 instruction translator. Higher-end performance is heavily dependent on multiple cores, special-purpose accelerators, GPUs and reducing power consumptions (even if you don't care about the penguins, heat dissipation is a major issue). Dumping the x86 translator hardware leaves more room and power for extra cores and accelerator gizmos.

Meanwhile, the vast majority of "complex" software is written in CPU-independent high-level language and uses OS abstraction layers to drive the gizmos. Only a small minority of developers need to know what CPU they are developing for.

 

[jerryk]

I don't know why people think this is a thing. RISC vs CISC is a 1990s debate that is almost irrelevant with modern CPU designs. Spoiler: RISC won, even modern x86 is a RISC-like core fed by an x86 instruction translator. Higher-end performance is heavily dependent on multiple cores, special-purpose accelerators, GPUs and reducing power consumptions (even if you don't care about the penguins, heat dissipation is a major issue). Dumping the x86 translator hardware leaves more room and power for extra cores and accelerator gizmos.

Meanwhile, the vast majority of "complex" software is written in CPU-independent high-level language and uses OS abstraction layers to drive the gizmos. Only a small minority of developers need to know what CPU they are developing for.

Yep. I remember people making all sort of arguments that RISC would never work except in certain situations.

And today, how many developers consider things like instruction or registers sizes. Unless you are really close to the metal, you deal with this function or that function in a higher level language. And the interpreter or compiler handles many of the details. The best thing you can do is don't write extraneous code. Because the fastest instruction is the one that is never existed.

 

[Mattsasa]

So ARM based MacBook/MacBook Air launching at end of this year/Early 2021? Then redesigned MacBook Pro with ARM in the middle of 2021?

But whatever the first arm notebook is, the one launching towards the end of this year. When will it be announced? This fall? or still possible at WWDC? (or just announcing the arm MacOS in general, without product specifics). (Assuming WWDC is still happening)

 

[theluggage]

The first version of Photoshop that became optimized for Cocoa wasn’t until about 2012 with CS6. Thats 8 years after the Intel transition and 6 years after the first Intel version, CS3.

Optimising for cocoa has nothing to do with changing CPU and everything to do with changing operating system - it was effectively the last stage of porting from MacOS Classic to MacOS X (which was a totally different OS and a far, far bigger upheaval than any CPU switch). The pre-cocoa look came from applications using the "carbon" framework which was intended to help developers port from Classic to OS X without having to go back to the drawing board for their UI.

My point was not that the iOS developments won't be helpful in making CS for MacOS/ARM - in fact, if they're replacing CPU-specific code with iOS/MacOS frameworks like Metal and Accelerate then it is potentially good news for MacOS/Intel - but that the iOS bit is potentially just as hard, if not harder, than the ARM bit.

You'd have to ask an Adobe developer who knows the codebase whether it would be easier to start with the MacOS code or the iPad code in order to make full CS for MacOS/ARM (in fact - even 'the code' is probably a gross simplification there).
[automerge]1584029740[/automerge]

But whatever the first arm notebook is, the one launching towards the end of this year. When will it be announced? This fall? or still possible at WWDC?

I think you're expecting too much detail from something that is still a rumour.

If you want to speculate, look at the history of the PPC-to-Intel switch - it was announced at WWDC 2005 alongside a developers-only machine that was basically the first Hackintosh, with the first consumer Intel Macs launched in January 2006 and the last transition - the Intel Mac Pro - arriving ahead of schedule in August 2006.

I'd say that an ARM transition would need to be a bit more gradual - its less urgent and there isn't going to be such a significant step-up in raw power to offset any use of emulation during the transition.

 

[DonutHands]

Just my uneducated guess.
Low end/cheap laptop.
Targeted specifically for education/students.
Can only run apps designed specifically for ARM or through Catalyst.

It would serve as a purpose built test bed for evaluating bringing ARM based desktops to the general public.

 

[jdiamond]

Guys, it's all about LIVE software development projects vs DEAD ones. The current transition to x86-64 Catalina means I will lose 95% of my software, because it was compiled for 32-bit x86 (even though it's pretty new) and is no longer in development. For companies still updating their software, getting Catalina compatible versions is trivial. The same is true for ARM - just check the box and compile. (This is why a lot of people think ditching 32-bit binaries was a way to wean people off x86 in general, not just off of 32-bit x86.) You'll lose all the software not currently being updated (although you certainly CAN have an emulator - people have already written some), but you'll have little trouble adapting new software. Remember that when Apple transitioned from PowerPC, they told everyone to stop using direct assembly instructions, and instead use SIMD intrinsics, so that gave them a lot of headroom to transition high speed kernels. And of course, Windows is available on ARM.

For me, the biggest issue is compatibility with Linux boxes at work. And yet - it's highly possible they'll return to fat binaries as they did during the POWERPC transition, meaning you'll actually still be able to run the new executables on x86 as well as ARM! If in addition, you can emulate the old x86 software on new ARM machines with OK speed, I don't see much issue.

I know this is all about compatibility with the iOS hardware line, but I wish they'd instead moved to RISC-V. Contrary to popular belief, the modern arm ISA is nightmarish. Their ISA manual is now over 7,000 pages long, and decoding some of the constant bitfields is so complex it can only really be done using reference software.

UPDATE: I've been going through all the software critical to my workflow. And it looks like by the time I can actually be productive on a Catalina machine, I'll have switched to almost 100% actively developed software. Which means switching to ARM will be far easier for me than switching to Catalina. And you KNOW they could provide an emulator for Catalina that ran 32-bit x86 apps if they didn't want us all to stop using older software.

 

[Mago]

first ARM-powered MacBook model will most-likely be either 12" or 13" (the latter assuming the 14" Intel-powered MacBook Pro is launched) and will likely be called MacBook or perhaps even "iBook".

I still not buy the rumour, first instance how carefully Kuo and Bloomberg avoid to name an specific platform (it could be ARM or Zen) but now stealthy Kuo introduce the term "custom CPU" indeed based in a current CPU, it's more like AMD language than ARM language.

I believe ARM could stand with regular PC workload but at low level, if you need code to run faster or in more complex applications you'll still need x86-64, the server industry compares x86-64 with ARM only disabling avx extensions as no GCC compiler support it neither arm has implement an equivalent yet, but most Server workload do not use avx at all, so for database, content and related applications avx is nothing to care about, but when you do transcoding, complex math, and ai is when avx and other x86 exclusive stuff (for now) bring an solid edge to the x86-64 architecture.

I still believe this rumors about Apple PC CPU actually are about a AMD Zen based licensed custom CPU, or a bifurcation in the macOS line with an ARM specific macOS and an x86 specific macOS with limited low level compatibility and likely requiring specific new builds of catalyst-only apps for those iBooks, but who needs an iBook stealing sales to the iPad pro (selling as hit cakes)? Has nonsense.

BTW ARM Macs means to break with PC applications, window and Linux virtualization (beyond bootcamp), so an software developer targeting Linux windows as derivative market beyond Mac, will have no choice than to have ab2nd machine or ditch develop under macOS.

The most logical scenario to ditch intel is to license AMD Zen 2 or Zen 3 and manufacture or customize (Apple may buy chiplets and integrate around it's own CPU hub) it requires no or trivial changes to macOS, do not break x86-64 compatibility and bring both Zen hype and Apple pride into the product line, PC buyer do not perceived ARM as q powerful platform (and this is right) selling them ARM as alternative won't be that easy.
[automerge]1584029986[/automerge]

, getting Catalina compatible versions is trivial. The same is true for ARM - just check the box and compile

Pretty naive.

 

[gsurf123]

Bloomberg never names anyone as a source. Their business model is based around unnamed sources, which I interpret as shading characters giving advice or just plain made up.

 

[Roscorito]

I had a feeling that uninspired 16 inch ‘redesign’ was a stopgap filler. Guessing those five registered but unreleased MacBook models last summer were the ARM designs but with butterfly keyboards and they decided to pull them late stage to remodel for scissor switches. So, a 12 inch ARM MacBook by the end of the year, ARM MacBook Pros later next year and I guess desktops must be much harder to track along the supply chains, probably because of the much lower volumes.

 

[CWallace]

I believe ARM could stand with regular PC workload but at low level, if you need code to run faster or in more complex applications you'll still need x86-64...

That is the case today and probably for years to come, but ARM is not a static platform in terms of hardware development.

Apple needs a beachhead to both emulate x64-86 and to get developers to start porting their existing x86-64 code to native ARM. The current Y-series CPUs in the MacBook Air are relatively low-performance so an A13X can quite possibly execute x86-64 code faster in emulation than the Amber Lake-Y series can natively (just as the Intel Core CPUs could run PowerPC code in emulation faster than the lower-end G5s could natively).

 

[movielad]

"Own" Custom Processor it's an broad expression, I Will laugh a lot when all these fanboy blogger read what Apple developed was just a AMD Zen based processor.

Bring me a single Kuo quote where's explicitly names ARM

That's actually a very good point. The Xbox and PS4 consoles have "custom" CPUs from AMD - the report also didn't say that it was an Apple-designed custom CPU. ARM is never specifically mentioned from what I can see - but then again, trying to find the original press release is tricky.
[automerge]1584031356[/automerge]

Windows runs just fine on ARM. The CPU changeover shouldn't be an issue.

Well, this is very encouraging:

Arm-based Surface devices FAQ - Surface

Explore how Arm-based Surface devices offer top performance, efficiency, and app compatibility for corporate environments.

docs.microsoft.com

It's going to need substantial support from the Windows community if Windows for ARM is going to be any kind of success. And I don't think we'll see that for a considerable amount of time.

 

[Wags]

Did Apple learn from the PowerPC fiasco? We need x86 compatibility with the 97% of the world, and that means Intel chips inside Macs! Otherwise, it is a deal breaker and switch to Windows. A shame for all.

Apple is ’all in‘ with iOS and ARM. Seems like Apple would get rid of Mac OS if think they could.