Why Apple is right to dump Intel for ARM in some MacBooks

MacBook Pro
MacBook Pro (Image credit: Windows Central)

Apple is reportedly going to start using its own ARM processors in some of its laptops starting next year, according to a recent report in Bloomberg. The news of a switch goes back to 2018, and is therefore not surprising. Still, it appears that Apple is getting closer to making the change a reality.

Microsoft has been using ARM for many years now, going back to the failed 2011 Windows RT attempt. Microsoft has since righted many of the wrongs with Windows 10, which does not have nearly as many limitations as Windows RT. New releases of the Samsung Galaxy Book S and Surface Pro X have created always-connected thin clients that cannot be matched by Intel or AMD, filling a niche, but significant market.

With Apple getting into the mix, though, it is both good and bad for Microsoft. Apple's 8-core A12 Bionic Chip series brings some serious performance that outmatches even the Surface Pro X's Qualcomm-based Microsoft SQ1 chip by a margin. There's little doubt that Apple has an advantage when it comes to iPadOS and its own hardware contrasted to Microsoft.

And therein lies the rub. Apple is likely to see greater earlier success than Microsoft if it sticks to putting ARM into something like the entry-level MacBook Air. That laptop is easy to optimize for as it currently features a dual-core Intel chip (Core i3-1000NG4). Tossing the Snapdragon 8cx into a MacBook Air could nearly match that performance even in x86-32-bit emulation.

Samsung Galaxy Book S Review

Source: Daniel Rubino/Windows Central (Image credit: Source: Daniel Rubino/Windows Central)

Apple still has a lot of work cut out for it. The same app compatibility problems and platform limitations are likely with macOS. Popular apps from companies like Adobe are likely to be in "development hell" before they are successfully ported. Mac users are already contending with the end of 32-bit app support with Catalina, making this a potential double whammy of app incompatibility for users.

But Apple does have arguably better developer relations compared to Microsoft, making any such transition possibly less painful. When Apple cracks a whip, its dev audience listens. Moreover, Apple is expected to bring over its iPadOS apps to macOS, filling any app gaps.

When Apple cracks a whip, its dev audience listens.

Apple's real threat though, is its in-house ARM development. It is incredible how, in just a few years, the company has created such powerful chips. This "leak" about switching to ARM came right before Intel's quarterly earnings on the same day. If Apple is getting ready to dump Intel for some of its product lines, then this news is timed to throw shade on Intel in a very public way.

The good news, if any, is this news puts more focus on general ARM development. With new companies getting on board, it gives ARM – even under Qualcomm – much greater reach and mindshare. Microsoft already had done a lot of work on ARM, and by the time 2021 rolls around, the rumored Win32-64bit support could be here.

With Apple finally making an ARM-based laptop, it could actually drive demand for something similar in the PC space. Luckily, Microsoft and its partners are already there, meaning there would be less catching up.

Qualcomm is on its third-generation of Windows-only processors in just over two years. Who knows what it has lined up for 2021, but it should be a substantial evolution over the current Snapdragon 8cx.

Even Intel is finally reacting to threats from ARM on multiple fronts. Its next-gen Tremont microarchitecture with Lakefield should bring most of the benefits of ARM to Windows with fewer drawbacks.

Microsoft, of course, is leading the way for ARM in laptops. But Apple is likely to swoop in and garner all the credit in 2021. Nothing is new there, but it does bode well for this idea that the future of mobile computing is diverging towards two major categories: thin clients with 4G and 5G, and beefier laptops with powerful discrete processing. How it plays out will likely be no different than today: Apple wins in the consumer market, while Microsoft dominates work and productivity.

Daniel Rubino

Daniel Rubino is the Editor-in-chief of Windows Central, head reviewer, podcast co-host, and analyst. He has been covering Microsoft since 2007 when this site was called WMExperts (and later Windows Phone Central). His interests include Windows, laptops, next-gen computing, and for some reason, watches. Before all this tech stuff, he worked on a Ph.D. in linguistics, watched people sleep (for medical purposes!), and ran the projectors at movie theaters because it was fun.

  • Great article! My company www.propresenter.com has tens of thousands of windows and Mac users. I just talked with our dev team today and they absolutely are cool with redistributing our app for arm.... but not until Apple has their arm for desktop platform out. I totally would LOVE to just be able to use a Surface Pro X for everything, but until the company I work for has our apps on it I certainly can’t move to it.
  • Interesting feedback. Makes sense. With Apple getting in on it suddenly ARM development makes more sense for everyone.
  • One question I have Dan, how exactly is Apple going to solve the MacOS emulation problem? Mature desktop apps (aka real programs) that have been developed for Mac over the years won't simply just like install on the ARM chip. How will they solve this? MS has really struggled with Windows 10 on ARM, still working on getting the emulation of x64 working fine. I'm pretty sure this cannot be a walk in the park for Apple. Even if the underlying ARM chip is good, and even if they have these fantastic developer relations, it's not easy to ask a company (that's if they are still around) to just magically recompile decades old code for the new platform. There's a reason MS always tries to implement emulation where possible..
  • It's all a bit vague right now with "Apple is exploring tools that will ensure apps developed for older Intel-based Macs still work on the new machines. The company also has technology called Catalyst that lets software developers build an iPad app and run it on Mac computers." It's not dissimilar form what Microsoft has to contend with.
  • Time to test the deeper coding chops of Apple's OS teams. I'm curious to see if they can really pull off MacOS emulation as good (or better) than Microsoft has done with Windows 10 on ARM and x86. I think this, more than the raw capability of the ARM chips is the real decisive factor. Yes Apple has a lead in Mobile, but I don't know if that extends to desktop, to the point that developers are willing to go all out and rewrite/recompile their legacy apps for MacOS on ARM. Interesting times ahead for sure!
  • I don't think MacOS will be emulated. That's not very Apple like.
  • @kojackjku Their fans will lap it up too.
  • Part of that is true, after all, Apple did just dump 32-bit apps in Catalina. So that's already getting rid of any older, legacy apps (or games).
  • Apple does not need to worry about legacy crap. They don't have customers who rely on 30 year old business software, which is common in Windows. Everyone just moves on when they are ready. Not to mention that Apple has done emulation already, having changed the CPUs in Macs twice. There were people who claimed in 2005 that emulating IBM Power PC code on Intel CPUs was "notoriously difficult", but Apple did it. I suspect the Arm laptops will be "ultra book" type machines. Intel laptops are not going away, so the Arm Macs will be lighter, no fans, great battery life, etc. If you need to run Final Cut Pro, then get an Intel Mac. Only Windows users insist that ANY hardware running anything called "Windows" MUST be able to run all Windows software. They want a Windows Phone that they can put into a dock and run Photoshop. They want a Windows tablet that can compile VS code. Anything less is just a "toy". Because you MUST be "productive" on Windows. You can't just use it for fun or entertainment. Which is silly, and is but one (of many) reasons that phones failed, that Windows tablets don't sell that well, and Windows on ARM has gone nowhere thus far. Hopefully, Windows 10X can change that. But MS needs to not call it Windows 10X. People will - again - expect it to run ALL Windows software. It desperately needs a new name.
  • "And why shouldn’t we want that."
    Because things like Win32 apps are not optimized for ultra-mobile usage, nor touchscreens, or a stylus/inking. Toss in security risks and outdated UI elements, it's not great on anything < 10-inches.
  • "Only Windows users insist that ANY hardware running anything called "Windows" MUST be able to run all Windows software. They want a Windows Phone that they can put into a dock and run Photoshop. They want a Windows tablet that can compile VS code. Anything less is just a "toy". Because you MUST be "productive" on Windows. You can't just use it for fun or entertainment."
    lol this is totally accurate. I wish it weren't, but here we are.
  • > Windows devices are supported much longer than macOS computers. Those of us who actually ran Windows on DEC Alpha, MIPS, RT-6000 and, more recently, Surface RT or, say, Lumia 650 would *really* like to believe you...
  • deleted because I misread a reply.
  • It’s not hard to redistribute for arm, just like when Apple switched from PowerPC to Intel, it was a matter of making some adjustments to the software’s cpu usage but in general companies really shouldn’t have a problem actually switching their software over. I think the reason companies won’t right now is simply because there is no popular arm platform. Like Dan hinted at, if Apple does arm, it will help windows on arm as well. There’s just no reason for many desktop app companies to build out or redistribute their apps for a new platform that doesn’t have their users on it.
  • The difference is that Apple has a ton of years working with ARM for iOS/iPadOS. A lot of these apps already run on ARM. They just need to polish them more for a Mac
  • There is an important reason Mac is easier to switch to ARM than Windows. Apple users have accepted shorter backward compatibility, newer versions of MacOS not supporting older hardware and especially apps that are getting updated not supporting older versions of the OS, or the other way around, apps that aren't being actively developed anymore not expected to run on new versions of the OS. This means the expectations are very different.
    Honestly, modern code for Win32 can easily be cross-compiled to x86, x64 and ARM, most of my x86 code basically recompiled to x64 and now to ARM without any code change except some legacy data types (mostly DWORD that were designed to hold pointers changed to DWORD_PTR when moving old x86-only code to 64-bit). Providing native ARM builds shouldn't be an issue for Windows developers, the problem really is interest from companies, as an extra build is seen as unnecessary because of the number of ARM-based Windows devices, and, more problematic, users expectations of backward compatibility with software that is out of support since years. Just remember the issue with 64-bit editions of Windows dropping support for 16-bit applications.
  • I'm more of a hardware designer, so I've been curious about ARM builds in general. Is it simply a matter of clicking a button to publish an ARM build? If it's that simple, I find it hard to understand why developers have this huge reluctance to publish ARM versions. Even if there are only 1 million ARM devices compared to the 100s of millions of x86/x64, it's still zero cost to just click an extra button right? Or are there more complications involved? Thanks for all the info too!
  • The Windows API is a mix of a base C-style API for system functions and COM/WRT (which you can think of a C++ extension for compiled components reuses, basically standardizing the missing data types such as strings, and v-table to expose objects from DLLs) for libraries (DirectX, Multimedia, codecs, etc...) Win32 code is very portable, as is the NT kernel itself, so except in cases of slight oversights, properly written code, even pure Win32 API C or C++ literally requires just an extra checkbox to get compiled for a new platform in Visual Studio. I even had Win32 code that could compile for both Windows NT x86,Itanium,x64 and Windows CE ARM,MIPS,SH3,... without any change. They had a few oversights, mostly with generic types that are used for several things depending on flags. The best example of those is the DWORD (32-bit unsigned number) that was used for numerical values, but also for pointers in some API functions, and had to be modified to DWORD_PTR to support x64 (basically 32-bit on x86 but extends to 64-bit on x64) to allow it to store pointers as it was used.
    Once the code has been updated where needed, the code compiles to x86, ARM32, x64, Itanium, ARM64 without anything CPU-dependent. Basically it's a one-time work to check which DWORD needed to get upgraded to DWORD_PTR in the codebase.
    The only place where you really need to handle the different processors is if you have some Assembly code, but most apps have none of that nowadays. So yeah, providing ARM64 is even simpler than providing x64 was in the early Windows XP 64-bit Edition days, because code that has already been updated to support x64 should require no change at all to compile for ARM64. They just need to do some more testing on actual ARM hardware, and add a separate distribution package. I must admit that support for building MSI installation packages has been lagging a bit, require some more work than a checkbox to prepare a new one, and could require some more work to maintain a separate installation project, so that could explain some delay in distributing ARM versions, but for major software, they should sort that out even if it takes some time initially.
  • Thanks for sharing the detailed info! I guess major apps like Adobe Photoshop probably have a lot of low level processor dependent code, which may explain delay in simply publishing an ARM64 build of Photoshop overnight? It's been quite some time since the Pro X was released, and I would expect at least Adobe to have ARM64 versions of all their software available by now, except there are some processor dependent complications, which makes it more difficult to simply click a checkbox and have an ARM version ready.
  • Can you please let Affinty (Serif) know this, I reached out to them for support for the Surface Pro X and they said that they just created their app from scratch for Windows 10 and would need to build a whole new app to have it compatible for Windows 10 on Arm 😂. I'm not a dev but I was also under the impression that Visual Studio had the ability to compile code for ARM using the same code from x64.
  • This is also what confuses me all the time! How would an entire dev team, that wrote Affinity for Windows 10 be completely unaware of the fact that you can just click a checkbox and you immediately have an ARM64 version ready?? How did they even get the x64 version ready if they are this 'ignorant' of an almost trivial detail? It seems the consensus is that ARM64 builds are trivial once you have x64 codebase, but yet the devs seem to take forever to just click this build button :-(
  • > Is it simply a matter of clicking a button to publish an ARM build? Contrary to the opinion, popular on this site, it is not "a matter of clicking a button". For a simple illustration of why not, you can compile and run a little snippet of code below on Intel and ARM and observe the output. Now, it is not hard to figure out what went wrong in a dozen lines of code... non-trivial pieces of software are slightly more complicated :( 8<----------------------------------------------------------------------------------------
    Unfortunately, the piece of code could not be posted here -- you can take my word for it or look into the differences in the sign expansion on Intel and ARM. For the curious -- I put the code here: https://1drv.ms/u/s!AnDenCB0CXInjPtgYn4NzvLzG7RMOQ?e=kIPGHj
  • The C++ compiler treats variables of type char, signed char, and unsigned char as having different types.
    ( https://docs.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=vs-2019 ) Plain char '\xE7' can be signed or unsigned depending on the platform, you cannot make assumptions and compare its value to unsigned char 0xE7 without expecting the risk of a signed/unsigned mismatch. If you really need to handle chars as numbers for some important performance improvement, your code should check the _CHAR_UNSIGNED precompiler symbol to handle both cases as you're taking advantage of unspecified behavior. My claim still stands, if you have clean modern code, it will recompile easily, of course if you have code ignoring the specifications to take advantage of platform-specific behavior, your experience may vary.
  • > if you have clean modern code, it will recompile easily ... and it only relies on the clean modern libraries, and, preferably no longer that 66 lines long and all written by yourself in the last year or two... sure. The example in question was reduced from relatively small project (~100,000 lines of code) that I had to port from Power to Intel. Original code base was evolving for about 25 years. Now, something like Adobe Photoshop, likely has a codebase in the millions with a non-trivial percentage that has not been touched in over 20 years. 'nuff said.
  • I think you've really given the true picture, and it probably explains the delay/reluctance of major codebases getting ARM64 versions. Thanks for this, it's what I have suspected all along as well. Yes, in an ideal, nicely written, modern codebase, maybe one click will generate ARM64 from x64. But in practical, huge codebases spanning 30 years, it's just a messy, difficult journey.
  • > it's just a messy, difficult journey Amen... and I haven't touched on the elephant in the room, which is the performance of the said code after the port. There's a lot written on the performance optimizations for Intel, slightly less for Power and precious little for ARM.
  • It can be just a few button clicks, but as others have said it can be more complicated if you depend on libraries that haven't been fixed up by other people. A change like this is something that happens over years, MS cannot snap their fingers and make it happen but neither should they give up if it hasn't happened in just a couple of years. It took a great many years to introduce x64 and get support for that ramped up. As for Serif, it sounds as though the person doing support was under the impression that Windows of ARM is some completely incompatible thing built from scratch like macOS -> iOS. It might take a little while to work through the build issues but unless they hand wrote it all in assembly code the idea they'd have to start from scratch is crazy. Having said that, if they used WPF and .net, well a native ARM version of that isn't coming until the end of this year with .net 5.
  • Interesting article. I think the real elephant in the room is that there just isn't that much software for MacOS and very little need for compliance with old corporate software. Also, most low-end Mac users are basically browser jockeys and might as well move to iOS or, really, anything else. (That shiny Apple logo tho... Probably iOS.) Both the risks to Apple and the gains to the consumer are low here.
  • > there just isn't that much software for MacOS I am not sure what this statement is based on. > most low-end Mac users are basically browser jockeys and might as well move to iOS Most low-end users are "browser jockeys" no matter what underlying OS they use and might as well move to ... Chromebooks? I see a lot of Apple-hate in your post and precious little meat -- since you are not 'bleached'... having a bad day?
  • I meant that all seriously. The app gap before the smartphone era wasn't between iOS and Android, it was between Windows and MacOS. Are you saying that's changed? Nothing I have read in the past 10 years says it has. (I could be wrong - I'm not an expert on this stuff.) The compatibility stakes are much higher for Windows devices moving to ARM. And yes, all low-end computer users are browser jockeys. But we're not talking about Chromebook users (my mom is a Chrome browser jockey!), we're talking about MacBook Air users. And the idea that they'd move to iOS eventually isn't that crazy, is it? So it's low stakes for Apple. Although I am totally cool with making fun of Apple, my comment wasn't actually that.
  • Hm... as someone, who moved personal laptop from MacOS to Windows as the result of Apple's keyboard decision, I see the app gap between MacOS and Windows in the different light -- not only I had quality applications that I had hard time finding for Windows, but I also had full gamut of open-source apps through the MacPorts project. Admittedly, the latter was remedied by WSL becoming viable. Now, to paraphrase one of the senior authors on this site, "that was how it worked for me" -- YMMV.
  • > I want from macOS on my windows systems Well, you will be you. This is not to say that you are wrong, mind you. OTOH, *I* want neither iMessage, nor FaceTime, but I would not mind having QuickSilver, Viscosity, Gemini II, iStatMenus and few things besides. And yes, I found the replacements by now, none of which are as well polished, but all of which are cheaper... which is the main difference, I have encountered moving from MacOS to Windows -- users of the latter do not mind paying for their software :)
  • Being that Apple is mostly a consumer focused company, they aren't missing any apps that consumers use.
  • Wonder when we will see the first hetero-core computers having both ARM and x64 processors in them. Your Phone technology, containers are basically a step behind this technology. We are basically running Qualcomm apps on our Intel/AMD devices. If they needn't to travel across meters of USB cables, they could significantly improve further.
  • I don't think so. The costs would go through the roof and there are a LOT of compatibility/switching issues. I find this idea up there with "just launch a dual OS device", which sounds good, but really no one wants that.
  • > "just launch a dual OS device", which sounds good, but really no one wants that. That depends on your definition of the "dual OS device" (think WSL).
  • I definitely don't mean something like WSL. I mean phones with dual OSs, or laptops that jump between ChromeOS and Windows. Parallels is the exception here, but even that is a minority of users (developers) and not regular consumers.
  • So your definition of dual OS device is something that you have to reboot between OSes? No contest there -- no end user would ever want that. And, if by "Parallels" you mean (https://www.parallels.com), I agree with your assessment. My definition of the dualOS device include WSL, WoW, yet to be released Win32 subsystem for WindowsX, Linux containers on the Chromebook and other things that allow me, as an end user, run applications written for the different OSes *simultaneously*. I guess VMware Unity mode comes close to your definition and still stays useful to the consumers, especially if nobody bothers to tell them about what they are actually running :)
  • Such devices existed in the past -- there were daughterboards for Power-based Macs and for PCI-based Sparcs (possibly more, but those are the two I had first hands experience with). Both had strong, but very niche appeal...
  • Apple survived 2.5 platform migrations, two major being Motorola 68K to Power and Power to Intel and the "half" being 6902 to 68K... they did it by thinking through the transition path (anyone remember "fat" executables) and treating the developers well. It would be interesting to see whether they can pull it off again.
  • There is no such thing as a 6902 CPU, certainly not in any computer that Apple sold. The Apple 2 family (2, 2+, 2e, 2c, 2gs and Apple 3) used the MOS Technology 6502, and variants thereof. This has nothing to do with Macs, and there was no transition. They were separate product lines. Therefore, Macs have had 2 CPU changes
  • First, thank you for your correction -- you are absolutely right it was 6502 -- I am just being silly. This said, Apple III was targeting business consumers, who have an unpleasant tendency to require continuity. Thus, I gave Apple half a transition from Apple III to Macintosh.
  • I don't think Apple will have an app problem. Two years ago Apple announced they were working to bring iOS apps to OS X. Between now and when this product releases, that's three years for devs to get their iOS app desktop ready. And when an ARM MacBook releases with millions of apps and games available, those saying Apple has an app problem will be drowned out by the heaping praise. Definitely there will be some big apps missing or undercooked, but I think people will be fine with windowed iPad apps on their ARM MacBook.
  • That's not the issue. The key is not having iOS apps running on your desktop, the key is having MacOS apps running on your iPad...so to speak. The hardware will be "iPad" hardware, i.e. ARM. You need to get MacOS apps, full Office, Photoshop, Final Cut Pro, etc., full versions, running on that architecture. Not doing so is what killed Windows RT. It could run some Windows applications, just not all the ones people expected, and not just the 'mobile' versions.
  • "Apple's 8-core A12 Bionic Chip series brings some serious performance that outmatches even the Surface Pro X's Qualcomm-based Microsoft SQ1 chip by a margin." Where is this performance testing data, and please don't share and or compare iPad A12 performance, find Apple's Bionic performance in Mac versus SQ1 in SPX.
    If that comparative scenario does not exist, then I beg to differ with your stated assertion in quote above. I will thus view simply as "Your Opinion" and not a demonstrated statement of fact., So, feel free to state IMO "Apple's 8-core A12 Bionic Chip series brings..."
  • "There's little doubt that Apple has an advantage when it comes to iPadOS and its own hardware contrasted to Microsoft." - There is no doubt at all. "But Apple does have arguably better developer relations compared to Microsoft" - It's not arguably, it's a fact. "Microsoft has been using ARM for many years now..." - And for the N-th time, whoever (usually Microsoft) came up with something first won't even matter, because when Apple steps in, they do it right, how it should have been done and will make others look laughable "How it plays out will likely be no different than today: Apple wins in the consumer market, while Microsoft dominates work and productivity." - Yes.
  • Judging by some of your other comments in this thread, you have never used the thing or, at least, not in the last 15 years. I am sure your opinion is well informed...
  • Au contraire ? Votre opinion n’est pas informée? Vraiment...
  • Judging by your answer, you do not understand what that sentence says... I guess *that* never prevented you from commenting :)
  • > Rene is waiting I seriously doubt that he is waiting, but, I suspect that, unlike you, he knows how to spell French :)
  • Heck, I can spell French. Now, spelling in French is something else. ;)
  • @Daniel Rubino : Does Qualcomm has a (temporary) exclusive right with Microsoft to design ARM computer chip compatible with Windows 10 ? I mean by that, could Microsoft freely engage with Apple to optimize Windows 10 on ARM to also work on future Apple Mac computers with ARM chips ? In theory, I would think that Windows 10 on ARM would have much better performance on a future Apple Mac on ARM than current Windows 10 on ARM computers using Qualcomm Snapdragon 8cx. But not sure that Qualcomm would appreciate this as then people would more likely prefer to buy a Mac on ARM computers most of the time, and Qualcomm would then maybe prefer to drop its costly efforts in developing Snapdragon computer chip due to the low potential of Return on Investment (RoI) ?
  • I've been a Surface user since 2015 but that move would make me switch to a MacBook, for sure. I'm sick and tired of old and outdated Intel.
  • Qualcom is not Intel.
  • You can buy Surface Pro X today with an ARM processor. Or AMD on the Laptop 15".
  • Surface Go should have gone ARM and Win10X. Missed opportunity.
  • Neither was ready.
  • At least this will push Qualcomm in to making proper chip for laptop /tablet formfactor unlike 8cx/sq1 which was just a 855 with a better gpu. Let's hope this also leads Intel & amd into making quality mobile chips. For the betterment of windows platform Intel & amd's progress in delivering mobile chip that can rival arm's efficiency & performance is must . Early benchmarks suggest Intel lakefield will be modest performer like core m. but obviously with much better power efficiency due to new hybrid architecture.
  • I don't think they will improve much. The reason why Apple's chips are so good is because they are designed specifically for their software. Hard to do that even if they work directly with Microsoft.
  • Apple could put out a $500 ARM laptop and put a big dent in Windows sales. I have always wondered why they haven't yet. ARM would be a perfect way to create a lightweight and cheap MacBook with great battery life.
  • They'd rather make iPads more capable and more expensive that make Macs cheaper.
  • What makes you think changing from Intel to a chip they design and commission themselves would make it cheaper? We have no idea how much A series chips are, as Apple doesn't break costs out like that...for us.
  • iPad starts at $329. Throw a keyboard on it and you are at $499.
  • "no different than today: Apple wins in the consumer market" I'd disagree with that right now, not sure about future but sales don't show growth over Windows. I think rather that's the image it got and people are much more forgiving when it comes to Apple. E.g. butterfly keyboard and very long upgrade cycles. I'd still rather have a touch-screen than none at all with lots of consumer choices (form factors, colors, screen design, ...).
  • Slow news day? Let's rehash an article from April...
  • Well, you're here, so ...
  • "But Apple does have arguably better developer relations compared to Microsoft" Folks, we have a new entry in the "Understatement of the century" sweepstakes. But seriously, I guarantee that Apple already has MacOS and all of their own apps running on their ARM hardware. There is probably a good amount of 3rd party stuff being worked on right now. Remember, in 2005 Apple did the entire show demonstrating the new Macs and OS X 10.4. At the very end of the show, they pulled up About This Mac and revealed that the ENTIRE demonstration was running on an Intel Mac. There was a gasp from the audience, and then cheering. Apple knows how to do this. They have already changed Mac CPUs twice. Which proves that MacOS is highly portable.