https://developer.apple.com/library/content/releasenotes/Gen...
https://developer.apple.com/library/content/releasenotes/Gen...
- 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).
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.
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 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.
(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.)
It wouldn't work for side loading unless doing it via Visual Studio.
Say, does anyone know who owns the IP for FX!32 nowadays?
Remember they were called Powerbooks back then? I miss that name.
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.)
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
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.
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.
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?
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.
Adobe has managed to get thousands from users without any 'help' from Microsoft.
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.
That says something
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).
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.
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.
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.)
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...
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 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.
https://www.engadget.com/2012/06/10/how-marklar-os-x-on-inte...