Could Apple have improved Objective-C instead of making Swift?

Recorded June 18th 2020 – watch the full episode on YouTube.

Many felt Objective-C had a bright future ahead of it, and was going to keep on improving. There must have been a point where you thought you could somehow keep improving Objective-C rather than build a new language – was that even possible?

Chris Lattner: Oh yes, you could definitely make Objective-C better. Here’s a little bit of a history lesson or story.

I joined Apple in 2005, which was right around the time when Objective-C garbage collection for the Mac had just been announced. This was right when Objective-C 2.0 was halfway through its development, so properties and things like that were being finalized. There was a lot of discussion of trying to breathe new life into Objective-C – let's try to get it to be more modern and easier to program, with less boilerplate; all of these kinds of things.

“We always want to improve Objective-C, but on the other hand there was a really interesting set of cultural divides because a lot of the people that had been using Objective-C for a long time didn't want it to fundamentally change."

There was a lot of excitement and enthusiasm to improve Objective-C. One of the big features, which was one of the first things I worked on in this space, was the blocks language feature, which is actually a C feature but it was really made to make Grand Central Dispatch work well, along with some of the Apple APIs that were really important for Objective-C. And so there was a long interest in improving Objective-C because it's so important.

Now when Swift started in 2010, the situation was similar, but different. We always want to improve Objective-C, but on the other hand there was a really interesting set of cultural divides because a lot of the people that had been using Objective-C for a long time didn't want it to fundamentally change.

One of the most funny examples of this in hindsight maybe was 2013-ish, when we introduced this feature called Objective-C literals. Instead of saying in [NSArray arrayWithBlahBlahBlah], you can say @[someStuff]. It's a huge amount of boiler plate, and you can subscript into an array or into a dictionary, an NSArray or an NSDictionary, using subscripts instead of using a method.

That's just an example of on the one hand it seems like a very small thing, and it dramatically improves code across the board in terms of both performance in some cases, but also in terms of the elegance and the readability, but this was highly controversial with the community.

"When Swift was coming up, there was no doubt that we could make Objective-C better, and I think one of the biggest aspects of push back on the whole Swift development among the executive team was, well, Swift is risky. This could fragment the community."

All these things really change how people think about the language. And, as you know, people are very particular about their view of what a thing is supposed to be. So when Swift was coming up, there was no doubt that we could make Objective-C better, and I think one of the biggest aspects of push back on the whole Swift development among the executive team was, well, Swift is risky. This could fragment the community. It might not be any good. You all seem well-intentioned, but this is actually hard – look at all the languages that have come and failed before you.

And they were right. And so a lot of the strategic discussion early on was, fine, you're going to do something, but why not improve Objective-C? If Objective-C needs a little bit more type safety, add some more types. Okay, well, Objective-C garbage collection didn't work out, fine. How else can we solve this problem?

That led to a large number of improvements to Objective-C including ARC. ARC came to Objective-C as part of Swift driving it, because we needed safety and memory management and we wanted to be able to talk to Objective-C frameworks, literals modules in Clang. There's a bunch of features that all made their way into Clang in Objective-C because of Swift. And if anything, the most amusing part of that time was we, on the compiling and language team, were being accused of taking Objective-C on a random walk. Why literals? Why modules? Why ARC? Why this stuff? Why not do the syntactic sugar thing or some other thing?

"The most amusing part of that time was we, on the compiling and language team, were being accused of taking Objective-C on a random walk. Why literals? Why modules? Why ARC? Why this stuff?"

There was a reason: it was to make it so that when Swift came on the scene that we could do interoperability. And so with literals, for example, it was a small feature to just nudge the community closer to thinking about things in the way that Swift would ultimately feel.

Paul Hudson: It's interesting that you forget how interesting, or how quirky, things were. Before literals, we used to create dictionaries by writing objects then keys. It was completely backwards, but you get used to it, almost like Stockholm Syndrome; it just becomes a normal thing for you. And then literals say hey, let's put the key before the value and it makes more sense and it's obvious in retrospect.

Sponsor Hacking with Swift and reach the world's largest Swift community!