Under Discussion: The Evolution of Swift

Behind the Code met up with Erica Sadun and Pavel Zak while attending the 2020 edition of dotSwift to talk about the evolution of the programming language Swift, created in 2014. Author and co-author of several proposals on Swift Evolution, as well as a bestselling writer of many books and blog posts about Swift and iOS, Sadun is an experienced mobile developer. Zak is a SwiftUI devotee and gives talks, writes, and is involved with training on it. They discussed how the language has grown over the past six years and considered the ways it still needs to change.

When did you start working with Swift and what is your current involvement with the Swift ecosystem?

Erica Sadun: I was completely burned out on iOS development because it kept changing every year, and I thought to myself, “Oh, a new language, this is the perfect opportunity to do something stable, it’s not going to change.” So I thought that, like Steve Kochan has his Objective-C book, which he updates about once every 10 years, I would write a book on Swift, and that would be it. I could relax, enjoy my family, and have a life because a brand-new language would be stable for many years to come. But that isn’t what happened! So currently, I write about Swift, I develop in Swift, and I complain about Swift, which occasionally gives rise to changes in the language.

Pavel Zak: I started working as an iOS developer 10 years ago, and to be honest, at first, I really fell in love with Objective-C. And when Swift appeared, I was one of the few guys in our company who refused to start developing it. It looked too much like JavaScript and I didn’t want to rush into it. In the end, we slowly adopted Swift in our code base. We all know that history was sometimes jumpy, but in the end, I just got used to it. And last year, I fell in love with SwiftUI and became its early adopter! So now I give talks, write blog posts, and do some training on SwiftUI.

Swift is currently the sixth-most-loved programming language, according to the 2019 Stack Overflow study. Why did it become so popular among mobile developers?

ES: Apple put its weight behind it and made it the official language for development. If you want to be working in the Apple ecosystem, you’re probably going to be using Swift. But I am the perfect counterexample—I spent most of last year working in Objective-C because I was involved in a project where it was the language for the legacy code base. I tried to bring some Swift in but it wasn’t easy, because the larger the company, the more likely they are to be tied to Objective-C and C code. It’s very hard to make big institutions change.

PZ: I partially agree with Erica. I am now working with some companies that have 100% of their code base written in Objective-C and I am pushing Swift on their projects. They are open to transitioning to Swift, because the future of Objective-C, I would say, is quite uncertain now.

ES: But it is not dead! Objective-C continues to evolve, and it continues to have new features, although most of those are interop between Swift and Objective-C, such as nullability and declaring what the APIs will look like in transition.

PZ: That’s true, but you can’t deny that SwiftUI, for example, is the future of iOS and Mac apps. That’s why companies are being forced to start thinking about Swift, and how to change their code base to be ready for a future with SwiftUI in it.

ES: Many companies are not even using Interface Builder. I think there are practicalities that drive people to different languages. For example, there are some companies that have invested heavily in Kotlin, which is a fairly delightful language and has wonderful richness and many things I would love to see in Swift. Kotlin believes in giving its developers many ways of expressing things, even if there’s a certain level of redundancy, and Swift tends to try to keep its language more limited, to have a higher bar for inclusion, with the idea that people will eventually develop their own in-house library. The thing is, a couple of years ago, Andrew McKnight did a survey of third-party libraries for Swift that were on GitHub, and he found there was a huge amount of overlap.

Many years ago, there was a type in Objective-C called NSArray, and nearly every single developer out there created something called “first,” which would bring the first element of an array. How many years did it take for Apple to give in and say, “OK, finally, we’re going to give you ‘first’?” It was a long time, and it wasn’t that long before they brought out Swift, maybe three or four years. So, finally, they gave something that everybody had created already. And the same sort of hesitation to be expansive in the language is also found in Swift.

So you cannot look at the language without Apple’s presence being there, and perhaps, rather than looking at lists of most-loved languages, it is better to ask which languages are necessitated by what you’re putting into the market.

PZ: I think developers had the feeling that Swift was not some random project that will die soon. And from my point of view, it’s this Apple presence that has given developers confidence in the future of the language.

ES: Swift is very much influenced by current languages—it has bits of Scala, and it has bits of Rust, and it has bits of Python. And anyone looking at it who is conversant in modern languages is going to recognize things, and then they’re going to say, “OK, here’s something I can work with. What else will it give me?” And then you come with protocol-oriented programming, which is really one of the hallmarks of Swift. So it’s not just a mishmash of other languages, it’s a cohesive whole that has features and such that lend themselves to iOS development. And you see that with protocols. You see that especially with the new features, like property wrappers, which is what’s powering SwiftUI. But the language is expressive for particular platforms, and I think that’s drawing people in a way that Objective-C never could.

In 2015, Apple opened-sourced Swift and created Swift Evolution, to allow developers to make change proposals. How is Swift Evolution different from how other open-source languages are managed?

ES: Swift is owned by Apple, and there’s no understanding of Swift Evolution beyond that this is primarily an Apple product that they have open-sourced and allowed people to contribute to. It has been a big way of finding talent and hiring, especially for the language itself. As far as Swift Evolution goes, there is a core team that makes the decisions. And unlike other open-source projects that also have central committees, here the language ultimately serves the needs of the corporation, the platform, and perhaps the developers. I think, overall, Swift being open-sourced has been an extremely positive thing that allows us this unprecedented access to Apple technology.

PZ: I haven’t been active in the open-source development, but from a distance, I think open-sourcing Swift made non-iOS and non-Mac developers start to recognize that the language was something they needed to count on using, that it’s not just something that Apple is making for itself. And I also have the impression that it made the development of the language more fluent and fast. But I don’t have any numbers to prove it, it’s just a feeling.

From your point of view, what features in Swift still need to evolve?

ES: What happened is Swift 1 to 2 was evolutionary, Swift 2 to 3 was traumatic, Swift 3 to 4 was refinement. Swift 4 to 5 is adding polish and features that need to be there. They still need to finish generics, for example. And concurrency is probably the biggest hole right now, but there’s the manifesto for it, so people pretty much know where it’s going to end up. And certain things that were added to the language changed a lot over time. Raw strings, for example, which aren’t raw strings in Swift now, but more like medium-rare strings, changed a lot during the design process. Result needed to be added to the language, so we were waiting for it. They were two camps arguing about the philosophy of whether or not the second of the generic things should be “error” or if it should just be an arbitrary type.

PZ: As Erica says, almost everything has been polished now, so it is really hard to find a feature that you are crying every day about. And when something needs to be improved, it doesn’t take too long for it to happen. So it’s not frustrating anymore. There are several features that really make me happy today, such as property wrappers and SwiftUI. And even when there is an issue, it’s solved quickly. For example, there was an issue when SwiftUI appeared—the type checker had trouble giving you meaningful error messages, so you could have an error on one line but you saw it in different lines. It was fixed in 5.2.

What do you think of the features that were added in 5.1, such as property wrappers and function builders?

ES: I think function builders are not as interesting unless you have the right problem space. I’ve played with them—have you, Pavel?

PZ: A bit, yes.

ES: Yeah, and that’s it. People are not really using them much beyond SwiftUI. You need some sort of structured representational system to use them, and how many times do you need that for day-to-day coding? But property wrappers are awesome!

How do you see third-party libraries for Swift evolving?

ES: Swift was deliberately given the Swift Package Manager to try to encourage third-party libraries. For a while, a bunch of us were pushing for what we call the “sub-standard library.” “Sub-standard” is kind of a joke, and the idea was that we put together things that we thought could go into the standard library. And then Apple sort of ran with that, so there are things that go into the Swift builds that aren’t in the language yet, so you can try them out.

PZ: Regarding third-party libraries, meaning libraries developed by common developers, I see them as a fast-growing branch and they help the ecosystem to flourish. But at the same time, I’m starting to feel that there’s no real need for these libraries because, if you can go with the flow, in the end, you can do the coding without any special need for third-party libraries.

The Apple team proposed a framework called Combine to manage concurrency. And at the same time, the Swift team wrote a concurrency manifesto. How do you see concurrency management evolving for Swift in the future?

ES: The Apple proposition is interesting because they did go with Combine and the reactive stuff.

PZ: In the end I’m very happy that we also have this sort of reactive pattern in Swift, and we are able to pass it in our applications. I see SwiftUI and Combine as a huge improvement not just to the platform but to the onboarding of new people as well. From the point of view of a trainer, it helps to explain things with a better architecture than MVC. In the beginning, when we started with iOS development, most of us ended with those massive view controllers that we hated. The architecture of the apps was ugly and a bit complicated. SwiftUI forces you, even though you don’t realize it as a beginner, to build better apps, to put aside UI, and to focus on business logic. So I think we are at the phase where there will be new developers who, from the start, will be able to produce better-quality applications.

How did SwiftUI change the way you work?

PZ: With SwiftUI, I’m feeling the excitement of building apps again. I’m feeling that I’m much more productive. The apps I write are better in terms of architecture and stability. So I’m suddenly feeling young again!

How do you think technologies that allow you to write native apps on different platforms, such as Xamarin, can compete with Swift?

PZ: It depends on the metrics you use to evaluate it. In the past, I participated in a large project with Xamarin. On the one hand, it was nice to have business logic shared between Android, iOS, and web apps. Also, the back-end models were shared, so when the back-end guy made a change to his objects, we were able to easily adopt it on the client side. But in terms of developer experience, it is quite a different story. In Xamarin, everything looks like UIkit, everything you are familiar with is there, you just use C# so it’s not so hard to actually start developing in it. But you feel that you would probably be more effective in your native environment and language, especially when you encounter some obstacles. And the worst thing about it is that you are dependent on some third party. So, for example, during our project, a new version of iOS was released, and it took one or two months for Xamarin to come up with the new version so we could build a new version of our applications and support the new iOS and build a new release of our apps.

But usually the price is the main factor for a company to make the decision. For some customers, we tried to find ways with PhoneGap or Xamarin to creating apps for both Android and iOS in the cheapest way possible. But in the end, we realized that if we stuck to native development, we would stay within the same budget. Because even though sometimes you need to write things twice, if a skilled developer on his platform is doing it, he is much more productive than when you are trying to come up with multi-platform code.

This interview has been edited for space and clarity.

A special thanks to Vincent Pradeilles who helped with the preparation of this interview.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Illustration by Catherine Pearson

Photo: Welcome to the Jungle

Follow Welcome to the Jungle on Facebook, LinkedIn, and Instagram, and subscribe to our newsletter to get our latest articles every day!