Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Kuo said Apple plans to launch MacBook models with its own custom processors in the fourth quarter of 2020 or the first quarter of 2021
"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
 
  • Like
Reactions: movielad
I think you have to assume this actually means an ARM 12" Macbook might launch, but there will be a Macbook Air/Pro redesign next year. Because there is zero chance they will introduce an ARM Macbook on the old chassis - that would be stupid, the thermal profile of an ARM Mac would be totally different. The way you'd design cooling for such a machine wouldn't have anything in common with the current Macbook line.

Not that I think launching an ARM based Mac is anything but insanity at this point. Emulation of x86 will break a lot of things, and the Mac software ecosystem has already taken a huge beating from the loss of 32 bit code this year. Developers will flee the platform en masse.
 
Switching to ARM would most certainly be completely incompatible. Unless they manage to pull off another feat like Rosetta (which would likely be MUCH harder in this case), it seems extremely unlikely that they would switch to ARM and break compatibility with all apps considering that they have yet to warn developers.

Microsoft have an x86 emulation layer in Windows on ARM, but not x86-64 I understand.

To be honest if apple switched to arm i see them refreshing the whole line at once. If you do what microsoft keeps doing and give an intel/amd alternative then devs are not really going to bother to port their stuff over to the arm version.

Apple doing the switch all at once on a majority of products with conformation that all products are switching to arm would give devs no choice but to make their stuff compatible

Yeah, I think they'd probably do it all in one go. I think if they did the low power options but not the pros it would seriously hurt the ARM chips image which could have long term consequences. Possibly they'll continue also offering x86-64 in the Mac Pro though (perhaps offering AMD as well as/instead of Intel), it being modular and all.
 
  • Like
Reactions: HowardEv
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.

It's possible to have the CPU directly emulate x86. Russian CPU Elbrus has the capability. Though the performance hit for the ARM CPU might be significant.
 
Apple ARM CPU keep improving every year. And in 3 years it will be quite a big change. Knowing that, Apple's apparent care for the environment, and engineering know-how, I would like to see if some sort of upgrade can be done without replacing the whole computer. Maybe a mother board change only, even better a CPU swap out, if it needs a more powerful fan - swap it out, etc. Ain't gonna happen, forget it.

Opening the Mac, removing the old mainboard and replacing it with another mainboard is already more expensive than just giving you a new Mac even if the new mainboard wouldn't cost anything.
 
How about neither? I'd expect the first MacBooks with custom ARM processors to be just that: MacBooks. Not MacBook Pro and not MacBook Air, just MacBook. 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). ARM on Mac will have to prove itself before it replaces Intel in the Pro or Air.
I’d argue that my 2017 MacBook is “fast enough“ but don’t dispute it was expensive.

if Apple can provide an ARM equivalent that will run MacOS apps but be a bit cheaper yet still have long (longer?) battery life it should have a good niche to fill.

But...it then also essentially admits that the iPad is not a true MacBook replacement.
 
About time for Apple to cut their dependence on Intel for processors. Apple has hired people from Intel and other processor companies in recent years. This gives Apple the intellectual capital, to pair with its monetary capital, to make an Apple processor powered laptop a reality.
 
About time for Apple to cut their dependence on Intel for processors. Apple has hired people from Intel and other processor companies in recent years. This gives Apple the intellectual capital, to pair with its monetary capital, to make an Apple processor powered laptop a reality.
Who’d they hire from Intel?
 
Looking forward to seeing what Apple can do, particularly in the low power/ fanless computing space which has been all but abandoned by Intel and which AMD don't seem interested in... A properly fanless slim MacBook Air with great battery life and the new magic keyboard would be a fantastic machine for a lot of light computing workloads (and all the more if it goes 14" or if there's a 15" option added!).
 
There’s just no way. With PPC to Intel, there was Rosetta which kept compatibility for PPC on all Intel Macs from 10.4.4 (first Intel version) all the way until 10.7. Then, the 64-bit transition was a loooong time in the making but they first warned developers in December 2017 by requiring 64-bit in the Mac App Store, and external apps were still supported with a warning until 10.15 (released October 2019).

Switching to ARM would most certainly be completely incompatible. Unless they manage to pull off another feat like Rosetta (which would likely be MUCH harder in this case), it seems extremely unlikely that they would switch to ARM and break compatibility with all apps considering that they have yet to warn developers.

I think there’s a good chance, actually more likely than not that they will eventually switch to ARM for many reasons (efficiency, unified architecture across all Apple products, etc.) and some non-Apple portable PCs already use ARM. However I think that’s a long ways away, unless they run iPadOS. macOS isn’t ready for ARM.

Yeah - So are you a developer? A software or hardware engineer?
I’m sure the professional engineers who work on this exact problem every day have not thought about any of this.
 
As others have noted, this 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".

Developers are going to need ARM-powered Macs to develop and test their code on so it makes sense for Apple to release such a machine, just as they did with the Intel-powered "Dev Macs" during the PPC to Intel release. This will also allow consumers whose computing needs align with such a portable Mac to use one and that will give Apple real-world feedback to iterate future versions of both that product and more powerful models designed to take on the role of the other Mac portables and desktops when the OS, software base and hardware is ready to do do at some future date.
 
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 :D
Yes your right - that is why this is at least 2 years away from happening. Assuming of course this random rumor on the internet is accurate to begin with.
 
  • Disagree
Reactions: mazz0
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 :D

LOL somebody gotta keep the Apple Death Knell tradition going.

I always like seeing what Apple does when it hits that "... and now for something completely different..." key in its piano factory, no matter what the focus of the change.

Evolve or die is no joke, and Apple gets that, including the part about how some explorations end up in a cul de sac once in awhile but that doesn't mean evolution stops to hold a funeral.

The great thing about a company that takes risks is that statistically speaking the chances of survival are far better than when a company holes up behind a display case of awards for best thing invented back in the good ol' days....
 
  • Like
Reactions: eulslix
Sure, it does not have feature parity and Adobe admits that. But, its the same code base and Adobe is adding features over time that either matches or reimagines it for the iPad.

...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.

Unless they manage to pull off another feat like Rosetta (which would likely be MUCH harder in this case)

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.

Did Apple learn from the PowerPC fiasco?

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.

My biggest concern is, will those new Macs be able to run old Windows applications?

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

I am curious to see how Apple will manage to design a CPU for Mac Pro that has tons of CPU options and limited sale.

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.

I find it odd that Apple would release an ARM based Mac with the "old" design and then refresh the lineup after 6 months.

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

I actually think Apple, MS and the Linux community should work towards platform independent code.

(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).

Apart from the BIG software companies, small and medium developers can't afford to write software for Windows and Linux and Intel MacOS and now ARM MacOS

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.
 
Now I just need to survive Human Malware and things could get exciting again for Apple!
[automerge]1584023583[/automerge]
...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.
Everyone READ ALL of this reply post. He speaks TRUTH.
 
  • Like
Reactions: orthorim
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.