SwiftUI and Catalyst: Apple executes its invisible transition strategy

Apple's playing a long game, and it's so slow you might not even notice.

paroject catalyst mac

Today's Best Tech Deals

Picked by Macworld's Editors

Top Deals On Great Products

Picked by Techconnect's Editors

Last week in San Jose I found myself considering something John Gruber wrote for Macworld at the beginning of this decade—about how Apple’s product design doesn’t happen in short bursts, contrary to popular belief. It is a marathon, not a sprint. And no other company in the tech industry has the track record at it that Apple has.

“It’s a slow and steady process of continuous iterative improvement—so slow, in fact, that the process is easy to overlook if you’re observing it in real time,” Gruber wrote. “Only in hindsight is it obvious just how remarkable Apple’s platform development process is.”

This is still true nine years later. And we’re right in the middle of it. It’s happening all around us—Apple continues playing its long game, dragging change-averse people through periods of transition so slowly that they often don’t even notice what’s happening until it’s all said and done.

The privilege of repeating it

Apple’s had more than its share of product transitions over the years. Macs have transitioned from Motorola 680x0 processors to PowerPC chips to Intel chips, and are rumored to be on the precipice of moving to Apple-designed ARM chips. On the software side, Apple moved from classic Mac OS to Mac OS X, then built an additional operating system—iOS—on the foundations of OS X.

For users, those transitions were relatively smooth. Apple engineered emulation technology into Mac OS during both chip transitions, so old software would run transparently on new hardware. (And in both cases, the new chips were so much faster than the old ones that most of the slowness of emulation or code translation came out in the wash.)

The Classic Mac OS to Mac OS X transition was bumpier, but even there, Apple gave everyone an awful lot of time—OS 9 didn’t get officially declared dead until Mac OS X 10.2 Jaguar was about to arrive. And even then, Jaguar ran Classic Mac OS apps in a special compatibility environment. It wasn’t seamless, but it worked—and by that point most apps had updated to OS X.

The App of Theseus

The ride was bumpier for software developers, of course. The switch from the classic Mac OS to OS X was enabled by Apple creating something called Carbon, which was a set of tools that let apps written for the old Mac OS run natively on the new one. But Carbon was a transitional framework, a bridge to OS X for Mac developers. OS X’s native system (brought over from NextStep) was called Cocoa.

Classic Mac developers brought their apps over to OS X using Carbon, but it became clear over time that Cocoa was the future—and at one decisive moment, Apple went back on a previous promise and announced that there would never be 64-bit Carbon apps. The writing was on the wall: the future was Cocoa. And in fact, with the release of Mac OS Catalina this fall, the last surviving bits of Carbon will be swept away.

And yet Mac apps from the classic era survive. Like the Ship of Theseus, they have been updated so many times that little if anything of the original remains. This is one way Apple manages its magic trick of the slow, invisible transition—developers adapt their apps gradually over time, the users keep on using the apps, and the wheels turn.

I use BBEdit by Bare Bones Software every day on my Mac. It was originally written for the classic Mac OS, survived the PowerPC transition (presumably with a bunch of behind-the-scenes changes to its development environment), then moved to Mac OS X with Carbon and began cycling on through into Cocoa in order to take advantage of new OS features and be 64-bit capable. There is little if anything left of BBEdit 1.0, but BBEdit endures as a Mac app.

Slow, but relentless

Swift UI Screen Apple

SwiftUI in action.

This brings us to today, when Apple is making multiple transitions at once. Catalyst, which arrives this fall, will allow developers who are well-versed in the vagaries of writing iOS apps to use those skills to write Mac apps. This will most commonly take the form of bringing iPad apps to the Mac, with additions to make them feel more like native Mac apps, but it’s more than that—it provides iOS developers with a familiar set of tools and access to an entirely new platform, and it makes the target for professional apps across Apple’s platforms broader by including both the iPad and the Mac.

iOS apps are currently built to run on devices running Apple-designed ARM processors, and if the rumors are true, that’s another transition waiting to happen. But given that all Mac and iOS developers are already using Apple’s Xcode tools to develop their apps, I suspect that the pieces have been put in place for a fairly simple transition to a new processor architecture.

And then there’s SwiftUI, which may be a harder concept for regular users to grasp, but it’s a huge step on Apple’s part. This is Apple’s ultimate long game—an entirely new way to design and build apps across all of Apple’s platforms, based on the Swift language (introduced five years ago as yet another part of Apple’s long game).

In the shorter term, iOS app developers will be able to reach to the Mac via Catalyst. But in the longer term, Apple is creating a new, unified development approach to all of Apple’s devices, based in Swift and SwiftUI. Viewed from this perspective, Catalyst feels more like a transitional technology than the future of Apple’s platforms.

But we’re talking about the long game here. Transitional technologies are all a part of the long game. Catalyst will bring those apps to the Mac. iOS and Mac developers will pick up Swift and SwiftUI. Mac apps can integrate iOS stuff via Catalyst. iOS apps can integrate Mac stuff for use on the Mac. And all developers can begin experimenting with SwiftUI, building new interfaces and replacing old ones in a gradual process.

And then we’ll turn around sometime in the 2020s and realize that all of this talk of UIKit and AppKit and Catalyst is behind us, and that our apps are written in Swift with interfaces created using SwiftUI. It will have all changed due to Apple’s slow and steady pace of iterative, continuous improvement. The long game never stops, and it can be hard to see that you’re even in it.

Note: When you purchase something after clicking links in our articles, we may earn a small commission. Read our affiliate link policy for more details.
Shop Tech Products at Amazon