Not necessary. They only need to ship one model of Mac Mini or any small desktop lineup with Ryzen to improve their negotiating position while still being compatible with the existing x86_64 ecosystem.
So no, this is not merely a negotiation jibe. There are definite long-term prospects.
We're already moving to a mobile-first design and approach world. Having those mobile/tablet apps expand automatically to desktop is the next logical conclusion. As an app developer, there is nothing better than write-once-run-everywhere, and the cascading effects of that on the whole Apple ecosystem and future consumer audience is hard to understate. Keeping aside power, efficiency, device prices, opportunity costs and much more.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
Definitely not today. Its been speculated for many years now ever since the A4 chips, and its still not official news. Usual "people who don't want to be identified". If or when this becomes official news, most partners would be like about time, because everyone is in one way or another working on convergence and multi-device. Adobe and Microsoft are examples of pivoting many of their desktop businesses successfully to cloud and apps already.
Thankfully Apple comprises vastly smarter people than me, but I've always thought this is a bad idea.
The two interaction models are so dramatically different that I don't see how merging them makes sense. A finger is not a mouse.
There are no good or bad ideas :) Its all about time, place, knowledge of tradeoffs, execution, business, marketing, taking into account all stakeholders (user is one of them) and everything holistic :)
What you say is true, a finger is not a mouse. But we're now a decade past the release of iPhone, and by this time, the industry in general (and Apple in particular) have deep knowledge about all the tradeoffs involved here. 5 years before and this can be considered a reckless bet that requires a Steve Jobs to pull out. Now, its just natural evolution. Responsive design has been around for even longer, and changing interactions based on screen and form factors is a pretty mature problem domain now.
To be very specific:
- whether its a finger or mouse can be a runtime decision, not necessarily a compile-time or clean-slate/distribution decision for different platforms
- those decisions are already standardized enough based on existing knowledge that you can let the platform/framework (or 3p libraries) handle it out-of-the-box for you and just register multiple possibilities. instead of debating finger vs mouse - think finger and mouse
i.e. different interactions requiring entirely different apps - is not necessarily true for all of them. for a 2D application, some amount of standardization is actually good, otherwise it doesn't really help all the interaction patterns and may instead stagnate them.
Is my anecdotal too far off?
If you look at the PPC->Intel timeline[1], Apple announced it 6 months in advance, although it went fairly quickly after that.
1: https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...
What's stopping Apple from shipping Macbooks with a custom SoC that can run existing Apps in emulation until developers can recompile? I would argue that most Air and Macbook owners aren't developers and probably don't have many apps that didn't ship with their system.
The processor doesn't matter.
Compiling for different architectures was a checkbox in ProjectBuilder (after you took care of endian issues, once). Much easier than in Xcode today.
My favorite was that they apparently shipped an additional architecture by accident: the developer tools came with one of the aforementioned architectures long after it had been officially dropped.
The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know.
Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at.
[0] https://arstechnica.com/staff/2008/04/rhapsody-and-blues/
[1] http://vintagemacmuseum.com/the-apple-developer-transition-s...
I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.
1) Old programs don't work, because it is a different CPU architecture. 2) Old programs work, but in a VM, so it can't take full advantage of the hardware. 3) Old programs must be recompiled to work on new architecture.
The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs.
None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software.
Cheers
I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place.
If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs.
You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)
But compare the Intel Core m3 to the Apple A11, and a completely different story will emerge. The A11 is already comparable to relatively recent Macbooks in terms of performance.
Keep in mind that while you don’t see much 68k outside embedded these days, you still see POWER in supercomputer rankings, and it also appeared in game consoles.
If Apple ends up doing it, the proposition would almost certainly be different and it seems very unlikely it would involve things like running your x86_64 macOS apps on your brand new Mac except three times slower. Thinking about this in terms of previous changes (or in terms of PPC history details) just seems obviously wrongheaded to me.
The Macbook Core i3 is barely enough to run Safari or iTunes and Apple could probably replace the CPU without many of those users ever noticing.
The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench, and within about 30% on their top desktop CPUs.
It's entirely possible for chip architectures to see 2x-3x speeds when moving from mobile power budgets to desktop power budgets.
An Intel Pentium 4410Y Kaby Lake running at 4.5-6 Watts gets about 1800 single-core on Geekbench, while an Intel Core i7-7700K Kaby Lake running at 115 Watts gets 5600 single-core on Geekbench.
No, they aren't. iPhone X's multithreaded geekbench score is 10k. The 15" macbook pro is 15k. That's a lot more than 10%. It's only close if you look at the lower end Intel chips, the dual core ones (which is what Apple ships in the 13" macbook pro).
What do you think is the most important for 250million desktop users? Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
My dual Xeon E5-2690 v4 regularly loads all its cores and benefits greatly from them, but keep making assumptions by all means.
But if all you want is a chromebook competitor then sure, A11-class works fine. I'm going to guess that the people using Mac Pros tend to care a bit more about just running Chrome/Safari, though. Maybe Apple is just going to completely give up on their historically strong content creation market.
I don't think we can make that assumption here. I would be very surprised if the ARM chips they put in desktops are identical to the ones they put in phones.
For one, the power budget is going to be a lot larger (even for a notebook), and power is roughly equivalent to speed.
They will not compete at the high end against the Core i7s with 6 cores running at 3.8GHz (12 with HT) though.
https://browser.geekbench.com/mac-benchmarks
> iMac (27-inch Retina Mid 2017) | Intel Core i7-7700K @ 4.2 GHz (4 cores) | 5683
https://browser.geekbench.com/ios-benchmarks
> iPhone 8 | Apple A11 Bionic @ 2.4 GHz | 4217
4217 for Apple A11 @ 2.4Ghz vs 5683 for Intel Core i7-7700K @ 4.2GHz
Of course, microbenchmarks don't mean much. But the margins are thin enough for users to notice already. Add in more power, more cores, more Ghz, better optimized instruction set, more vertically integrated system, and who knows.
Geekbench is not at all a reliable benchmark that tells you anything about real preformance.
Its a total farce to suggest that a CPU with a power budget that is 10x to 20x larger, on a modern process, with modern archtecture is somehow just as fast or slower.
The market segment isn't that large though so it seems tough to get it done within the laptop budget. Still, it could benefit the other devices and streamline the hardware development, so maybe they think it's worthwhile.
Will it be that simple? Apple's own Logic Pro ships with a lot of legacy products from Emagic days. I know they've re-skinned a few with the last couple releases, but I'm guessing a lot of the DSP code is still the same.
"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008. , (Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.
Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.
A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.
Google didn’t answer that for me, but I found out that there now is a ”cp15 sctlr[1] (alignment bit)”. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... says this about it:
”3.5.1. Alignment faults
If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”
the article (thin as it is) claims a multi-step transition. Apple almost certainly has a version of Mac OS that can run on their iPad hardware - the transition path that makes the most sense to me is a 12" MacBook that runs essentially the same internal hardware as an iPad pro, and a MacOS that can run iOS apps. There would be a great consumer market for a MacBook that runs iOS apps, and it would serve as a hardware test bed for developers to get their MacOS applications ported over to ARM before transitioning the MacBook Pro lineup away from x86.
https://www.macrumors.com/2015/11/16/tim-cook-no-converged-m...
>We feel strongly that customers are not really looking for a converged Mac and iPad, because what that would wind up doing, or what we’re worried would happen, is that neither experience would be as good as the customer wants. So we want to make the best tablet in the world and the best Mac in the world. And putting those two together would not achieve either. You’d begin to compromise in different ways.
But as a former Surface Pro owner who now has an iPad Pro, I don’t see that happening. The iPad is immeasurably better as a tablet when you have tablet-oriented software available. And when you don’t, obviously the Surface’s compromise of “have a crappy desktop experience too” is usable if you need to have that option. But it’s not good compared to stuff designed for a tablet.
Similarly, the chunks of Windows 10 that are clearly designed for touchscreens (like the new Settings app) are not great on a desktop compared to the older and still more powerful control panel. More consistent, sure, as any ground-up redo would be, but the information density of things like the Add or Remove Programs list is awful compared to what it was before.
I don’t think Apple is going to make those compromises. They might do a more converged developer backened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
This, I think, is the most accurate picture of future iOS / Mac convergence. Universal binaries that present either a desktop, tablet, or phone UI based on where they're running.
Microsoft's mistake was trying to converge the desktop and tablet UIs.
Unifying the Mac frontend into that ecosystem just seems like the obvious conclusion.
I don't know that they'd strictly be the same executable, but at least as far as the user is concerned they would be the same piece of software. From a developer perspective, multiple UIs built with slightly different flavors of AppKit depending on the UI paradigm, including the Mac which is currently targeted by AppKit.
iOS doesn’t handle that kind of UI well.
There’s also the cost issue. All but the most exotic iOS apps cost less than $100. Many professional apps cost hundreds or thousands of dollars.
It’s not just a fundamentally different market. The products are fundamentally different in critical ways.
I can imagine a hybrid MacPad product - maybe a dual-panel clamshell - but if it’s done badly it would be the worst of both worlds.
I auspect it could a succesful replacement for the iOS product line, with dual MacPadOS and iOS support.
But I can’t see it working for professionals without a lot of breakage.
If it didn't need a totally separate UI framework, ports like this would take less effort and more apps would do it. Maybe you can't sell it for 6x the cost any more, but a comparatively small amount of work gives you a leg up on the competition.
Twitter is another example. They killed the native Mac client earlier this year and said "For the full Twitter experience on Mac, visit Twitter on web."
It's also worth noting that when he said that, Chromebooks didn't run android apps.
Putting an ARM processor in a Mac does absolutely nothing to change the viability of running iOS apps on a Mac.
iOS developers always compile, test, and debug their apps on x86. The challenge of running iOS apps on x86 was solved 10 years ago.
https://www.macrumors.com/2018/01/31/apple-still-plans-combi...
Or it could be nothing. This is a pretty thin article.
They definitely do have OSX running on ARM64, they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX, NeXT ran on x86, SPARC, PA-RISC and 68k, PPC is the one Apple had to add), they've already gone through two architectural migrations (68k -> PPC and PPC -> x86) and by all accounts the iOS core is very much shared with OSX, it wouldn't make sense not to port OSX along the way.
Although NeXTStep ran on x86, the MacOS build on x86 was John Scheinberg's personal skunkworks project until it became Marklar in 2001 (and then kept under the hood for another four years). Mind, Darwin was always written to be portable, but it wasn't a deliberate strategy to take it to Intel. This time around though, I too reckon that they have already a MacBook running on an A10X in the labs.
I was just listening to a Windows Weekly podcast about that, and its limited to 32-bit x86 binaries only, no 64-bit support. They also said its "unusable" for 32-bit apps (in particular Chrome), because you can watch the system drawing the windows of x86 apps on the screen.
Watching the video, they seem to be exaggerating a bit with "unusable", but Chrome does look sluggish, and the startup of "DrRacket" and its window redraw does look very slow too.
Edit: After watching the video, that didn't seem too bad. Perhaps it would work well enough on top of a beefier ARM processor? Of course the lack of x86_64 support is another issue that may not have a reasonable solution.
I'm reminded of the patent-sharing agreement between the two. Or, given MS' diversification, they may be willing to directly license the tech. Making the x64 -> aarch64 translation as robust as possible has benefits for both companies, and they're not nearly the bitter enemies they used to be.
No, they have tech for executing i686 binaries on aarch64, not x86_64. Big difference.
Meanwhile, High Sierra is the last macOS release to support 32-bit binaries.
"Without compromise". We'll see what this means later, but most likely it'll mean that macOS won't ship with a 32-bit runtime and you'll be able to download as you do with Java.
On PPC you could either dual-boot or run OS9 (and 8?) apps seamlessly on an OSX desktop, which was pretty impressive.
The seamless emulation of OSX-PPC apps on an Intel processor was extremely impressive though. I remember the majority of stuff working surprisingly well with little slowdown (though this might now be rose-tinted).
Mac OS 9 inside of “Classic” (the VM that ran OS 9 inside of OS X) wasn’t especially seamless, but what was seamless was “Carbon”, a transitional API that allowed developers to build apps that ran natively on both Mac OS 9 and Mac OS X. It didn’t take nearly as long to port code from OS 9 to Carbon as it would have taken to port to Cocoa, so many early OS X apps were Carbon ports.
I dunno, I feel like the writing has been on the wall for Apple to switch to their own ARM chips, for 3 or 4 years now. At first it was "yeah maybe someday", but by this point, I'm just surprised they're waiting until 2020. I was hoping the first ARM Macbooks would be this summer. (Really, last summer, if I'm being honest).
In 2020 I doubt anyone will see any problems with ARM performance on a desktop or laptop.
Edit: Found the source: http://atp.fm/205-chris-lattner-interview-transcript/#bitcod...
Doesn't all have to happen at once, and Apple has been though this before in the PPC-Intel switch, which went rather well.
I concluded ARM was fast enough for 90% of users. Once you don't have the restriction of battery life and small enclosure it is not hard to imagine that Apple could beef up ARM a lot for their desktops and laptops.
Why run multiple CPU architectures when one does the job and is much cheaper?
I've been thinking hard about what kind of workload ARM can't handle and I can't think of anything. Ok... there is one 1st person shooter games. But iOS is a more successful gaming platform than Mac.
Why is it unlikely that Apple would make a x86 chip? Because of IP/licensing, or for technical reasons?
[1]: https://www.idc.com/getdoc.jsp?containerId=prUS43495918
When I say that, I'm thinking of the old TED Talk by Amory Lovins called "Winning the Oil Endgame". I feel like there's some parallel one could draw between peak oil and process improvements. Intel has slowed down now that it's more difficult to extract increased performance with each iteration. I'm guessing someone at Apple is thinking about where they'd like to be positioned when the well runs dry.
This announcement is hardly a surprise. The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices. What that replacement meant is that it would ease Apple's transition away from any particular architecture - developers shouldn't have to do much if the app is installed from the App Store.
These weren't clear signs of an upcoming ARM switch:
• Apple has been purging software that's under the GPL for quite a while now, and GCC was probably high on the list since Apple (NeXT) had been bitten by its license before[1].
• The Intel switch in 2006 was extremely smooth even using GCC.
• Bitcode is not enabled on macOS, and even if it were, it's not abstract enough to recompile an x86 app for ARM[2].
[1] https://news.ycombinator.com/item?id=9158017 [2] https://news.ycombinator.com/item?id=9728162
To make their own chips, they'd need to either license from an existing holder (which wouldn't let them tinker unless it was a partnership or they acquired the license) or they'd need to make something so incredibly great the other three would trip over themselves to use it, and bind themselves in the process.
(Price tag would be in the ballpark of $15-20 billion, 3 months of income for Apple)
https://www.kitguru.net/components/cpu/anton-shilov/amd-clar...
In theory, but then VIA is a subsidiary of Formosa Plastics Group, so they'd need to either negotiate the sale with an entity with which they've locked horns in the past or buy an entire petrochemical group???
They'd probably have an easier time buying AMD.
They can't buy AMD (nobody can) for patents as licences on parts of x64 AMD doesn't own will be voided if AMD is ever acquired.
Intel will also lose access to AMD patents.
I know the iPad Pros certainly outperform many cheaper Intel chips while using lower power.
But I doubt they would want to split the line into half ARM half Intel, or move the Mac Pro to ARM.
What pro task, really requires high single thread performance? I imagine Apple could match intel by simply using more cores on their ARM CPUs.
Only issue I have on Mac is compiling large programs.
- an iMac that didn't really meet my needs
- a ridiculously unaffordable Mac Pro tower
I jumped over to Linux running on commodity PC hardware.
It'd be perfectly valid to write an application for the MAS in x64 assembly, if you want, as long as it's sandboxed and doesn't touch any private APIs.