Nick’s journey into programming started early, though he didn’t follow a traditional computer science path: he studied electronic engineering at university before transitioning into web development. In 2009, the company he worked for wanted to get into iPhone app development, and this is when he took the opportunity to dive into a new field: iOS development.

This led him to become involved in iOS development, where one of his open source projects became very popular: iCarousel. It allowed displaying a cover flow interface, similar to the UI present in the iPod app. This helped establish his name in the iOS community, along with a book he wrote on Core Animation.

One day, after Swift was released, Nick decided to create a tool to solve code formatting issues, to allow himself, and his team, to focus on what matters in Pull Requests: the functionality and the architecture, not the amount of whitespaces or the position of the brackets. Nowadays, SwiftFormat is by far his most popular project, solving code formatting issues for hundreds - if not thousands - of developers.

In this episode, Nick shares his journey from web development to becoming a key contributor to the Swift ecosystem. He discusses the evolution of SwiftFormat, its technical implementation details, and how it compares to Apple’s official swift-format. He also shares insights about maintaining motivation in programming and his thoughts on the future of Swift development.

• Website
• GitHub
• Mastodon

• try! Swift Tokyo 2025 - SwiftSyntax: for good and evil
• SwiftServerConf: So You Think You Know Swift?

• SwiftFormat
• iCarousel
• Expression

Back in 2017, Pedro Piñera was working at SoundCloud in the iOS Platform team. Their codebase was a mix of Swift and Objective-C, and developers faced difficulties when dealing with linking, build phases, build settings, and other complexities. Additionally, they would have Git conflicts in the Xcode project file.

That’s when Pedro decided to create a tool that would solve Xcode’s complexity by using project generation, which would abstract Xcode’s intricacies, instead of creating a new build system. With that, Tuist was born.

As Tuist’s users come from iOS and macOS development background, choosing Swift was a no-brainer, to encourage contributions from anyone using it. The tool was well received, the project became more popular, and the community around it grew over the years. One of the contributors, Marek Fořt, added support for SPM dependencies. Later on, he became part of the core team.

Facing the challenges of maintaining an open source project, Pedro and Marek decided to establish a company around Tuist. Their objective: to guarantee a sustainable future for the project and develop a better product.

In this episode, Pedro and Marek share the journey of Tuist since its inception, and discuss the challenges of scaling an open source project: what starts as a pet project can easily burn you out. They also explore some of the contributions they are able to provide to the Swift community, by extracting battle-tested parts of Tuist into reusable packages. Finally, they share the vision for the future of Tuist, by making it become more than a CLI tool. A broader ecosystem, with a server component and automation blocks, with the goal of helping developers in their workflows of creating software, testing it, sharing with others.

• Interactive & Beautiful CLI Tools with Noora
• Running System Processes with Command

• Website
• Mastodon
• Bluesky
• Slack

• Command
• Noora
• XcodeGraph
• XcodeProj
• Tuist

• Website
• GitHub
• Mastodon

• Website
• GitHub
• Mastodon

Natalia’s journey into programming didn’t start with Swift - it was actually with Java. Later on, she worked on a codebase in Ruby, and in 2014 she joined the company that built Paw, the macOS HTTP client, where her time was mostly spent by coding in JavaScript. But working with interpreted languages didn’t feel quite right for her.

Around that time, Apple had just released Swift, and it came in a great timing for Natalia. She missed the compiled aspect of Java, but also the simplicity and the expressiveness of Ruby and JS. This brought her closer to the iOS and macOS development scene, and in 2019 SwiftUI became the new kid on the block.

With the limitations of the first version of SwiftUI, Natalia started writing great blog posts about it, drawing the attention of the engineers behind it: a few months later, Natalia joined Apple and helped build some new SwiftUI components.

In 2022 she left Apple, and slowly transitioned to fully working on her own projects. Last week Natalia published her 3rd book, SwiftUI Fundamentals, covering its core principles and concepts. Today she joins us to speak about her early career, the work she did at Apple, and how she manages mixing writing blog posts, publishing books, and doing client work.

• Blog
• SwiftUI Fundamentals
• Swift Gems
• Integrating SwiftUI into UIKit Apps

• X
• Mastodon
• Bluesky

Sourcery is one of the first tools in the Swift ecosystem, launched back in 2016. Its author, Krzysztof Zabłocki, got tired of writing boilerplate code, such as Hashable and Equatable conformances (before they were automatically generated by the compiler), and decided to create a tool to save time doing it for him and many others.

But long before that, Krzysztof’s journey into programming began when he was a kid. He entered the world of iOS development even before the public SDK was released, and before that he worked on game and graphics development. Krzysztof built custom UI and Physics Frameworks for games, among other lower level libraries in C++ and renderers.

Throughout the last 15 years, and alongside his open source contributions to the community, Krzysztof worked with iOS at various companies, such as Mashable, led the iOS team at the New York Times, worked at The Browser Company (behind Arc), and also built his own indie apps at Pixle. In 2024, he decided to leave his full-time position at The Browser Company, and focus on consulting and launching a course about developer productivity, SwiftyStack (use code SWIFTTOOLKIT for 20% off).

In this episode, Krzysztof joins us to talk about his career, the history of Sourcery, and what led him to leave solid positions to become independent, and focus on what is important to him, in both professional and personal senses.

• Website
• GitHub
• X

• SwiftyStack (use code SWIFTTOOLKIT for 20% off)
• Sourcery

• SwiftHeroes 2024: The Art for Balanced Life
• SwiftHeroes 2023: Leveraging Composable Architecture at Scale
• SwiftHeroes 2022: Improving developer experience through tools and techniques

Mikaela Caron learned how to code after studying mechanical and electrical engineering in college. When SwiftUI was first released, she preferred to learn UIKit as it was a more mature framework, and later returned to SwiftUI a few years later.

When a coworker introduced Mikaela to Vapor and Server-Side Swift, she became interested in the topic and created several video tutorials about it. At the SwiftServer Conference, Mikaela gave two interesting talks, in 2022 and 2024.

After working as an iOS developer at Lickability, she decided to become independent, dividing her time between freelancing work, her own indie apps, and her YouTube channel, where she shares her knowledge about UIKit, SwiftUI, and Vapor.

In this episode, Mikaela shares her journey as a software developer, from learning how to program for iOS in Swift to making the leap to backend development with Vapor, and the lessons she learned along the way. She also tells us how working as a freelancer allows her to keep learning new things and how that contributes to her own apps, which she builds in public.

• Website
• GitHub
• YouTube Channel
• Swift Over Coffee
• Other Social Links

• SwiftServerConf 2024: Just Save a File, It’s Easy, Right?!
• SwiftServerConf 2022: How to Make Vapor Fly | Deploying Vapor on Fly.io

• Deploying an Email System with SwiftCloud
• Swift Open Source Slack
• Vapor Discord
• Hummingbird Discord

The adoption of strict concurrency in Swift is not an easy process in some projects. Implicit assumptions we usually make are often challenged by the compiler, and we don’t know how to solve them in many cases - leading to frustration among us, developers. The amount of keywords also doesn’t help: tasks, sendability, isolation domains and boundaries, actors, preconcurrency, and the list goes on.

If you’ve been active on Mastodon, in the iOS development world, there’s a person that is frequently mentioned in questions or errors about Swift’s strict concurrency: Matt Massicotte. While working on his open-source projects, he recognized the opportunity to migrate them and deepen his understanding of structured concurrency.

In this 4th episode of Dev Conversations, he joins us to talk about his experience with Apple platforms even before the introduction of OS X; a bit about his work on improving the iPhone’s battery life in the late 2000s, and also the early days at Crashlytics.

But the main focus of the conversation is Swift 6’s strict concurrency. We discuss the factors one should consider before adopting it, the feelings we face when encountering enigmatic errors, and also suggest practical solutions and strategies to upgrade to strict checking with peace of mind.

• Website
• GitHub
• Mastodon

• ConcurrencyRecipes
• Queue
• MainOffender
• Chime

• Swift.org: Migrating to Swift 6
• Talk @ Swift TO: The Bleeding Edge of Swift Concurrency
• Should You Enable Swift’s Complete Concurrency Checking?
• Problematic Swift Concurrency Patterns
• Making Mistakes with Swift Concurrency
• Crossing the Boundary

• Swift 6 + Concurrency = Peace: Talk by Muralidharan Kathiresan at SwiftConnection 2024

Adam Fowler and Joannis Orlandos are both active members of the Swift Server Workgroup. Adam is known for his contributions to Soto (a community supported Swift SDK for AWS), and to the VS Code Extension for Swift, amongst other packages. Joannis was a contributor and core team member at Vapor, and is involved in many Server Side Swift projects: he created MongoKitten (a MongoDB Driver for Swift), and is a maintainer in RediStack and CoreOffice.

In the last few months, they have been working together on a new major version of a lean and modular web framework in Swift: Hummingbird 2.

In this Dev Conversations episode, Adam and Joannis join a chat where we talk about the evolution of Soto, working with Swift in VS Code and how Dev Containers are helpful, and how not, Hummingbird 2. As Joannis told his jounery in the Swift on Server world, we discussed the key differences between Hummingbird and Vapor, lessons learned along the process, and how the two frameworks help each other and the Swift community as a whole.

• Website
• GitHub
• Mastodon
• Soto (Website)
• Soto (GitHub)
• VS Code Swift Extension

• GitHub
• Swift On Server
• X
• Mastodon
• ServerSide.swift 2024: Introduction to Hummingbird 2
• ServerSide.swift 2019: API Performance A Macro Talk About Micro Decisions

• Website
• Discord
• GitHub
• Examples Repo

Dave Verwer is well known in the iOS developer community, mostly for his iOSDevWeekly.com newsletter, which he’s been publishing for more than a decade. In the recent years, Dave and Sven A. Schmidt have been working on the Swift Package Index - a website that does much more than just listing Swift packages. It shows, for each listed package, a matrix of supported platforms, Swift versions, and also allows launching a playground with a package to try it out!

After listening to some of their podcast episodes, and peeking at the organization repositories on GitHub, I was sure it could yield a great talk about the different pieces they have built when creating the website. The Vapor server, the tools to digest packages, documentation hosting for package, the infrastructure that supports it all…

Sven and Dave both kindly accepted my invite to join another Dev Conversations episode. We chatted about its history, all the pieces behind the scenes, the state of Swift 6’s strict concurrency. Wrapping up, we also discussed how demanding this project became, and how essential is the community support, from GitHub Sponsors to the companies that contribute to it (MacStadium, Microsoft, and since 2023, Apple).

• Website and Blog
• Discord
• GitHub
• Podcast
• Ready for Swift 6
• Post: Switching to ephemeral macOS build runners
• Mastodon
• Percy by BrowserStack

• Website
• GitHub
• iOSDevWeekly.com
• Talk: How I Accidentally Ended Up Running The Largest Open-Source Vapor Website

• Website
• GitHub
• Mastodon

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 first recorded episode Dev Conversations. Here we talk 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.