“While the focus on Apple’s smooshing together of its platforms has been primarily about the software (iOS apps running on the Mac) and hardware (the potential of future Macs running Apple-designed ARM processors), the new MacBook Air got me thinking about another way Apple’s approach to iPads and iPhones may dramatically change how we shop for Macs in the future,” Jason Snell writes for Macworld.
“The new $1,199 base-model MacBook Air comes with a 1.6GHz dual-core Core i5 processor with Turbo Boost up to 3.6GHz. If you max out all of its specs, on the other hand, you’ll walk away with a $2,600 computer… with the very same 1.6GHz processor,” Snell writes. “The new iPad Pro comes in a single processor option, the A12X. The iPhone XR and XS are powered by the A12. That’s it.”
“This feels like the future of the Mac, certainly on the consumer end of the product line,” Snell writes. “If Apple starts building Macs with ARM processors, is it going to want to offer different classes of processors within those models? On iOS, Apple has steadfastly refused to do this. Every model-year of a given model is generally powered by the same processor across the board.”
Read more in the full article here.
MacDailyNews Take: Snell also speculates that “RAM feels like a configuration option that might very well disappear when Apple makes the move to ARM. Instead, Apple will pick a RAM configuration that feels right for a given product, and stick with it.”
This would be a issue because until the most-recent top-of-the-line iPad Pro’s 6GB RAM, every single iPad Apple has ever produced lacked enough RAM to rally handle a professional workflow. Some people work across myriad apps, multiple tabs, etc. and need sufficient RAM – more RAM that whatever Apple imagines “the average user” would require. We’d hate to be forced to buy the highest storage option just to get enough RAM to work with, especially if we don’t need that storage.
ARM Consumer Macs, something else Pro Macs. This will require two versions of programs, or performance and battery wasting emulation.
Hey, who said fragmentation back there?
MacOS and iOS are the same OS. Both from NeXTSTEP which is highly portable and has already run on many different platforms. App development with universal binaries is already common. Running x86 binaries with a new Rosetta will be so simple you may not even notice. Programs aren’t the issue. That is already solved. The success of iOS has taken care of the messiest parts of any future transition to ARM for Mac. Fragmentation won’t be a thing. Apps will just work. Apple has already done all the hard work in this regard. Years ago in fact.
The real issue is not being able to run Windows and whether or not Apple can get enough performance out of an ARM platform for the Mac.
“Running x86 binaries with a new Rosetta”
Will not be necessary as Apple has had the frameworks in place for some time that can compile to Intel or ARM on request and maintain those on the App Store back end. When a device requests a software package, it gets sent the code that’s compiled for it.
If you’ve got anything Legacy, then you’ll need to keep your legacy computer to run legacy code.
That sounds right. The point is apps won’t be a problem. I wouldn’t bet against an easy way to run legacy apps on an ARM Mac though. It shouldn’t be difficult. It may be unnecessary given how easy it is already to develop apps for either platform as they are compiled on demand.
A multi-core supercomputer ARM concept is very interesting and could be extremely powerful. Intel needs to wake up.
“wouldn’t bet against an easy way to run legacy apps”
I agree, it’s “likely” not technically difficult, but Windows compatibility and native Intel execution were never “features”, it’s just what you got as an added bonus from Apple switching to Intel. However, they’ve been downplaying that angle in recent years. Such that the majority who are buying a mac today are buying it to run macOS and macOS apps.
NOW, something I just though about, since the new Pro system is supposed to be “modular”, I could see a well designed ARM processor that would handle Apple’s consumer AND Pro apps better than Intel could, while generating less heat. If you NEED Intel, you buy the x86 “module”. I doubt they’d sell very many… why would a professional that requires Intel NOT have an Intel based system?… But, like the Mac Pro, it could sell in low enough numbers to potentially be made in the US.
“When a device requests a software package, it gets sent the code that’s compiled for it.”
How is that different from, say, now?
The point is, that’s EXACTLY the way it works now. You don’t get code for an iPhone 4 that’s “emulated” or has anything like “Rosetta” on an iPhone X, all the binaries are available. You get what your system runs. It wouldn’t change just because ARM is inserted into the macOS picture.
Both are BSD btw… and an App would need to be compiled for one architecture or the other or need to run under emulation. But you knew that.
I fail to see how BSD is relevant here. The point Wrong Again and I are making is developers don’t need to make any changes to apps. They will just work if Apple changes the processor architecture. That’s what the move to bitcode three years ago was about. Apps are compiled for the device when you get them. No emulation is needed and no extra work is needed.
When you said “This will require two versions of programs, or performance and battery wasting emulation.”
Every part of that sentence is wrong. Those issues were solved three years ago by Apple.
If you feel to see how BSD is relevant, but you see how NextStepm a direct BSD derivative is indeed relevant, there’s something that doesn’t add up with you.
OSX came from NeXTSTEP which came from Unix/Mach/BSD. The point is that OSX and iOS are very flexible and can run on many different platforms. What was your point?
It doesn’t change that everything you said was wrong. There won’t need to be any emulation for apps or two versions of apps.
If you’re referring to Rosetta, that’s emulation. Either you need compound binaries or separately compiled applications. But you told me that….
I wasn’t referring to Rosetta except in the sense that Apple could have something like that up their sleeve to solve running Windows. You were talking about apps. I did say the real issue was running Windows.
The same app is compiled on demand for different architectures. That’s the beauty of bitcode. We might be talking past each other. You don’t seem to understand.
The fact remains that everything you said was wrong because you based your statement on wrong assumptions and outdated knowledge.
X86 requires x86 native code, arm needs arm. In line compilation is still producing different code. Arm is a risc instruction set Intel is a cisc, They compute differently thus the in line compilers are producing two different instruction sets, and infact can be very different in excecution. No different than separately compiled applications. Too java like btw…
It isn’t like Java at all. Apple’s approach allows developers to easily maintain an app for different architectures without the need for emulation. For the user it all just works and the developer doesn’t need to build another version of their app.
Facts are facts. Everything you said was wrong.
bytecode is bytecode.
I suppose bytecode is bytecode? Bitcode is not bytecode and saying bytecode is bytecode doesn’t fix anything about what you said. Okay. You don’t understand what we’re talking about. That much is clear now. Stay well.
You’re silly!
Now step away from the compiler before you hurt yourself and others.
PS-Thise issues were solved long ago with wasteful emulation. As for installing the right version as native binary, it’s never been an issue. The OS was the differentiator.
One reason I doubt this will happen is that Apple has historically offered higher-end configurations on its computers with more than corresponding higher prices.
I don’t see them abandoning the upsell potential of faster processors or more memory/storage.
Apple has also made serious committments to IBM and other F500 companies to support their employees with top notch Macs.
Hence, I see continued Mac OS & Windows use on Mac Hardware.
Introducing an ARM Mac doesn’t seem likely to help Apple & actually might be a kink in that the ARM chips for Macs would be low volume chip compared to iOS … forever.
Apple is already adding parallel computing with the T2 chip. I would imagine there would be more of that depending of how it’s spec’ed for the up-sell. Multi-processors, RAM, GPU, storage….
Apple will do fine with the up selling. No one should worry about that.
Totally agree would give Cook a heart attack otherwise.
Fact is for good or bad, and I suspect a mix of both, there will be A class Macs, the only alternative will be a long slow replacement by iPads or derivatives which I’m sure Cook would prefer but is unrealistic shorter term as his recent neglect of the Mac has shown. It would simply kill too many devoted Apple fans from staying on board while wasting the increasingly impressive power of Apple Silicon. Once the chips are fast enough to handle emulation at. competitive speeds we will see them in Macs or combo OS at the low end to start with. Their far superior power management will more than make up for any hit on battery life implications.
I suspect any delay will be to get such a head up on performance that the A or perhaps even a new B class will make full conversion of the platform as short as possible. That of course will actually allow a range of performance as is offered now so the writer is probably making a presumption that has little evidence to support it.
Tim and Apple LOVE the Mac. No worries for the Mac. Let’s remember, Apple sells half as many Macs than iPads, yet makes TWICE as much money off of them. What’s not to love? Who would dare hurt that business model? Sell less, make more money. That’s a golden goose no one is going to kill.
“It would simply kill too many devoted Apple fans”
This can’t be true. The vast majority of Apple fans are fans of iOS. By quite a stretch. There are a few that are fans of both, but “a few” does not equal “too many”.
Given the prices Apple charges for RAM and SSD upgrades, I hardly doubt this will ever happen.
The writer could just look at the fact that the chip in the MacBook Air wasn’t even KNOWN to anyone until the Air was released. This isn’t a choice by Apple, I’m sure they would have preferred to provide a variety of speeds. BUT, they can’t offer what Intel doesn’t make, and that’s currently the fact they live with.
Testing out the gravatar.
“If Apple starts building Macs with ARM processors, is it going to want to offer different classes of processors within those models? On iOS, Apple has steadfastly refused to do this. Every model-year of a given model is generally powered by the same processor across the board.”
Why is this posed as a negative? There is no inherent benefit in having and using several variants of a processor at different clock speeds, different amounts of L2 and L3 cache, etc. Indeed, I would prefer that Apple choose the high end processor for a given Mac lineup – Apple would gain economies of scale and consumers would gain performance on lower end machines that are typically saddled with lower end processors.
This evolution is a natural outcome of Apple’s in-house A-series SoC development. Apple typically only has two variants of its SoC – the initial release and the subsequent “X” version with beefed up graphics for the iPad (and, eventually, Macs).
Rather than struggling to distinguish between many versions of an Intel CPU family, performance will come down to the generation of the processor (A12X, for instance) and (assuming that Apple is designing future A-series processors for parallel configurations), the number of A-series SoCs used in a given Mac configuration.
For example, a new 2019 Mac would use the A12X and you might be able to choose between 4, 8, and 12 processors for a MacBook Pro. Mac Pros might offer configurations with dozens of A-series processors.
Next year, Macs would use the A13X. The year after, Macs would use the A14X assuming an annual A-series upgrade cycle, although I suspect that the period of the upgrade cycle will eventually stretch out to two years.
The advantages to Apple are obvious. Apple already procures a couple of hundred million A-series processors each year for its iOS devices. The economy of scale of increasing the size of that annual A-series processor order by another 30M, 50M, or more would greatly reduce component costs for Macs while also breaking the handcuffs between Apple and Intel. Apple could regain bragging rights on workstation performance that it used to have back in the mid-1990s and differentiate its Mac products from the field of Wintel PCs once again.
It made sense to transition Macs from Motorola processors to PPC in the mid-1990s. It made sense to transition Macs from the PPC to Intel processors in the mid-2000s. And it now makes sense to transition Macs from Intel to ARM-based A-series processors in the 2020 timeframe.