I don't follow the line "it moved from the classic OS 9 to Mac OS X and now macOS".
I thought both Mac OS X and macOS were Berkeley Unix-based. Unless macOS is the 64-bit version of Mac OS X.
macOS is just a renaming of Mac OS X to follow the pattern of iOS, watchOS, tvOS, and now iPadOS. Really all of those are OS X-based OSes. While "we" were already calling it iOS Apple was still trying to figure out how to market it. First as simply a ridiculously sized and complex "firmware" and then as "OS X iPhone" in contrast to "OS X Mac" as evidenced by banners at one WWDC.
I don't follow the line "it moved from the classic OS 9 to Mac OS X and now macOS".
I thought both Mac OS X and macOS were Berkeley Unix-based. Unless macOS is the 64-bit version of Mac OS X.
macOS is just a renaming of Mac OS X to follow the pattern of iOS, watchOS, tvOS, and now iPadOS. Really all of those are OS X-based OSes. While "we" were already calling it iOS Apple was still trying to figure out how to market it. First as simply a ridiculously sized and complex "firmware" and the even as "OS X iPhone" in contrast to "OS X Mac" as evidenced by banners at one WWDC.
Thanks for the clarity. The article gave me the impression of a big upheaval similar to OS 9 transitioning to Mac OS X, but I didn't remember a similar upheaval, if any, going to macOS. APFS? Metal/Metal2? 64-bit only? That's all I could come up with.
I'd still say they are going to be moving to custom-designed AMD chipsets instead. Probably based around the Zen 2 architecture. It'll retain x86 compatibility and provide better performance for the power. The move to an all ARM platform seems a little too early. Yes, they could if they wanted to, but I still think there needs to be considerable work done before Windows on ARM becomes a proper, mass-embraced thing.
Apple makes macOS. Microsoft makes Windows.
Well DUH.
The point is that Macs are in a position to run both operating systems. Virtually or via natively. As a systems administrator who works for a system integrator (and before that, a VFX software firm), I work across multiple operating systems and the Mac is the only device that allows me to consolidate both OSes within the same hardware. Shift to ARM, that goes away.
I'd still say they are going to be moving to custom-designed AMD chipsets instead. Probably based around the Zen 2 architecture. It'll retain x86 compatibility and provide better performance for the power. The move to an all ARM platform seems a little too early. Yes, they could if they wanted to, but I still think there needs to be considerable work done before Windows on ARM becomes a proper, mass-embraced thing.
A Mac running ARM Windows makes no sense (I think we agree on that). I don’t think Apple will go AMD besides using their discrete graphics ...until they develop their own. I remember reading Intel gives Apple amazing prices for their chips. It’s possible AMD could match it, but Intel and Apple collaborate elsewhere. Eventually Apple will do everything in-house, but until then switching to AMD seems like a needless complication.
Oh goodness - certainly not at the moment. Microsoft was certainly brave to release the Surface Pro X, but realistically it's not much use to most people given how little support there is for ARM-based Windows applications at the moment. That may grow, but I don't see it happening for a very long while - if that. Apple does already have its own discrete graphics based off of the PowerVR graphics found in iPhones and iPad Pro. But whether that's going to be good enough for the Mac and will continue to use AMD for that, I don't know.
It's all rumours and guesses at this stage. If they go ARM on the Mac, I'd expect to see a development kit rolled out a good 6-12 months before any consumer kit is released. And I'd hope that Apple will continue to support Intel Macs for another 4-5 years after the last Intel hardware is released to ensure plenty of time for people to take advantage of hardware they've just purchased.
If I were Apple, I would make a x86 instructions compatible processor with ARM core. Modern Intel processors used the same technique with RISC-like core and x86 microcode. This way, no transition issues, if not 100% compatible with existing software.
This is very unlikely because of licensing issues. It is probably impossible for Apple to get a x86 license.
The alternative is running a version of the x86 application under either emulation or translation to ARM. Both are likely to be used; first you start an application by emulation x86 opcodes and after a short amount of time for statistical analysis at runtime, you translate the x86 instructions to ARM instructions. The instructions translated usually are localized in what is known as “hot-spots”. This makes the relatively time consuming operation of translation shorter since you are only translating short snippets of binary code that run frequently.
This has been done before with the Intel transition. The Rosetta emulator for going from PowerPC to Intel x86 was quite effective. The problem with the ARM transition is that the ARM CPU isn’t likely to be as much faster from the Intel CPU as was the Intel CPU from the PowerPC CPU. So any slowdowns will seem like very poor performance.
But unlike with the Intel transition, Apple has a lot more control with their own ARM CPU designs. One solution is to add a few instructions to the ARM CPU to aid in the emulation/translation from the Intel instruction set. Apple has complete discretion to add anything they want to their A series processors. They may be able to do statistical analysis on a wide variety of Intel binaries and find where any slowdowns because of CPU architecture differences occur. These instructions don’t have to resemble their x86 counterparts because they would only run under emulation or translation thus avoiding any copyright or patent problems from Intel or AMD.
Will Apple deem this work to worthwhile? I have no idea, but these ideas aren’t new or radical. They’ve been employed since the 1990’s so Apple is well aware of the possiblities.
Edit: One thing I was going to note is that Apple has added instructions to their A-series CPUs in the past for speeding up an interpreter. This was done for Javascript in, if I remember correctly, the A7 chip. This instruction improved performance of Javascript in Safari by a significant margin.
I has a MacBook Air about 8 years ago and the W key was the hottest key on the keyboard. W was and remains today the main key you have to press to play most video games (as it means move forward). I suspect the Air's Intel CPU was under the W key. I abandoned laptops until this problem is permanently solved, and this ARM move might do the trick.
With the full migration to 64-bit, now is the perfect time for Apple to transition to ARM based Macs. Like previous architecture changes, we all know Apple has been running dual code bases for sometime.
Full migration? A large percentage of the user base has not switched because of the cost and/or complexity of third party software upgrades. My son-in-law manages Macs for five different companies and NONE of them have switched. I haven't switched, not because I'm "cheap", but because I don't want subscription software, so I've been resisting, but eventually I might not have a choice. I've switched from Photoshop to On1, although I prefer many aspects of Photoshop, especially some of the plug-ins. And I really don't want to move to subscription-based Office.
So it's neither a full migration nor, as the article suggests, that it was "easy".
I don't know if there are publicly available stats on how much of the Mac user based has switched, but if they are available, I'd love to know what the share is.
I has a MacBook Air about 8 years ago and the W key was the hottest key on the keyboard. W was and remains today the main key you have to press to play most video games (as it means move forward). I suspect the Air's Intel CPU was under the W key. I abandoned laptops until this problem is permanently solved, and this ARM move might do the trick.
1) That isn't a laptop issue. That's an issue with that specific MBA at most. For all you know the next MBA model moved the CPU location or corrected the heat dissipation issue.
2) You can always get a heatsink to sit atop the key. LOL
Don't conflate iOS and ARM Macintosh. The article does that by implication at least.
There's no additional benefit to iOS developers in ARM coming to the Mac. That's not a bad thing, it just is.
The world is a lot different from 2005, and a different *PLANET* from when the move was made from 68K to PPC. In both those cases, Apple had change management strategies in place, and minimized -- with varying success -- the complexity exposed to developers. Ironically, some developers were angered by that.
The thing about Apple is, if they want it to happen it will happen. They won't focus group it. They won't manage the rate of change over based on customer perceptions. They'll do it according to what's best overall and in the long run. They always favor the strategic. During the Intel changeover, it went so well they just went ahead and pulled the trigger. That wasn't a reaction to customer perceptions, it just WAS.
As it was for intel, all the Frameworks are already being built for ARM..not because most of the frameworks already also exist for iOS, but because Apple's surely been expecting this changeover for a long long time. Almost all functionality exists on all platforms in early identical ways: Metal, the GPU framework, displays everything, accelerates nearly everything, and is everywhere. Image handling, networking, file management, maps, location, webkit, mail, calendars, muslc, books, messages...
So the biggest issues in the past and also the biggest issues now for developers are business-related. Either they don't have the resources or they're no longer around -- or both -- to update their apps. And a BIG BIG part of that is customers. They'll tell you a certain plugin is CRUCIAL to their workflows and then in the same breath tell you they'll never pay a developer for updates. They'll never pay more than 99 cents for an app. That all software should be free. Blah blah blah. People suck when it comes to paying money for software.
THAT'S where a huge part of the pain for developers is.
The migration from PowerPC to Intel involved the whole product range, desktops and laptops, and at the same time. There is no reason to assume that Apple will fragment its Mac product range by introducing an ARM Mac, with apparently no substantial benefit (or profit). - ARM cheaper? - OK, but that's not your business, Apple will write that to its profit row. - But then no one would buy the ARM Mac. - Of course, and this is why Apple won't make one.
We're not talking about Mac software moving to ARM, we're talking about iOS/iPad/iPhone software moving to the Mac/ARM.
I can't say it's going to be a breeze, but reasonably doable with Apple support. The big and little players are already on iOS. Those will now have to drive the software with the touch pad and mouse. With Macs able to use iPads as alternative entry devices and display the flexibility is already here.
So, in addition to the iPadOS, WatchOS, TVOS, Apple would release ArmOS for the new Macs.
You all are talking about a brain transplant. I'm talking about a body transplant.
ARM-based Macs is exactly NOT what you're saying here. it's 100% NOT anything to do with iOS apps moving to the Mac.
It's all about Macs still being Macs. Just as they are today, except with CPUs that run cooler, probably faster and likely with much longer battery life. And will give Apple much more control over what kinds of designs they can do on Mac hardware and when they can release new models.
Again: ARM-based Macs have nothing to do with iOS on Mac hardware.
To be honest, more Mac developers abandoned the platform for iOS than Windows developers after the PPC/x86 switch.
So true. There's some nice, artisan like Mac software, but most of the Mac software landscape is a wasteland because devs were making (and maybe are still making) money hand over fist on iOS.
There is large number of open-source libraries in use, and both closed source and open source applications built on these running on macOS where it is highly unlikely they will ever be ported to ARM. Many of these run on the current macOS by a shoe-string only by feature of running on Intel, as the port is relative untrivial compared to a port to ARM.
You're missing the crucial aspect of Open Source software: the source code is ...open.
The ones that are needed will come along. As needed.
If I were Apple, I would make a x86 instructions compatible processor with ARM core. Modern Intel processors used the same technique with RISC-like core and x86 microcode. This way, no transition issues, if not 100% compatible with existing software.
Apple would be wise to wait for the outcome of Oracle vs Google in SCOTUS. If Oracle wins then Intel will have Apple over a barrel when it comes to licensing the instructions set (AMD will have a say as well)
If Oracle win their your idea will be a non starter (IMHO)
If history is any indicator, Apple lead the way to PowerPC with 3 distinct models, the base model was internally called Galileo, then Copernicus and the high end was named in honor of Carl Sagan, called simply Sagan. I was one of the engineers at Motorola at the time, and we were competing against IBM for the sales of these processors, however we worked together in the design and layout of these chips.
Somehow, Carl Sagan discovered that we were using his name as a Code name, internally only, on the high end PowerPC Mac; and he sued. Steve Jobs promptly had us change the internal code name to BHA (Butt Head Astronomer), again in his honor.
But, these 3 models launched simultaneously, and the writing was on the wall - given the performance of these units, the Motorola 680x0 was on the way out. Most everyone adopted the new PowerPC computers. Also, at that time, Apple opened up their OS and allowed another company to make an Apple clone under the name of Power Computing, which used designs that were ham-strung by Apple, yet they streamlined other areas of the design to make very competitive machines that essentially cannibalized Apple's market share - the cloning agreement was discontinued, an Power Computing failed shortly thereafter.
Aside from the cloning mistake - I think that Apple will likely come out with a few competitive lines of ARM Macs, that will show a superior performance level across a variety of price points, and performance will sell the ARM Macs. It's pretty apparent, Intel cannot match the performance improvements we are witnessing year after year with the ARM processors.
Comments
The point is that Macs are in a position to run both operating systems. Virtually or via natively. As a systems administrator who works for a system integrator (and before that, a VFX software firm), I work across multiple operating systems and the Mac is the only device that allows me to consolidate both OSes within the same hardware. Shift to ARM, that goes away.
It's all rumours and guesses at this stage. If they go ARM on the Mac, I'd expect to see a development kit rolled out a good 6-12 months before any consumer kit is released. And I'd hope that Apple will continue to support Intel Macs for another 4-5 years after the last Intel hardware is released to ensure plenty of time for people to take advantage of hardware they've just purchased.
The alternative is running a version of the x86 application under either emulation or translation to ARM. Both are likely to be used; first you start an application by emulation x86 opcodes and after a short amount of time for statistical analysis at runtime, you translate the x86 instructions to ARM instructions. The instructions translated usually are localized in what is known as “hot-spots”. This makes the relatively time consuming operation of translation shorter since you are only translating short snippets of binary code that run frequently.
This has been done before with the Intel transition. The Rosetta emulator for going from PowerPC to Intel x86 was quite effective. The problem with the ARM transition is that the ARM CPU isn’t likely to be as much faster from the Intel CPU as was the Intel CPU from the PowerPC CPU. So any slowdowns will seem like very poor performance.
But unlike with the Intel transition, Apple has a lot more control with their own ARM CPU designs. One solution is to add a few instructions to the ARM CPU to aid in the emulation/translation from the Intel instruction set. Apple has complete discretion to add anything they want to their A series processors. They may be able to do statistical analysis on a wide variety of Intel binaries and find where any slowdowns because of CPU architecture differences occur. These instructions don’t have to resemble their x86 counterparts because they would only run under emulation or translation thus avoiding any copyright or patent problems from Intel or AMD.
Will Apple deem this work to worthwhile? I have no idea, but these ideas aren’t new or radical. They’ve been employed since the 1990’s so Apple is well aware of the possiblities.
Edit: One thing I was going to note is that Apple has added instructions to their A-series CPUs in the past for speeding up an interpreter. This was done for Javascript in, if I remember correctly, the A7 chip. This instruction improved performance of Javascript in Safari by a significant margin.
So it's neither a full migration nor, as the article suggests, that it was "easy".
I don't know if there are publicly available stats on how much of the Mac user based has switched, but if they are available, I'd love to know what the share is.
2) You can always get a heatsink to sit atop the key. LOL
There's no additional benefit to iOS developers in ARM coming to the Mac. That's not a bad thing, it just is.
The world is a lot different from 2005, and a different *PLANET* from when the move was made from 68K to PPC. In both those cases, Apple had change management strategies in place, and minimized -- with varying success -- the complexity exposed to developers. Ironically, some developers were angered by that.
The thing about Apple is, if they want it to happen it will happen. They won't focus group it. They won't manage the rate of change over based on customer perceptions. They'll do it according to what's best overall and in the long run. They always favor the strategic. During the Intel changeover, it went so well they just went ahead and pulled the trigger. That wasn't a reaction to customer perceptions, it just WAS.
As it was for intel, all the Frameworks are already being built for ARM..not because most of the frameworks already also exist for iOS, but because Apple's surely been expecting this changeover for a long long time. Almost all functionality exists on all platforms in early identical ways: Metal, the GPU framework, displays everything, accelerates nearly everything, and is everywhere. Image handling, networking, file management, maps, location, webkit, mail, calendars, muslc, books, messages...
So the biggest issues in the past and also the biggest issues now for developers are business-related. Either they don't have the resources or they're no longer around -- or both -- to update their apps. And a BIG BIG part of that is customers. They'll tell you a certain plugin is CRUCIAL to their workflows and then in the same breath tell you they'll never pay a developer for updates. They'll never pay more than 99 cents for an app. That all software should be free. Blah blah blah. People suck when it comes to paying money for software.
THAT'S where a huge part of the pain for developers is.
- ARM cheaper?
- OK, but that's not your business, Apple will write that to its profit row.
- But then no one would buy the ARM Mac.
- Of course, and this is why Apple won't make one.
ARM-based Macs is exactly NOT what you're saying here. it's 100% NOT anything to do with iOS apps moving to the Mac.
It's all about Macs still being Macs. Just as they are today, except with CPUs that run cooler, probably faster and likely with much longer battery life. And will give Apple much more control over what kinds of designs they can do on Mac hardware and when they can release new models.
Again: ARM-based Macs have nothing to do with iOS on Mac hardware.
Correct. "macOS", "OS X" and "Mac OS X" are the same product, in reverse chronological/revision order. OS 9 and prior is a different beast entirely.
There are zero rumors or suggestions that this is the avenue that will be taken.
I'm not opposed, but it's unlikely.
You're missing the crucial aspect of Open Source software: the source code is ...open.
The ones that are needed will come along. As needed.
If history is any indicator, Apple lead the way to PowerPC with 3 distinct models, the base model was internally called Galileo, then Copernicus and the high end was named in honor of Carl Sagan, called simply Sagan. I was one of the engineers at Motorola at the time, and we were competing against IBM for the sales of these processors, however we worked together in the design and layout of these chips.
Somehow, Carl Sagan discovered that we were using his name as a Code name, internally only, on the high end PowerPC Mac; and he sued. Steve Jobs promptly had us change the internal code name to BHA (Butt Head Astronomer), again in his honor.
But, these 3 models launched simultaneously, and the writing was on the wall - given the performance of these units, the Motorola 680x0 was on the way out. Most everyone adopted the new PowerPC computers. Also, at that time, Apple opened up their OS and allowed another company to make an Apple clone under the name of Power Computing, which used designs that were ham-strung by Apple, yet they streamlined other areas of the design to make very competitive machines that essentially cannibalized Apple's market share - the cloning agreement was discontinued, an Power Computing failed shortly thereafter.
Aside from the cloning mistake - I think that Apple will likely come out with a few competitive lines of ARM Macs, that will show a superior performance level across a variety of price points, and performance will sell the ARM Macs. It's pretty apparent, Intel cannot match the performance improvements we are witnessing year after year with the ARM processors.