They did it before in the PowerPC to Intel change. Migration was helped by:
- Fat binaries (Mach-O binaries can support multiple platforms).
- A PowerPC emulator for applications that are not ported.
I think they are even better positioned for an architecture change than during PowerPC -> Intel. They now have the app store where they can impose certain requirements (like supporting two architectures). And they now have their own compiler backend, which opens the possibility of supporting architecture-independent IR (along the lines of bitcode).
There was also the 68K transition to PowerPC a long time ago. And more recently, the 32-bit to 64-bit transition.
And for a lot of the older Mac developers, iOS was kind of like another migration. And iOS has gone from armv6 to armv7 to arm64, plus the x86 and x86-64 simulator targets. Not to mention that there is now an LLVM Bitcode requirement for Apple TV and watchOS.
Apple and its developer community has a lot of experience with architecture migration. Each transition built on the experience of the previous and got smoother each time. Apple has been very good insulating their frameworks and tools from the architecture, and the Apple developer community has gotten very good at following Apple's guidelines to minimize disruption since there have been so many of these transitions.
Forgot to add that I think the real thing keeping Mac on Intel is the bullet point that Intel Macs can install Windows.
In the PowerPC days, Apple had trouble convincing people to switch to Mac because Windows being so dominant, everybody was afraid they might need Windows for something and that would make a PowerPC Mac an expensive mistake. The Intel switch alleviated many fears because in the worst case and Mac OS didn't work out, they could just install Windows. Bootcamp and virtualization provided additional options.
Apple has always seen Mac and iOS as different markets. Mac is still a small market compared to Windows. They are still trying to grow which means still trying to convince Windows users to switch and the safety net of Intel is still useful. (Windows RT isn't a realistic option.) I personally haven't seen iPhone users wishing for a big laptop or desktop that runs their same apps.
Windows was already on ARM with Windows RT, for which I believe Microsoft did the work of porting UEFI and standardised bridge (PCI) technologies to ARM.
While speculating: Apple could conspire with Microsoft to standardise these technologies together to lock up their ecosystems against the Linux / Android monster :-)
The hard part for Microsoft is not the porting of Windows to ARM. The hard part has been and continues to be convincing existing Windows developers to port their apps to UWP.
The reason Windows on Mac is useful to people is because people have may programs that do not have acceptable equivalents on Mac OS. These apps are usually legacy programs that probably fill special niches, and the cost of "modernizing" is usually not justified. This effort would be required to port these apps to Windows ARM, which last time around also required porting to UWP which Microsoft is still pushing, but not easy to actually do for a lot of code bases.
A new Microsoft irony kicks in here is that if they are successful in convincing the huge Windows ecosystem to migrate to UWP away from Win32, et. al, they may actually kill their lock-in advantage. A serious rewrite at this stage may also invite Mac, Linux, iOS, Android ports. In this case, Apple no longer needs to care about Intel Windows and this bullet point becomes less compelling and maybe they could reconsider.
You can use the new Centennial technology to wrap an old Win32 application as an UWP Store app. If the app was made with .NET it might even run on ARM.
I think this market is getting smaller and smaller year over year (I no data to back this up unfortunately). They could honestly build a MacBook with ARM in the near future while keeping the pros around with x86 for a while longer. They could reduce the price by hundreds of dollars switching off of Intel processors which would undercut a huge amount of competition.
The sole reason I can use a Mac for my paid work is, that I can run Windows and x86-Linux VMs, as I need to run Intel based software on those operation systems.
Well yes and no. I ran Windows in VirtualPC (I think) on a PowerPC MBP for a while. Pretty slow but good enough for Outlook, Word etc that I needed the compatibility for.
Say, does anyone know who owns the IP for FX!32 nowadays?
Putting aside the fact that Windows RT was a commercial failure and discontinued which makes it weird to push yet another effort that this would be anything more than some niche demo thing like Raspberry Pi support, Windows in of itself is not what concerned potential Mac switchers.
People are concerned that they have some mission-critical, unreplaceable app that only runs on Windows, that has no acceptable Mac analog (doesn't exist, doesn't have feature parity, data formats are incompatible).
Windows on ARM doesn't solve anything because almost no Windows apps that people care about were ever ported to Windows RT. (It was probably more likely there was a Mac port.)
Not to mention it's been a long time since Intel really stopped the show with a CPU release. That was not the case way back when Apple switched to Intel. Granted I remember the RISC vs CISC wars with nostalgia.
And Apple could transition even easier now thanks to it controlling most Mac apps through the Mac Store. All Apple needs to do is announce they're going to enforce ARM support in the Mac Store a year or two before doing it, and that's it.
Also, isn't Apple already encouraging the use of some intermediary bitcode for iOS (and macOS?) apps? Wouldn't that already made apps architecture-agnostic?
You're not being serious are you? MAS holds such an insignificant role in Mac App development that any requirements it sets around the transition would weaken its cause.
Also mo, bitcode would not be able to be used to facilitate an Intel to ARM transition - bitcode is still fairly processor-specific. Bitcode is more for being able to adapt to minor changes in instructions in the same arch
>You're not being serious are you? MAS holds such an insignificant role in Mac App development that any requirements it sets around the transition would weaken its cause.
Negligible? If you exclude Adobe and MS, most apps people use are available through the Mac App store. And more can be made available if Apple pushes more for it.
With the restrictions it currently imposes (sandboxing), I think we would see a significant withdrawal from the Mac platform. Many developers would stop making apps (especially those that are for power users, which when turn more devs away from macs). I doubt Adobe Creative Suite (Photoshop) would be technically possible with sandboxing, so Adobe would withdraw from Mac. MS Office would probably be gone as well. Parallels and other virtualisation software would find it extreme difficult to run.
Valve would have to pull Steam because you can be as sure as hell they aren't going to give Apple a 30% cut of Steam sales. There goes Skype as well.
Without special deals with lots of developers, I doubt we would see many more apps on the App Store and instead we'll see the Mac be an unsuitable platform for many/most people. It would turn into a glorified Chromebook.
In this hypothetical situation Microsoft doesnt make the stupid move of requiring all apps go through their store which imposes its own limitations (like sandboxing).
Mind you, it would be a completely insane move for Apple (or Microsoft) and I can't see them doing this any time soon. It would be absolute suicide.
How is Adobe going to do it when Windows follows the same footsteps than Mac OS X?
The only way will be the store, or why do you think Microsoft is making it easy to port Win32/WPF (legacy) applications to the store model?
When the applications that matter like Adobe are on the store, and Apple has proven the "my way or the highway" works, they will slowly disable the "legacy" model.
I have been through enough computing changes to believe this will indeed happen.
> thanks to it controlling most Mac apps through the Mac Store
Serious question: Do you have any evidence to support that claim?
I could well be in the minority, but I don't publish through the Mac app store and I don't know anyone else who publishes exclusively through the Mac app store (except Apple).
Well you'll have to if Apple decides that ARM MacBooks will only be able to install apps from the Mac app store - they already have a precedent in iOS and precedent of pushing developers to do things their way.
iOS had a very different history with developers. The desktop isn't the mobile space.
Desktop developers have their own solutions in place and have for a long time. You'd be forcing them to give up a ton, in exchange for nothing of value. I'd expect many would just stop developing applications at all instead of comply with store requirements as they stand right now.
That's not to say those problems couldn't be resolved in the future.
All nice and good, and where would those developers go, considering that both Google and Microsoft are following similar sandbox approaches?
Those developers can choose between stay in business or go broke, because I doubt GNU/Linux or *BSD users would pay for desktop software as their current Mac OS X customers.
I don't think Adobe and Microsoft, the two biggest third party Mac developers, care what Apple imposes on the Mac App Store.
And they certainly won't be too happy about having to rewrite, again, their applications (I think Office for Mac is not yet fully 64bits, but I could be wrong, haven't checked in a while.)
> I don't think Adobe and Microsoft, the two biggest third party Mac developers, care what Apple imposes on the Mac App Store.
Microsoft must care somewhat because they have spent a lot of time fully sandboxing Office 2016. Since OneNote is already available in the MAS [1], I reckon Microsoft will eventually add the remaining Office apps at some point in the future.
> I think Office for Mac is not yet fully 64-bits
Microsoft released the first 64-bit version of Office 2016 for Mac (15.25.0) last month [2] [3]
As the article says, bear in mind that a lot of those applications are now on iOS. They seem to think a shift to ARM might also mean a shift to iOS, with the iPad Pro acting as the bridge device to encourage software makers to provide compatibility (which seems to be working). One possibility might be Apple segmenting its laptop range, with the MacBook being shipped with iOS, and the MBP with OSX.
They say in the article that the entire PC market shipped fewer units than the iPhone alone, one quarter last year. There's certainly a risk that the consumer end of the laptop/desktop market gets dragged in behind as an 'additional device' for the mobile operating systems, bringing with it its walled gardens and concept of 'devices as utilities' rather than generic computing platforms.
I suspect as strange as it might seem to us a lot of people would jump on a laptop with the managed qualities of a utility device, especially if it meant they could get a Macbook for $150 less.
The one think keeping me so far from buying an iPad Pro and probably will cause me to buy a macbook next is the software limitations of iOS which prevent it from being a generic computer. So if Apple moves to ARM, it probably would be rather some more macOS style operation system. But that switch would be not really difficult as iOS and macOS largely share the same codebase.
The history of Mac OS X on Intel (the Marklar project) is very interesting. Most of the work was done by a single dev (ex-director who demoted himself to engineer) who wanted to spend more time with his family. So he worked from home.
Changing to Intel are kinda easy, because applications (think Photoshop, etc) already has optimized code for x86 (think SSE/AVX and such, which are hand-coded). While undoubtedly many also has NEON nowadays, I still think it is on different scale.
One other factor is the degree to which hand-optimized code in general has been going away: Apple heavily encouraged people to use system frameworks like CoreImage, CoreVideo, etc. both to ease the transition and to take advantage of their significant optimizations, and that appears to have been followed by many developers. Adobe presumably still has a whopping case of Not-Invented-Here but I'd be surprised if a significant number of apps couldn't be ported with very modest changes.
