In a couple of months or so, Mac OS 10.15 Catalina will be released, and so the next Mac transition will begin — perhaps slowly, but surely. I’m trying to put together some pieces to pre-visualise a picture of how things will go. So far I’m not really thrilled by what I’m seeing, but I’m doing my best to stay mildly optimistic.

Howard Oakley, talking about SwiftUI, observes:

The real sting comes in system requirements: the moment that you choose to use SwiftUI, your app can’t run on Mojave or earlier, it’s committed to Catalina. macOS users are generally rather slower to upgrade to the latest operating system than are iOS users. Read the comments to articles on this blog and you’ll find that there are plenty of advanced users here, with Macs perfectly capable of running Mojave, who are still running High Sierra or Sierra, and a few who are back on El Capitan or earlier. This isn’t because Mac users are stick-in-the-muds, but because many are in complex situations which have to wait for key software and other requirements to change before they can upgrade.

Assuming that half of you here were to upgrade to Catalina by the start of 2020, which could be optimistic, would I want to invest my time and effort into building apps which the other half couldn’t run until they too had upgraded?

If there were other compelling reasons to upgrade, as there are in Mojave’s much-improved APFS, maybe. But for most users, the major trade-off coming with Catalina is going to be whether its better security and speed outweigh the loss of all 32-bit software. I’m not convinced that will lure many to upgrade early. Are you?

On the hardware side, it’s worth sharing Pierre Dandumont’s observations. The original post is in French, but I did my best in translating and summarising the essential parts as follows:

• To release a Mac of this type in 2019 [the new Mac Pro] implies at least one thing: even if ARM-based Macs arrive soon, the two architectures may coexist for a while.
• Currently, Macs seem to be at a technological stalemate for a variety of reasons. First, because Intel has big problems: the architecture has not really changed since 2015 with Skylake. A 2019 MacBook Pro has more cores and higher CPU frequency than a 2016 Mac, but these are just superficial adjustments — it’s the same processor, with just a slightly better graphics part. To offer better performance, you either increase the number of CPU cores or the processor’s frequency, or both, and in all these cases you end up with increased power consumption, which is bad. Typically, Apple can’t offer a really competitive MacBook because Intel doesn’t have a really better CPU than it had in 2015.
• Macs also suffer from a GPU problem, but here it’s Apple’s fault. The company keeps using AMD GPUs that evolve little and consume a lot of energy. Nvidia makes chips that are faster and consume less, yet Apple stays with AMD. I don’t know why this is (we will surely discover the reason one day); we can assume that Nvidia is part of the problem, but the fact is that staying with AMD limits a lot of things. Even with the work that Apple does on the drivers and the custom cards that AMD makes for Apple, that’s still a problem. From what we know about Navi (RDNA, Radeon RX 5700, coming out soon), the new architecture is not the solution.
• Finally, Macs suffer from some of Intel’s choices, especially when it comes to memory support. Some Macs still use LPDDR3 or DDR4, whereas they should use LPDDR4. It’s Intel’s fault. Some developments that seem natural on the iPad do not happen on the Mac because Intel can’t (or won’t) do it. Things such as variable refresh screens, high definitions, native USB support at 10 Gb/s, etc.
• The transition to ARM would solve some of the problems. Even if we consider just the Apple A12 (from 2018), Apple could offer a faster CPU (and in some cases, noticeably faster) with the same frequency as the Skylake CPUs, with a year-over-year evolution that would bring significant gains and the integration of modern technologies (LPDDR4, etc.). All this on consumer platforms, with a much lower consumption than what Intel offers.
• The only unknown currently is the scalability of chips. An A12X consumes much less than a MacBook Pro CPU for an at least equivalent performance (and higher in many cases), but it’s a CPU with four cores (the low-power cores are negligible) and an awesome GPU with regards to power consumption, yet limited in absolute terms.

  I don’t know if the same chip with eight cores and a GPU at least doubled — to reach the level of the Radeon Polaris 15-inch MacBook Pro — would maintain the same power consumption advantages. I also don’t know whether Apple can easily provide a version with many more cores. Because an A12X has the downside of being rather big: 122 mm² in 7 nm, for four cores (eight in reality, but again in this case the low-consumption cores can be ignored) and a GPU, when a modern Core i7 has the same size in 14 nm.

  In any case, from a consumer standpoint, we can perfectly replace the components of a MacBook Pro or Air while maintaining a comparable performance and gaining autonomy significantly.

• The biggest downside of a transition to ARM architecture is software compatibility. Changing architecture involves recompiling all programs (Apple seems to be working on this) and being able to run all old programs efficiently. Switching to ARM wouldn’t allow this. The example of laptops under Windows ARM speaks volumes: if it is vaguely usable with ARM software, it is horrible to use with x86 software. In addition, switching to ARM effectively eliminates virtualisation and the ability to install Windows, which remains a thing that reassures many people and is very useful to many others.

If we put together both these software- and hardware-related concerns, we can see how the appearance of a new Mac with an ARM processor and running Mac OS 10.15 Catalina would effectively represent a point of reboot for the Mac platform. (The 12-inch retina MacBook could be an excellent candidate, by the way, and it would be an interesting reappearance). On the outside, it would be Apple’s wet dream: an extremely power-efficient Mac with decent performance, instant operation like an iOS device, ridiculously long battery life, and a tightly controlled software environment, because only new ARM-compatible apps, or older-but-updated apps would run on it.

The PowerPC-to-Intel transition was announced in mid-2005, and Macs with Intel chips started appearing in 2006. By the end of 2006, all product lines were updated with Intel chips. Software-wise, things went gently and smoothly, from what I remember. Mac OS X 10.4 Tiger shipped in April 2005, officially for the PowerPC platform only (but at the WWDC 2005 in June, in revealing the transition to Intel, Jobs said that they had been developing and testing an Intel version of Tiger internally). When the first Intel Macs were introduced, they were running Mac OS X 10.4.4, and Tiger went on until its final minor update 10.4.11 being available for PowerPC and Intel Macs.

Mac OS X 10.5 Leopard shipped in October 2007. Despite appearing more than a year and a half after the official switch to Intel, it still supported both architectures, and 10.6 Snow Leopard — the first Intel-only Mac OS X version – would appear at the end of August 2009, and it would still support PowerPC software via an internal emulator called Rosetta. The PowerPC platform was ultimately left behind with Mac OS X 10.7 Lion, introduced in July 2011. If you think about it, it was an extremely generous grace period. This way, people who purchased a new PowerPC Mac in 2005 could at least use it with sufficiently updated software until 2009, and those who purchased expensive PowerPC software could use it at least until 2011.

I have the feeling that with the Intel-to-ARM things will go differently. Assuming Apple will develop custom ARM chips that deliver optimal performance for Macs, it’s likely the hardware transition will happen like a wave, starting with more consumer-oriented Macs (like the 12-inch MacBook and the MacBook Air, maybe even a base configuration of the Mac mini), then the Pro laptops and maybe a base configuration of the iMac. But I expect an undefined period of time where we’ll have all ARM Macs except the high-end Pro machines (iMac Pro and Mac Pro), which will probably still rely on Intel processor for sheer multi-core performance.

If the hardware side of the transition happens this way, perhaps we’ll have a reasonably long grace period, software-wise, with Mac OS running in both x86 and ARM flavours. A period where, while new SwiftUI apps (and SwiftUI-updated older apps) can be properly developed, older x86 (64-bit) apps can still work and be used on Intel Macs with an updated version of Mac OS (just like PowerPC Macs that ran Leopard from 2007 to 2009).

So, keeping the speculation levels high, if we assume the first ARM-based Mac appears sometime in 2020, it’s possible this transition will take at least two years to complete from both a hardware (consumer and semi-pro) and software standpoints. This could mean at least three Mac OS versions supporting the Intel platform (10.15, released in 2019; 10.16, released in 2020; and 10.17, released in 2021), where by ‘supporting’ I mean that they can be installed on all Intel machines available now and introduced from now on, and that can run existing, traditional 64-bit Intel applications.

At the same time, those same versions of Mac OS could also run on ARM-based Macs, and be the future-facing side of the transition.

This is sort of a best-case, hopeful scenario. I hope the next transition can be carried out this smoothly, and as smoothly as the previous one. What I fear is that today’s Apple could turn out to be much more impatient, and rush things in a way that backwards compatibility isn’t going to be retained for very long. Today’s Apple seems very focused on the future-facing side of things, even more than before. In a sense, the official introduction of the Mac Pro this autumn is my one hope that the next transition can happen at a reasonable pace for all users and can be handled thoughtfully by Apple.

Addendum: The future of Mac OS, security, and new problems

As I was finally about to publish this piece, Pierre Dandumont wrote another very interesting article on his blog. Translating from the French, its title should be The future of Mac OS, security, and the problems that will emerge. Here are the essential points:

• Mac OS Catalina, the next Mac OS, will bring a lot of changes under the hood, and for Pierre (someone who likes to tinker and hack), things look pretty annoying.
• Catalina completely drops support for 32-bit apps, and this poses two problems: first, obviously, all your 32-bit-only apps will no longer work. It may be an old application, like iPhoto, or even EyeTV. Second, and perhaps a bit less obvious, all those applications that rely on 32-bit software will no longer work either, or only partially work. Pierre makes the example of apps that still use QuickTime 7 frameworks to decode video or audio. “In fact, a lot of old codecs (and old software) depend heavily on QuickTime 7, unfortunately”, he writes.
• Catalina also drops support for HFS (aka “Mac OS Standard”), so if you, like me and Pierre, still need to access old read-only media like CD-ROMs, it’s a bit of a hindrance (my workaround here is to use an older Mac, of course). Support for AFP file sharing should also be dropped in Catalina (according to Pierre it still works for now).
• The most annoying changes are related to security. Pierre emphasises a key distinction: “Let me be clear: these are more annoying for an advanced user who likes to hack. For a normal daily use of macOS, such changes shouldn’t be a nuisance and will actually improve security”. And then he adds: “But it makes macOS closer and closer to iOS, and from my point of view it’s not necessarily the macOS I want”. And oh yes, I feel the same.
• Changes in Gatekeeper: in early versions, when it came to allow software to run on your machine, it was possible to choose between unsigned apps (no protection), signed apps, or Mac App Store apps. With Yosemite, the first option got disabled periodically (and automatically). With Sierra, it was hidden. In a future version of Mac OS, it is going to disappear entirely. The wording [see the screenshot on Pierre’s blog, taken from the presentation Advances in macOS Security (701)] indicates that it should still be possible to enable the option to launch unsigned applications, “but that by default macOS will prevent it… like iOS”.

  Pierre then observes: “This is frankly a problem: it will become impossible to develop (or compile) a program without paying [an Apple developer’s fee] and with anything other than Xcode (as I’m told, Xcode signs programs for the user), and many open (and not open) source applications will not launch anymore. Sure, this is clearly a security advancement, but it’s not flawless: there is signed malware, you know”.

• Another annoying thing is that in Mac OS Catalina, the system will be read-only. “Catalina uses APFS to separate a data volume from the volume containing the system, in a completely transparent way. The volume containing the system will be read-only, which will prevent modification of the OS. Again, this is interesting for security, but not for all the different macOS hacks”. Pierre also notes that, for now, disabling the SIP (System Integrity Protection) removes this function, but Apple’s presentation (What’s New in Apple Filesystems — 710) is very clear on this point: it will be impossible to do it permanently. Disabling the SIP will mount the write partition until the next restart. And that’s it. It will then go back to being read-only.
• Finally, another change Pierre finds potentially problematic is related to the new driver format (System Extensions and DriverKit — 702). He writes: “Specifically, Apple is pushing a new generation of drivers for certain types of devices: HID devices (in general), USB devices, serial devices (more specifically USB-to-serial adapters), and everything network-related. I’m simplifying a bit, but basically, if you have a device that communicates via serial with a built-in controller (for example an Arduino), a Thunderbolt or USB network card or a USB device like a TV card, the drivers will have to be rewritten. Not in the very short term, since Catalina is still going to support kexts, but in the short term nonetheless, as Catalina’s successor will leave them behind for devices that fall into these categories.”

  Pierre observes that “Quite frankly, seeing how keeping track and maintaining drivers is often pretty bad under macOS when a new version changes little things — if you have a Wacom tablet, you’ll understand — I think it’s going to be a nightmare for the users. And I see only one solution for now: trying to use only devices with macOS native drivers. It’s not that easy, unfortunately: in the case of serial adapters, for example, Apple natively supports only FTDI models, and they are expensive. Same thing for network cards: hopefully, manufacturers will follow suit, but it’s not a given.”

If we go back to the now-trite analogy Steve Jobs made when he talked about the Post-PC era, about traditional computers as trucks, and mobile devices as cars, I think this could keep making sense, but only if trucks are allowed to continue carrying out their truck duties, so to speak. Putting all these pieces together is a tedious task, but when it comes to the future of Mac OS and the Mac platform, the picture I’m starting to make out here is of a severely locked-down, exceedingly streamlined system. And if you start transforming trucks to make them behave more like big cars, then what’s the point?

Yes, Mac OS is not the bulletproof platform it once was, security-wise, but it’s still far more secure as it is today than most of what’s out there. And while aiming for a bulletproof system is a good thing nowadays, I believe it shouldn’t be done at the expense of the inherent and historical flexibility of such system. Why have UNIX underpinnings to then utterly dumb down whatever is built over them? And it also shouldn’t be done at the expense of third-party developers of such platform, who are expected to jump through increasingly narrow hoops to create software that works as it should and simultaneously complies with Apple’s progressively stifling demands. This is the part that keeps me apprehensive as this next excruciating transition approaches.