ARM Mac coming in first half of 2021, says Ming-Chi Kuo

Posted:
in Future Apple Hardware edited June 2020
Apple is continuing to work on a self-designed processor for use in a future Mac, analyst Ming-Chi Kuo, with the first possible release using an ARM-based chip instead of an Intel processor likely to arrive in the first half of 2021.

MacBook Air, a likely candidate for an ARM processor
MacBook Air, a likely candidate for an ARM processor


Rumors of an ARM-based Mac or MacBook have surfaced in a while, with the general theme of Apple moving away from its reliance on Intel Core processors in favor of its own silicon. According to TF Securities' Ming-Chi Kuo, this could happen sooner than people may think.

In a note to investors seen by AppleInsider, Kuo forecasts that Apple will be using a 5-nanometer process at the core of its new products 12 to 18 months' time. As part of this, Kuo believes there will be a "new 1H21 Mac equipped with the own-design processor."

The creation of its own processor would, most likely, lean on Apple's extensive knowledge of chip design for the iPhone, iPad, and other devices that use the A-series chips, as well as other periphery silicon of its own devising. This would enable it to use designs it created to help reduce the amount of power the chip consumed, for example, as it did with the A13 Bionic.

A move to its own chips would also mean it wouldn't be bound to the limitations of Intel's designs. If Apple wanted to introduce new features or believed it could implement a processing technique in a better way than Intel, it would be free to do so under its own steam.

Shifting over to an ARM-based chip would also give some context to Apple's decision to move away from supporting 32-bit apps in macOS Catalina, as well as Apple's work on Catalyst. In theory, this could allow Apple to use the same chips in the Mac as it does in iPhones and iPads, reducing its overall costs and enabling apps to be more usable throughout the entire Apple ecosystem.

Kuo's nearer-term proposed uses of 5-nanometer chips by Apple also includes the "iPhone 12" as well a refreshed iPad for the second half of 2020 equipped with mini LED.
«1345678

Comments

  • Reply 1 of 149
    lkrupplkrupp Posts: 9,471member
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    dtb200
  • Reply 2 of 149
    blastdoorblastdoor Posts: 2,438member
    If true, the timing is a bit ironic as 2021 is when intel might finally be getting their issues sorted out. The competition between Intel and AMD is likely to be fierce, benefiting OEMs and end-users alike. 
  • Reply 3 of 149
    Mike WuertheleMike Wuerthele Posts: 6,262administrator
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    netroxcaladanianOfernetmageargonaut
  • Reply 4 of 149
    thttht Posts: 4,040member
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    It can be a lot like the last time.

    1. Apps using Apple’s frameworks and Xcode will mostly be a recompile
    2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime)
    3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.

    And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
    cornchipOferjony0
  • Reply 5 of 149
    I imagine when someone "ports" their iPad over to the macOS via Catalyst it already has the code to run on ARM so it would not surprise me if Apple comes out and says "and if you develop for both iOS and macOS your apps will work right out of the bag!" With that being said, WWDC should be an interesting one this year. Maybe Apple will start encouraging developers who do not have an iOS app to bring their apps to that platform so it will be a seamless task to bring it back to the Mac once they have ARM processors?
    razorpitcornchipargonaut
  • Reply 6 of 149
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    There isn’t as big a jump in performance of current Intel processors cs Apple’s A-series as there was in then PPC vs then-current Intel.  That said, the primary reason why the switchover was so successful was that the lion’s share of applications used mainly just a few Toobox calls. For example, Excel would spend on average 70% of its time in the API DrawString().  So if Apple has only ported that single function to Intel-native code, with no extra work on Microsoft’s part, Excel would be running 70% of the time as a Native application. 

    I don’t think the switchover will happen across the board as quickly as it did then ,either. It’s a long long way off before the Mac Pro could be an A-series-based machine. Not because Apple couldn’t sooner rather than later match the performance, but because the Target customers’ tools have too much invested for much longer a term in Intel. 
    netroxElCapitanviclauyycargonautkillroy
  • Reply 7 of 149
    crowleycrowley Posts: 8,750member
    I wonder if they'll go all-in on a line, or if they'll parallel sell an Intel and an ARM version of, say the MacBook Air.

    Assuming some meaure of accuracy in the report, of course.
    cornchip
  • Reply 8 of 149
    An "A15X" type 5 nm chip in a laptop is going to blow the doors off anything offered by Intel

    Batteries in the MBP are 2-2.5x the size of iPad Pros.   Plus the thermal envelope of the MBPs are much greater.    It will allow Apple to dramatically increase the number of cores plus boost the clock frequency.    It is going to be something to behold 

    This is the laptop I want 

    edited February 2020 longpathcanukstormMisterKitmwhitecornchipOferargonaut
  • Reply 9 of 149
    blastdoorblastdoor Posts: 2,438member
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    I'll hazard a guess that if such a transition occurs, it will be much easier than previous transitions thanks to Apple's control over development tools and the now total elimination of Carbon. The last remnants of the Classic Mac have been swept away, as has the need for caring about the underlying CPU architecture when writing MOST (But not all) code. 

    While I'm sure that some code will have to be emulated, I bet a lot won't need to be thanks to (1) use of Apple frameworks that will be ARM-native and (2) easy-peasy recompilation of lots and lots of code. 
  • Reply 10 of 149
    red oak said:
    An "A15X" type 5 nm chip in a laptop is going to blow the doors off anything offered by Intel

    Batteries in the MBP are 2-2.5x the size of iPad Pros.   Plus the thermal envelope of the MBPs are much greater.    It will allow Apple to dramatically increase the number of cores plus boost the clock frequency.    It is going to be something to behold 

    This is the laptop I want 

    You & me both!!!!
    red oakcornchipgenovelleapathy_forever
  • Reply 11 of 149
    tmaytmay Posts: 5,430member
    tht said:
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    It can be a lot like the last time.

    1. Apps using Apple’s frameworks and Xcode will mostly be a recompile
    2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime)
    3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.

    And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
    Presumably, Apple will initially be delivering the "consumer" Mac's, a MacBook Air, and maybe a Mac Mini, analog with ARM, sans x86 compatibility, so users that require X86 will still have other Intel options. I would expect there to be overlap of ARM Mac and Mac Intel for quite some time, but also consider that AMD may replace Intel for some products.
    edited February 2020 argonaut
  • Reply 12 of 149
    blastdoorblastdoor Posts: 2,438member
    red oak said:
    An "A15X" type 5 nm chip in a laptop is going to blow the doors off anything offered by Intel

    Batteries in the MBP are 2-2.5x the size of iPad Pros.   Plus the thermal envelope of the MBPs are much greater.    It will allow Apple to dramatically increase the number of cores plus boost the clock frequency.    It is going to be something to behold 

    This is the laptop I want 

    I'm not so sure. A TSMC 7nm A13X chip could probably blow the doors off Intel's 14nm Skylake-based lineup. But if Intel makes good on its roadmap of 7nm (which is more analogous to TSMC 5nm) in 2021, then it could be a much closer competition (especially with Sunny/Willow Cove cores and AVX512). 

    The big question is whether Intel will delay 7nm. They keep saying they're on track, but we've heard that before. 
    FileMakerFeller
  • Reply 13 of 149
    Apple, has had extensive work in this area, going from:

    OS 9 -> OS X
    Carbon
    PPC -> Intel
    Rosetta
    32-bit -> 64-bit
    Universal
    macOS -> iOS (simulator)
    etc...

    At this point I am sure they will have the heralded,
    "Just click to compile for ARM (button)" farily ready to go...

    So waiting!
    red oakcornchipargonaut
  • Reply 14 of 149
    thttht Posts: 4,040member
    Shifting over to an ARM-based chip would also give some context to Apple's decision to move away from supporting 32-bit apps in macOS Catalina, as well as Apple's work on Catalyst. In theory, this could allow Apple to use the same chips in the Mac as it does in iPhones and iPads, reducing its overall costs and enabling apps to be more usable throughout the entire Apple ecosystem. 
    I don’t see how any of this would make it easier for Apple to make macOS/ARM. macOS in of itself will be fairly easy. It’s the ball and chain of 3rd party apps that will drag it out across years. Catalyst doesn’t enable making macOS/ARM easier whatsoever, and 32 bit perhaps only makes it easier for Apple in having less work to do. 

    The goal is to make moving x86 macOS applications on to ARM as simple as a recompile. Eg, make it as easy and cheap as possible for Adobe and MS to move their apps over. That basically means making sure CLANG and LLVM can take their generic C++ or .NET frameworks, but likely with x86 dependencies here and there, can compile them on ARM without any issues, making sure they can compile all the Unix utilities without issue. Same thing with the game engine platforms. If they have x86 dependencies, Apple has to find away to handle them.

    If there is a lot of work to be done by the developers, it’s game over. This is why Carbon worked while the previous Rhapsody strategy was doomed to failure.
    roundaboutnowFileMakerFellerkillroy
  • Reply 15 of 149
    thttht Posts: 4,040member
    tmay said:
    tht said:
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    It can be a lot like the last time.

    1. Apps using Apple’s frameworks and Xcode will mostly be a recompile
    2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime)
    3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.

    And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
    Presumably, Apple will initially be delivering the "consumer" Mac's, a MacBook Air, and maybe a Mac Mini, analog with ARM, sans x86 compatibility, so users that require X86 will still have other Intel options. I would expect there to be overlap of ARM Mac and Mac Intel for quite some time, but also consider that AMD may replace Intel for some products.
    I think it will be desktops first. Start with the form factor with the least amount of sales for the customers who will want them first, namely developers. Then, I think they will transition the Mac product lines completely to ARM as fast as possible. 2 years or less.

    If they ship Intel and ARM PCs simultaneously, especially in the same product category, for a long time, all they are doing is delaying or decreasing the amount of 3rd party application support for their ARM personal computers.
  • Reply 16 of 149
    melgrossmelgross Posts: 33,035member
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    This is the problem I’ve been wondering about for some time. While some people dismiss this as an issue, or in most cases, don’t even think about it (aren’t aware it is an issue), it’s the biggest issue apple will need to deal with. In previous changeovers, even Apple was very lax in getting their own big apps out. It took a year for them. It took a long time for Adobe and Microsoft, with their massive software, to come over too.

    ARM is not close to x86. It’s optimized for battery life over performance. Apple and ARM have made significant advances on that front, but the instruction sets are different enough. We know from previous attempts at emulation, that a processor family needs to be 5 times as powerful in order to be able to run software at the same speed as the family they’re emulating. This hasn’t changed. Microsoft supposedly does it now, with their “universal” sdk. But they don’t, really. They require software to be rewritten, and recompiled for ARM. And there have still been issues with performance, specific features and bugs.

    im not saying it can’t be done, because obviously it can. But if Apple is really going to release a device next year, there will either be significant limitations, or they’ve figured out a way around them. My suggestion, which no one here has ever commented on, from my memory, is to add a dozen x86 instructions to the chip. It’s been found that 80% of the slowdown between chip families is from about a dozen instructions. The chip, or OS, could hand that over to those when native x86 software needs them. Individual instructions aren’t patented, or copyrighted, as far as I know. If true, that would give Apple a way around the problem.
    edited February 2020 jdb8167rundhvidFileMakerFellerargonautmuthuk_vanalingam
  • Reply 17 of 149
    Arm doesn’t bother me so long as the performance exceeds the best x86 processors. 

    If that means a 12 core arm as standard, then do it. 

    Just don’t give me some iPad CPU in my Mac. 

    That would be doing it very wrong. 
    MisterKitargonaut
  • Reply 18 of 149
    melgrossmelgross Posts: 33,035member

    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    Microsoft’s solution requires a software rewrite, and a recompile. It’s not a “real” solution. A Rosetta solution is just a quick, temporary hack, in the hope that developers will quickly move to new native apps, and a total rewrite of their old ones, and the expectation that newer hardware will be faster, and allow the Rosetta solution, which is half as fast, on an equivalent chip, to become less of a drag on performance. I remember all of Apple’s changeovers, and they were all pretty slow for about three years, when the new CPU’s caught up, and native software also took over.

    what’s been questioned about Apple making another changeover now, is whether major producers will again follow along. Anyone who says they will is just guessing, because they don’t know. I see moving to iOS, because of the number of devices out there, but Mac growth has stalled at just over 100 million installations around the world. Small developers might jump in, but large ones? It’s not a sure thing.

    what makes it more iffy is the way Apple will need to do this. They can just put their toe in the water, they can’t just jump in. So there will, at first, be no machines out there. Developers are reluctant to develop for what will be at first, a non existent market. They will wait. This is one of the reasons Windows phone died. Developers waited to see if it would sell in large numbers, and oeople would buy until the apps they wanted were there. Microsoft ended up paying developers to write for it, but it didn’t work.
    edited February 2020
  • Reply 19 of 149
    There is also (I believe) a substantial cost savings to Apple here 

    Assumptions: 

    -  Half of Macs use internally developed Apple CPU: 10M/yr    (the other half stays on Intel)
    -  Current cost Apple pays per Intel chip:  $200  (likely higher)
    -  Cost to Apple to manufacture new chip at TMSC:   $30 (likely lower)
    -  Dedicated Apple CPU chip employees and cost:   300 employees x $400K/yr fully weighted cost =  $120M 


    Total Intel Cost:  10M x $180 =  $2B
    Total internal Apple Cost:   10M x $30 =  $300M + $120M = $420M 


    Total Annual Savings:    $2B - $420M = $1.6 Billion 


    It would be $3.2 Billion if Apple were to move it all internal.   That would increase overall gross margin of the company by ~ 1%.    It would be a huge financial win.   But more importantly, it gets Apple untangled from the mess that is Intel

    Not included here is the massive R&D effort/spend to get to launch.   Maybe this is one of the driver's of Apple R&D spend exploding over the last 5 years 

    edited February 2020 MisterKit
  • Reply 20 of 149
    tmaytmay Posts: 5,430member
    tht said:
    tmay said:
    tht said:
    lkrupp said:
    Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
    Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.

    A Rosetta-like framework is the most likely.
    It can be a lot like the last time.

    1. Apps using Apple’s frameworks and Xcode will mostly be a recompile
    2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime)
    3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.

    And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
    Presumably, Apple will initially be delivering the "consumer" Mac's, a MacBook Air, and maybe a Mac Mini, analog with ARM, sans x86 compatibility, so users that require X86 will still have other Intel options. I would expect there to be overlap of ARM Mac and Mac Intel for quite some time, but also consider that AMD may replace Intel for some products.
    I think it will be desktops first. Start with the form factor with the least amount of sales for the customers who will want them first, namely developers. Then, I think they will transition the Mac product lines completely to ARM as fast as possible. 2 years or less.

    If they ship Intel and ARM PCs simultaneously, especially in the same product category, for a long time, all they are doing is delaying or decreasing the amount of 3rd party application support for their ARM personal computers.
    ARM is intended to drive costs down, with better battery life, for a lower price point. That says Mac Book or Mac Book Air, not desktops. I'd argue that there is a significant proportion of Mac users who have never needed X86 compatibility, I certainly haven't, so eliminate it from initial products. Let current Mac developers reap the benefit of providing new capabilities and opportunities to ARM Mac users.
    netmageargonaut
Sign In or Register to comment.