Dev Conversations #1: Andrew Barba
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
The first time I spoke with Andrew was in the first half of 2024, while I was checking out his Swift runtime for Vercel Functions. What I didn’t know then, was the fact he is the developer behind Swift Cloud. It initially launched as a hosted platform, but Andrew just announced and released a new vision for Swift Cloud: an open source framework to deploy Swift server applications, that is agnostic to the cloud provider and the application type (Vapor, Hummingbird, Lambda). The great thing about it is the infrastructure code abstracts lower level concepts and technologies (such as Dockerfiles), enabling the developer to describe in Swift the server infrastructure.
I messaged Andrew around a month ago, before his Swift Cloud announcement, asking to interview him for this series. Not only he right away agreed, but he was kind enough to help reviewing the hands on article covering Swift Cloud, and constantly listening feedback about its API.
Today he joins us for the second Dev Conversations, the first video episode. You can watch our conversation about his career, from an intern on the early days of WhatsApp in 2012, until his current position at Vercel and his work and future vision for Swift Cloud. You can find the written interview if you prefer reading or listening instead, and the podcast links after the video, along with relevant links discussed in the chat.
Also available in your favorite podcast player 
Swift Toolkit
Thanks for joining us today, Andrew!
Andrew
Thank you so much for having me. Excited to chat about Swift!
Swift Toolkit
To start, tell me a little bit about your background in programming. How did you start coding?
Andrew
So I started really as an iOS developer. The first place I ever worked was WhatsApp and I had a chance to go there and build an iOS app like really early on.
Back in the iOS 5, yeah, iOS 5 days, I believe, where Automatic Reference Counting (ARC) had just come out. So a lot of Objective C at the time and I was just all self-taught on the iOS side. I ended up going to school for computer science, but very early in my career I spent a lot of time just self-teaching myself Objective-C and then obviously Swift.
Swift Toolkit
The good old days. And then you move to TableList, where I assume you did a lot of iOS development.
What are the main things you did there? What were the most interesting challenges?
Andrew
So TableList started as a consumer platform for customers to book reservations at high end nightclubs. One can think of it as open table, but for nightlife. We built that company when I was still in college. I ended up working there for some five, six years, you know, even after college. But really my role there was to lead the native iOS development.
Originally it was just the consumer iOS app. Then very shortly after, we realized that in order to have a really good system for customers and the nightclubs, we basically had to build the management software for the clubs as well. I was also responsible for building the iPad app, which is what got basically the most usage inside of the nightclubs. So yeah, it was a really fun place to be.
I'd say some of the most interesting things and some of the things that I was really proud of was being offline first from the jump. We were using heavy CoreData from the start and then ultimately switched over to Realm. Once we migrated the app over to Swift, Realm just made a lot more sense. And at the time, Realm was just like a groundbreaking SDK.
Swift Toolkit
They took care of offline persistence and syncing, right
Andrew
We didn't even use it for all the syncing. It's just that their local data store was just so much better than Core Data at the time.
Swift Toolkit
I see. And you did backend stuff there?
Andrew
Being at a startup necessitated me to move from iOS over to a lot of backend. And this was also around when Node 0.10 was released. So we ended up building most of the backend on Node and Heroku at the time. I started to spend a lot of time with backend server technologies, scaling servers, using things like queues and different database technologies and things like that.
My career started to shift a little bit away from developing a ton on iOS, and started moving into much more backend architecture type of work.
Swift Toolkit
You left the bubble!
Then you moved on to Barstool Sports. That's where you started doing Swift on the server, more or less?
Andrew
Yeah, I joined Barstool Sports in 2017, where the first thing I did was actually rebuildtheir iOS natively from scratch. But similar to TableList, very shortly after, I had to move to the backend and start to rebuild, you know, basically their entire backend system. It was all in AWS. And we chose to use Lambda very early on.
It ended up being a phenomenal call, but it was certainly a bit of a rocky road to get it to where it is today. But yeah, we made the choice to be 100% serverless. And that directed a lot about how we thought about Swift on the backend as well, because it did such a good job abstracting away all these super challenging concepts when it comes to backend architecture.
Swift Toolkit
From a product perspective, was it for dynamic add insertions on Podcast episodes, or something different?
Andrew
The first Swift service we actually built at Barstool was a streaming media service and it did dynamic ad insertion. This was built on Fastly's cloud and their Edge Compute platform, which is a web assembly based runtime that gets executed at the Edge. They did not have a great JavaScript SDK at all, only a Rust SDK.
I wanted to see if I could write it in Swift. So we built this service that did all of our podcasts, server-side ad insertion in Swift. We compiled the Swift WebAssembly and deployed it to Fastly's Cloud.
Most of Barstool was Node on Lambda. This was like the first time where we got to try and use Swift, and it was for basically one of our most mission critical services: our podcast platform. It's still running today and it's been an amazing service for us.
Swift Toolkit
How was the reception from people who are not into Swift so much? Was there any resistance from their side?
Andrew
The language itself had little to no resistance. The tooling is what really had the most resistance from the other engineers. When you're so used to using things like npm install and looking for packages on npm and just using VS Code, and how well it understands TypeScript and things like that. Telling somebody to go download a 10 gigabyte Xcode IDE was a bit of a shock to go try and write Swift.
Then you throw on the fact that we're actually compiling to WebAssembly, so it was, it was very bleeding edge technology. So the tooling was probably the most frustrating aspect.
Swift Toolkit
I understand that
And from there, you started working on a side project, right? On the first version of Swift Cloud.
Andrew
Yeah! Basically, I took that Fastly compute runtime, which we were using. It was just so easy to deploy a Swift app to Fastly once you had all the correct tools in place. The idea for me was, well, how do we make it easy for everyone to deploy Swift on the server? And especially when you look at the language. It has async await now, even throwing the typed errors in Swift 6. Swift is so good for server-side development.
But the problem is it was way too hard to go figure out how to actually deploy a Swift app to the server. That was the idea behind Swift Cloud: the easiest platform to deploy Swift on the server.
That was the first version where I wanted to do it on top of Fastly, because it was fully serverless. It was streaming based, so really high performance and really easy to do custom domains and things like that. There was a lot of nice things that Fastly provided out of the box and made it a good platform to build Swift Cloud. But ultimately, I think the first version suffered from just being too bleeding edge on the WebAssembly front.
Swift Toolkit
I see. From there, that work on Swift Cloud got you a job at Vercel, right? Just for those who don't know, what is Vercel?
Andrew
Vercel is the leading front end cloud platform. It is the place where web developers go to deploy and host their websites. You know, everything from simple static sites to very dynamic serverless sites. And Swift Cloud had a lot of principles and was following, getting a lot of inspiration from the things that Vercel was building.
Swift Toolkit
The developer experience
Andrew
Exactly. I had a chance to demo the Swift Cloud Platform to Guillermo, the CEO of Vercel And it was very shortly after that, it was like, "you should just come build CDNs at Vercel"
I have not had a chance to introduce Swift at Vercel yet. I'm hoping one day, but most of my time at Vercel was spent writing Go Lang and Lua.
Swift Toolkit
What's your favorite part about other languages that you don't get in Swift?
Andrew
That's a great question. I would say so Golang is probably the most interesting language that I write day to day compared to Swift. Golang just feels so lightweight, and sometimes Swift can just feel so heavy. And that's for a lot of reasons.
Swift Toolkit
The type system you mean?
Andrew
Not even the type system, but honestly, parts of it is just using Xcode. It feels like you need all this horsepower to write Swift, and it feels like you need zero horsepower to write Golang. I would love if Swift would just start to feel more lightweight in build times, in the way it interacts with IDEs, the language server protocol, things like that.
I think it's starting to move into that direction.
Today actually 100% of the Swift I write is inside VS Code. I haven't used Xcode in quite some time, so I feel like we're starting to move in that direction.
I just love how, Go has built-in formatters, built-in benchmarking. It has all these features that you're starting to see Swift adopt. The Swift format plugin in VS Code is now working great. The official Swift plugin for VS Code has built-in testing. So we're starting to catch up to some of these other languages.
Swift Toolkit
The GitHub org change in the Swift repo reflects that.
Back to Swift Cloud!
You released around 3 weeks ago the new version of Swift Cloud. Do you want to talk a little bit about it?
Andrew
Would love to! When I first launched the first version of Swift Cloud, I found was I knew too much of the behind the scenes that I couldn't project to developers. The most obvious example of this is people would come to the platform, and they would say: "Hey, how do I get my Vapor app running on Swift Cloud? Or how do get my Hummingbird app? How can I use SwiftNIO or AsyncHTTPClient"
All these things were heavily limited because of the fact that there's no support for those things inside of WebAssembly. So the types of Swift apps that you could build on it were way too limiting. They were taking you too far outside of the ecosystem that Apple was trying to build.
So I wanted to take a completely new approach and develop an SDK that was framework agnostic, and cloud provider agnostic. And of course being fully open source. It's a complete shift in direction from what the initial platform was, but I think it's even more in line with the vision I wanted with the original platform.
It's giving people the tools to deploy backend Swift applications to any cloud that they want.Naturally, we're starting with AWS just because they have the most primitives, and Apple's doing a lot of work specifically around compiling to Linux, publishing Amazon Linux to Docker images, the AWS Lambda runtime.
Swift Toolkit
It indeed sounds like AWS is the best fit to start with.
And do you know already what are the next steps for it?
Andrew
Now it's just a matter of getting feedback, help shape what the future API looks like inside of Swift cloud. There's so many different areas of improvement. It really just comes down to letting people get their hands on and start using it.
Then of course, obviously adding new providers. Fastly and Vercel will probably be the next two that I add because I already have a lot of experience deploying to those two platforms today.
But I'd love to see someone go support Fly or Render or GCP. All the primitives are there for them to do that.
Swift Toolkit
Anyone can come in and contribute!
What I personally really like is that you're not required to know Docker or learn how to write a Docker file or a complicated packaging script or uploading.
It takes care of all the steps and even abstracts the concepts of resources, policies, roles. And we are only talking about AWS and each provider has its own intricacies and what not.
Andrew
Yeah, that's exactly right! If you were to start a new Vapor app today, it has some 100 line Dockerfile in it, which most people probably have no idea what's going on in that file.
I wanted to take a very different approach where you're not building inside of Docker, you're building natively. And Swift 6 will be able to use the native SDK cross-compilation, which we'll move to basically, as soon as that's released. And so we won't even need Docker at all, which is amazing.
Swift Toolkit
What I find fascinating about Swift on the server is that it lowers the barrier so much for people who have an iOS background development.
That's exactly what Swift Cloud solves in my opinion, right? It lowers the barrier for even for deploying. So I think this is beautiful and can empower people to build so much great stuff.
Andrew
I love to hear that! My dream is to mimic what Next.js did for JavaScript, where you could build a website, drop in a folder called API, and now your website can talk to your API and it's all deployed. I imagine you create a new target and Xcode right alongside your iOS target: you define your infrastructure and your backend services, you deploy them and boom! Now your iOS app has a super scalable API to talk to and you own all of it.
Swift Toolkit
Yeah, very cool!
All right, Andrew. Thank you so much for, first of all, all of your work, and for your time with us today.
Andrew
Thank you so much. It was great talking to you.