Hacker News new | ask | show | jobs
by microtonal 3568 days ago
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).

3 comments

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.

> Intel Macs can install Windows

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.

There's legacy software, and there's also games.

(But I'll freely admit that me being able to run games at sub-30fps on my MacBook Air is probably not Apple's intention.)

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.
Yes, but only if distributed via the store, due to AOT compilation.

It wouldn't work for side loading unless doing it via Visual Studio.

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?

Yeah, it was probably Virtual PC.

Remember they were called Powerbooks back then? I miss that name.

On the other hand there are rumours that Microsoft is already working on Windows 10 for ARM, so this might be a moot point.
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.)

Well, what if Windows on ARM could do a decent job of x86 emulation?
What would then accomplish when you have fast chips that don't need emulation RIGHT THERE?
Windows 10 IoT Core is already running on ARM and it runs UWP apps: https://developer.microsoft.com/en-us/windows/iot/explore/de...
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?

> controlling most Mac apps through the Mac Store

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.

Hypothetically, how do you think the market would respond if Apple said that apps could only be sold through the store?
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.

Except that all the real desktop alternatives are adopting the same sandbox models.

So, just like any technology adoption that comes from above those developers would just shut up and follow along.

Or do you think they would earn any money selling to GNU/Linux users?

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.

Considering that the only app I use on my mac from the AppStore is xCode, I'd say it would respond very negatively.
If you use XCode you are already not the typical consumer.
True, but last time I checked Xcode is one of the most popular apps in the Mac App Store.

That says something

> 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]

[1] https://itunes.apple.com/gb/app/microsoft-onenote/id78480155...

[2] http://macadmins.software/

[3] https://support.microsoft.com/en-us/kb/3179163

Now let's do all the other PaaS vendors. Steam, Battle.net, Origin, Adobe CC, SmithMicro... I'm sure I'm missing plenty more.
Steam and Adobe, yes., but most Mac users could not care less for Battle.net, Origin, or SmithMicro.

In fact, Battle.net, Origin, or SmithMicro would care more for Mac to do a rewrite than Apple would care to lose them.

Besides, Apple changed to Intel and didn't give much of a care about MS or Adobe apps having to be rewritten.

They would eventually need to do the same dance on Android, ChromeOS and Windows.