Transcript of Craig Federighi and John Gruber on The Talk Show Episode 139

Craig Federighi: I always end up seeking back to figure out what part I missed where the podcast started, and then I realize it just starts.

John Gruber: That is how it goes, Craig.

Federighi: It is.

Gruber: So, this is a great thrill for me being able to speak to you. Craig Federighi, senior vice president of software engineering at — what’s the company?

Federighi: Apple.

Gruber: Apple, Apple.

Federighi: Yes, yes.

Gruber: And we are talking on the occasion of the open sourcing of Swift, which went live last week. What day was it?

Federighi: It was last Thursday, wasn’t it? It’s been huge. Yeah, it was incredibly exciting for us.

Gruber: So as we speak it’s about a week later. How do you think this first week of Swift as an open source project has gone?

Federighi: Really, really well. I mean, the level of activity on Github is off the charts. We’ve had really high aspirations for Swift from the beginning. But at every step it’s been pretty amazing for us how much bigger it’s gone than we could have ever hoped. And I think already on Github we’re a more active project than I think all the other languages that are on Github, which is just incredible for the first week. I think over 60,000 people have taken a clone of the project. So it’s pretty amazing and the team is just ecstatic over the whole thing.

Gruber: There are different ways for a big company, especially a big company, to do an “open source project”. They’re sort of like, yes, technically it’s open source, but it’s really just a zip file with an open source license and there it goes. “Have at it.” And then there’s the actively-engaging-in-a-community manner ...

Federighi: Yes.

Gruber: ... with the outer world. So when you guys announced it at WWDC that Swift would be open source, I think there were some skeptics who thought maybe it’s going to be, well, technically it’s open source and there it is. But this is really like full throttle, fully engaged with the world outside Cupertino.

Federighi: Yeah. I guess it’s funny. There will always be skeptics, but anyone who has been watching our team in the context of the LLVM world, Clang, LLDB — and our Webkit team — would see how much developing in the open is in the spirit of those teams. And so, the Swift team has been among the most engaged among our development community of any group at Apple, even prior to open sourcing, in terms of from the first launch or announcement of Swift 1 at WWDC and how much they were engaging with the feedback that was coming in and modifying the language right up to 1.0 and then beyond. And this is really an extension of the only way they really have ever wanted to work. And so, yeah, they are very excited to be working completely in the open. And it really is the case where all the features in Swift that will be announced officially to the world at our next developer conference, you can sort of see them unfold before your eyes in the time leading up to that as they are working on them in the open on Github.

Gruber: Yeah, just like everything else Apple does.

Federighi: [Laughing] Very, very similar to everything else we do.

Gruber: The thing to me that’s most telling — and I know that Github makes it easy to track all these changes and see how many people are involved — but to me, if you just want to get a quick look at just how much this is a collaboration between the Swift team at Apple and the outside world, it’s the Swift Evolution mailing list ...

Federighi: Mmm-hmm

Gruber: ... where, you know, you guys have been upfront about this right from Swift 1.0 in 2014, that this is not a finished language. You didn’t go and finish a language and say “Here it is. Have at it.”

Federighi: Right, right.

Gruber: It’s: “We’re still working on this. A lot of what we’re going to work on is: Tell us what you need. And here on the mailing list are people actively engaging and employees from Apple — Chris Lattner and people on his team — are fully engaging with these ideas and proposals that are coming from outside the company. Already, one week into it being an open source project.

Federighi: Oh yeah. I mean, I think our team is a really seasoned team in the world of developing languages and we know that a language really can’t be developed in a vacuum. It is a product of how people use it and the problems that people are trying to solve, and so we knew from the outset with Swift 1.0 that ... the first step is you have to crystallize your basic ideas and have a starting point. But we knew we needed feedback then to work toward the language that ultimately Swift has become and will become in the future. But that we needed to have this open dialog, and open sourcing is, as you say, just really accelerating and deepening the kind of feedback that we’re getting. And so, it’s really energizing for us. And I think it’s really exciting for a lot of our developers in our community as well, to be a part of it.

Gruber: What are the other reasons to go open source with a new programming language?

Federighi: Well, you know, when we just talked about it briefly at WWDC, I think we laid out the big ones, which are for us: Swift is, we think, the primary programming language that developers should be taught programming in, actually. I mean, if you’re going to learn computer science, Swift is a fantastic learning language. And if you’re a developer who is going to invest a huge part of your career in mastering Swift and developing code in Swift, you’re going to want the ability to use that code in every context possible. You’re going to want to use your skill in that language in all the environments in which you have to work to do your job. So whether you’re scripting your build system or writing web services — and of course writing your mobile applications — we want to make sure that you can invest in Swift in that way and know that it’s going to be available to you everywhere. And so, we saw open sourcing as a critical element to make Swift reach its potential to be the language, the major language for the next 20 years of programming in our industry.

Gruber: It’s a really ambitious goal.

Federighi: It is. It is. But ... you know, at every point along the way — because this has been our vision from before we first unleashed Swift on the world — but at every step, actually, the reaction has really outdone our expectations. So maybe our goal isn’t so outlandish.

Gruber: I would say that for education purposes, it really has to be open source because there really is no way that a language is going to take root as a teaching language if it is proprietary to an Apple platform, or any other vendor’s platform.

Federighi: Right. You know, we had a lot of universities who would teach a specialized mobile programming course or an iOS programming course. And in that context, of course, they teach Swift. And Stanford has an outstanding course that is on iTunes U about programming in Swift to program on iOS. But when it comes to bringing it into the core curriculum that every student at the university has to take to, let’s say, learn computer science, making it open source, having it available to every student on whatever platform they’re going to use to do their work is — we think ultimately is a huge enabler. And so many of the people that we talk to, the professors, wanted to use the language in these ways, but they needed it to be open source for this to happen. And so we’re really excited to follow through with them on this.

Gruber: Why not open source it? What are downsides that were debated before you made the decision to go open source with it?

Federighi: You know, there really weren’t. We, of course, talked it over at length. We had a tough time coming up with a significant reason not to do it. It was more a “when” question. You know, is it now? And we knew after 1.0, that we weren’t quite there, that we wanted to get that first round of feedback, begin to stabilize the definition of the language. But as we got close to WWDC this last year, we realized we were where we needed to be to take a step that we knew was going to happen. It was going to be this year or the following year, and we realized that we were where we needed to be. And so we moved ahead, and the hunger out there was so great that we thought, let’s do it now.

But the downsides are really limited. And I mean, I think it’s inevitable but positive that Swift will be used in all kinds of contexts outside of Apple. That’s kind of the point. So, that’s fine. It’s clear that we’re going to get a lot of people wanting to do things with the language that aren’t directly related to Apple’s line of business, and that’s OK. ... So there weren’t a lot of downsides, and we think that the upsides are tremendous.

Gruber: One of the areas ... where I see so much excitement about it already in terms of Swift being cross-platform, is the use of Swift on servers.

Federighi: Yes.

Gruber: And, you know, a lot of that is certainly going to Linux, and you guys have already done the port to Linux.

Federighi: That’s right.

Gruber: That’s an area where I feel like ... I have no idea... I feel like it’s going to be used, but it’s like it’s so early that we don’t know where that’s going to be. But do you see that happening? That it’s going to be used for a lot of server-based development that’s really outside Apple’s platforms?

Federighi: Oh, totally. I mean, from really the outset. IBM, for instance, jumped all over Swift for building their mobile apps, and almost immediately they were coming back to us with, “We really want to use this on the server. How can we get this on the server?”

And, of course, within Apple there’s a tremendous passion for Swift. And our own iCloud team has been completely champing at the bit to be able to apply it in many, many of the things they do. So, I think it’s going to be one of the first break-out uses of Swift. And of course these days there are so many mobile applications that are part mobile app, part server code. And in a lot of cases, at the very least you want to share your knowledge, but very often you want to share parts of code, parts of your model layer, some of your utility libraries, and having Swift enabling you to do that is going to be huge for a lot of our community.

Gruber: Yeah, I can definitely see that. That to me is one of the sort of building-for-the-future aspects of Swift versus, say, Objective-C, which has roots from 20 or even 30 years ago ...

Federighi: Yeah.

Gruber: ... and the fact that the cloud or whatever you want to call it — the client software running on a device talking to servers somewhere off on the Internet is part of, I would say, almost certainly the overwhelming majority of apps being written for these platforms today. That having [the same] language at both ends of the communication is huge.

Federighi: Well, exactly. Exactly. ... I think for a lot of developers prior to Swift, they probably were using Objective-C. If they had high-performance code, they had to write part of Objective-C as C, and so they were dropping down into C to do some of the more optimized work which can be almost another language. There’s a real continuum there within the environment. They might have been using a scripting language for part of what they do. And then they might be using a server-side language, like Java. And Swift is uniquely capable of spanning from really easy and natural kind of scripting expressive uses. It’s a great application programming language. But it was also designed to be a great systems language and be really fast so you can do C kind of high-performance work without compromises in Swift. And then it’s going to work in the cloud as well. So, I think it’s going to really unify the environment for a lot of developers.

Gruber: How would describe a systems language? This is right from the Swift Programming Language book, it says: Swift is intended to be “the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language. It’s designed to scale from ‘hello world’ to an entire operating system.” What is a systems programming language?

Federighi: Well, there’s some low-level bits and some matters of spirit, I think. In terms of low-level bits, Swift has a very predictable memory management model, a very contained runtime. If you look at traditional scripting languages or languages like Java, they run garbage collectors; you really can’t control memory. In a way Swift builds on our ARC technology that first came to Objective-C to provide really high-performance and really predictable and manageable memory management, which means that if you wanted to write everything from an operating system kernel to a high-performance graphics library, you could do that without inheriting a huge per process memory footprint overhead. And you see that when you see how Apple’s OS and apps are able to run in lower memory footprint, and we’re able to ship with different memory footprints than some of our competitors who use languages that don’t have this characteristic.

But Swift is also designed that when it can be fast, it’s as fast as can be. So we aren’t taking the overhead of dynamic dispatch for every call, and yet we can provide dynamism when needed. We can optimize. If you use an array in Swift, we can be every bit as optimal and do auto-vectorization and parallelization in ways that you would expect from optimized C code, but are very hard to do if you were trying to optimize Ruby or Python, or even in Objective-C with NSArray on top of the foundation classes. And so, you can go very, very low-level and get very predictable and peak performance out of your hardware.

Gruber: Let’s compare it to Objective-C. Objective-C, there are so many great things we can say about it. It’s served Apple so incredibly well. It still will for the foreseeable future in so many ways ...

Federighi: Yeah.

Gruber: ... but there’s this big “but” which is that sometimes you need to ... drop down to C or C++ and now you’re losing all of the stuff that we love about Objective-C because you need to drop down temporarily for performance reasons. And with Swift you don’t need to do that. You can write high-performance code right in Swift.

Federighi: Yeah, that’s right. I think when we first introduced Swift, we said we were imagining a world where we took what we loved about Objective-C without carrying forward the baggage of C. But what that meant is that Swift had to replace C in its role in Objective-C programming. And it does that really well while bringing all of these higher levels of abstraction and higher productivity programming techniques to writing that kind of high performance systems code, but also so great for app code.

Gruber: So, one thing that Swift is not — and I think we already covered this — but it’s not Objective-C with prettier or better syntax.

Federighi: Right.

Gruber: And it’s the syntax of Objective-C that people find off-putting, at least at first. And I know that that’s a debate that people who use Objective-C and who have used it for decades — it’s a never-ending argument. But ...

Federighi: Yup.

Gruber: ... but at least at first, even if you really, really love Objective-C, I feel like you can’t avoid the fact that at first it looks weird.

Federighi: Uh-huh. I’ll admit, I’m an Objective-C lover. There were plenty of good debates internally about, you know, should we have a Smalltalk-inspired syntax. Should we stick with something like Objective-C? But in the end, it can go either way. And what we were able to retain in Swift are the sort of literate nature of APIs that Objective-C enabled; the readability of code with the labeled arguments. And we brought all of that to Swift while at the same time having the syntax that’s much more concise and at this point with the sort of evolution of people’s expectations around programming languages, just much more natural for them.

Gruber: Is part of the thinking there that in terms of the Smalltalk-inspired dynamic runtime, that you didn’t need a new language to do that because you already have Objective-C, and that you can go — you know — for the future, for the next 20 years. That that sort of model of looking at frameworks and programming languages isn’t the best way to go from here going forward?

Federighi: No, I would ... separate the syntax from some of the underlying aspects of the runtime and the programming model. Some of my favorite features from Objective-C are things like protocols and categories, which in Swift are called extensions, and those literate APIs as well as first-class classes with class methods — all of these things that were so important for us to build great APIs and great extensible frameworks were brought to Swift along with things like labeled arguments. And slowly we’ve also been bringing back much of the dynamism. Now there are some things that are impossible in Objective-C, and most of the dynamism that you really want is the ability to figure out what classes this really needs, to be able to cast the class dynamically to a particular protocol, to be able to do a kind of response to select or perform selector check. All of these things are possible in Swift today. And there are some other things that aren’t, but certainly we consider important to ultimately bring to the language. So, this thing about a dynamic programming model is still very important to us.

Now there are still some very unsafe things that people do in Objective-C, and I’ve been guilty of this myself, where you walk the Objective-C runtime and hack the method table — and that’s cool. But it is highly unsafe and doesn’t lead to very maintainable, scalable large programs. But the vast, vast majority of what makes Objective-C great and dynamic is ... either part of Swift now or certainly part of our ongoing ambition for the language. But the thing that we didn’t want to bring from Objective-C is that in Objective-C you’re paying the overhead of that dynamism all the time. You know, you’re trying to use an array or some class, and you’ve got the compiler with both hands tied behind its back in terms of opportunities for optimization, and then you’re forcing the developer to then modify the way they’ve written their code and maybe drop down to C for something where performance matters. For Swift, because it’s safer and has more type information, it gives the compiler what it needs to optimize when it can, but that alone doesn’t stand in the way of all — in my opinion — of all the dynamism that matters.

Gruber: In layman’s terms — and I’m probably way more on the layman’s side — it’s been a long time since I’ve programmed regularly — but for people listening, I think that the big difference is that with Objective-C — and people may not even know what a runtime is — but more or less what it means is that you compile the app and it starts running, and a lot of this stuff gets decided within the app while it’s running.

Federighi: Mmm-hmmm.

Gruber: With Swift, by doing these things at compile time, and knowing more of the type information and forcing you to be a little bit more specific about the type information upfront, it enables the compiler to do more efficient things before the app is even running because it’s happening at the time the app is compiled.

Federighi: That’s right. And then it permits all kinds of optimizations because maybe if the compiler can determine ahead of time that absolutely this object you’re about to message is of a certain type and we know you’ve done whole module optimization and we know what the result of that method is, sometimes the compiler can even inline the implementation and not even involve the overall function call. Let alone a dynamic method dispatch. ... That’s part of how you can get these incredible hand-optimized C kinds of performance numbers out of ... what you get to write as very high-level code. So Swift, I think, has a really excellent balance there. But the key is we still have a runtime where you can look at your classes and introspect them. And there’s more — there’s more of that coming.

Gruber: [laughing] Which partly is an open road map and partly is — in terms of the frameworks for the operating system, obviously is the sort of thing that you’re not going to be able to talk about in advance, because that’s not the kind of stuff that’s open source.

Federighi: That’s right. I mean, some of it honestly you will see us bringing up over the course of the next couple of months in the context of the open source project because certain things that our team will take on will bring them forward as proposals to the open source community. And then you’ll see us start to implement them. I don’t want to jump the gun and pre-announce everything that the team is thinking. ... A big part of the focus, we wanted to make sure was clear right out of the gate with Swift, was that the goal for Swift 3 was really to stabilize the binary interface and to refine the APIs and to finalize our API guidelines and all of those things. I think the next important step is to really stabilize the language and the environment of our community. And that’s a big task. One of the things that’s been so great about Objective-C is that it has this great stability that has enabled us to write frameworks with binary-compatible interfaces, release over release over release. That’s something that languages like C++ really couldn’t get right. And we absolutely need to bring that to Swift, so we brought forward some of those goals. But there are other things of course that will be added to the 3.0 ambitions as time goes on over the next couple of months.

Gruber: One of the complaints I’ve seen — and part of this is, it’s impossible to avoid, I think, with how early in its evolution Swift was unveiled to the world — but what I’ve seen from developer friends and just commentary on the Internet, is that it’s hard right now to write a large-scale application in Swift. Apple...

Federighi: Mmm.

Gruber: Apple has more people working on Cocoa apps than any other company in the world for obvious reasons.

Federighi: Right.

Gruber: How has the feedback from the internal developers — the people who work for you, the engineers who work for you with extensive experience shipping user-facing apps — shaped the direction of Swift from 1.0 to what’s on the road map in 3.0?

Federighi: We have all types here within Apple. They start out with the “I love Objective-C. I don’t want to change” to “OK, maybe there’s something to this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through all the phases internally. You know, we’ve had some really great adoption by teams like ... the team that does the Dock and the window management on OS X, implemented all their new features for El Capitan in Swift and started mass-converting all of their code, and say that they couldn’t imagine going back and that they’re more productive with it. Part of what our internal teams need to deal with, though, is that they’re working on, let’s say, the current version of Swift 2.0 while it’s not done yet. I mean, while it’s not even WWDC-level done yet, right? And they’re working on the interfaces in terms of our internal frameworks that haven’t been modernized for Swift. And so, they’ve got it rough. They’ve got to really love it to make that leap because they’re working on a very, very bleeding-edge environment when we use it internally. Thankfully, with Swift 2.0 now well out the door, that’s stabilized things a good bit and they’re really open to it.

But there’s been just lot of feedback. And a lot of it has helped with the impedance, making sure the impedance between Objective-C and Swift is absolutely minimized because of course we have and will continue to have and continue to write more Objective-C code, and so the ability of Swift and Objective-C code to work together completely naturally is a huge focus. A bunch of things like generic collection, support for lightweight generics in Objective-C, were big pain points internally and something we fixed in the language, and is now great for all of our app developers externally. So, it’s been a not dissimilar road for us internally to what you see outside.

But in terms of Swift and writing big apps, it’s certainly the case that when Swift 1.0 came out — heck, we didn’t support incremental compilation in the very first update. And so that was going to be a limiting factor for productivity for people who had big apps. A lot of that stuff has changed. And then in 2.0 having a good error-handling model, having the availability check so you could span API versions — these sorts of things. I think it really addressed the vast majority of pain points that we were experiencing, that I think the community was experiencing about writing larger apps. And so much about Swift is actually inherently better for building big apps because it handles modules and namespaces in a way more naturally than in Objective-C. It makes the API contracts a little more clear, the code more obtainable. So, we’re very comfortable.

Gruber: Objective-C’s namespace management was more or less “Let’s just all agree to put unique initials [as a prefix to our class names]” ...

Federighi: [Laughing]

Gruber: ... Right?

Federighi: It’s amazing it’s taken us this far. But yes, that’s basically been the answer. [Laughing] Maybe the bar wasn’t that high.

Gruber: Exactly.

Federighi: We have vaulted over it.

Gruber: How do you manage as the chief mofo in charge of this? How do you manage the enthusiasm that you clearly have for Swift and, what to me seems like a sincere belief that Swift is the way forward — with the necessary conservativeness that you need so that there still has to be a lot of Objective-C written? How aggressive can you be about putting teams on, “Sure, go ahead and do that in Swift”?

Federighi: People here are idealistic yet really pragmatic, and I think you see that as an Apple characteristic in many, many elements of what we do. And so, teams know, what the nature of what we’re trying to get done in their area in any given year, the nature of their code base, whether Swift is the right answer for them, or where it’s the right answer. Even teams where, for one reason or the other, they can’t jump right on Objective-C — or rather Objective-C conversion to Swift now. They then use Swift heavily for writing all their unit tests, which is great because then at least as they’re introducing new APIs, they’re experiencing their own APIs in Swift and then ... sort of eating their own dog food in that regard. We do have some constraints internally which we’re addressing, but because we ... I mean, it’s something in our closet a little bit, but we still support running 32-bit apps on the Mac. And the 32-bit runtime doesn’t actually support Swift right now. And so, what that means is that if we implement a framework that’s available to 32-bit code, we actually can’t write it in Swift. If that code, if that framework is used across iOS and OS X — as many of our frameworks are — that introduces a little stumbling block as well. So teams recognize what’s practical and what’s not practical and find ways to use Swift wherever they can. There’s no shortage of enthusiasm.

Gruber: This has been so geeky and so fun.

Federighi: Sorry about that.

Gruber: No, no, in the best possible way. I really enjoyed this. I see that you did a whole round of interviews last week, and I read them all, and I think they were great. And I didn’t want to cover the same ground, and I don’t think we did. I think this is truly, truly eye-opening to me. And I certainly appreciate your time. But I really appreciate the openness that you’ve had here.

Is there anything else that you want to say before we wrap up this segment — anything else you want to talk about Swift?

Federighi: I just want to say how, to the world — or at least the subset of the world that listens to your podcast, which must be most of them — how proud I am of the team that’s made Swift possible. Of course there’s Chris Lattner, but he’s part of an incredible team with folks like Ted Kremenek and Doug Gregor. Swift is where we have our incredible compiler team. We’ve also got people who have been writing deep frameworks and apps within Apple for, in some cases, since the beginning of NextStep. I mean, people like Ali Ozer, who you may know from his talks at WWDC. It’s been so vital in shaping the language and how the language fits our frameworks and fits the needs of our developers, and I’m just so thrilled with the work that all of them do and the passion they put into making Swift a success. I just want to get that out there for everyone. And there are hundreds more behind them. It’s been an incredible effort by our team.

Gruber: Would you agree with this? I think that Apple is in the unique position to ... if Swift achieves what you guys have set out to do, which is to make it the default language that people might learn to program on for the next few decades, Apple is in a unique position to make that happen because you have these platforms, especially iOS, but the Mac, the watch, and anything that might be coming in the future — oh yeah, tvOS...

Federighi: tvOS. Let’s not forget about the TV.

Gruber: ... that are so popular and are such a draw that they’ve made Objective-C, you know, like the second or third most popular programming language on some of these lists...

Federighi: Yeah! Mmm-hmmm.

Gruber: ... which, I think, to someone like you who started in the NeXT days, if you would have found out that in the year 2015 Objective-C is the second most popular language, you’d be like “What?!”

Federighi: I wouldn’t have believed it. Yeah, I would not have believed it.

Gruber: A language that there’s been an initial reluctance from people to get on board with. Now there’s this language that is so approachable and really almost has a syntax level — you know, when you’re talking about “Hello world” type stuff, it really almost looks like pure pseudo-code.

Federighi: Yeah.

Gruber: ... that Apple is in the unique position where the draw is there with the platforms to really, really make this explode in popularity.

Federighi: Yeah. I mean, I couldn’t say it any better. When we created Swift, while we wanted it of course to be a great language, we also from the outset wanted it to be a great language for our platforms, and the fact that it embodied lessons that we learned from creating so many deep frameworks and great apps over so many years, and what that’s meant is on day one Swift wasn’t a restart for the community. It wasn’t a “Hey, let me learn a whole new set of frameworks” or “Let me wait for Apple to create a whole new set of frameworks.” Swift has been this automatic transition for people who ... maybe who were new to our platform and wanted to get started. The whole world was open to them on our platform, and I think that’s been so huge to driving the energy around it. And then others have been drawn in just by the greatness of Swift as it is. It’s amazing, these Swift language conferences where people are talking about different functional programming paradigms in Swift and all these different things you can do with the language just based on what an amazing new language it is. So you bring those two communities together and it’s magic right now.

Gruber: Thank you so much, Craig. I really appreciate the time.

Federighi: Yeah, thank you, John. It’s been an honor to speak with you. So, thank you so much.