Dev Conversations #9: Nick Lockwood
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.
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 Nick 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.
You can also find the written interview and the podcast links after the video in case you prefer reading or listening, and the relevant links at the end of this page.
Also available in your favorite podcast player 
Swift Toolkit
Hey Nick, how's it going?
Nick
It's all good, thanks
Swift Toolkit
Last year it was quite a surprise for me when I was joining SwiftHeroes, the conference, and I looked three rows behind me and I saw you!
I've been wanting to chat about these topics for a while, so I'm happy we found the time.
Before we jump into SwiftFormat, can you tell me a little bit about your early days as a programmer?
Nick
I've been interested in programming since I was a kid. I studied electronic engineering at university instead of computer science. After realizing this wasn't the right path, I spent a year catching up on computer science fundamentals.
My first job was as a front-end web developer, working primarily with HTML and CSS. While it wasn't traditional software engineering, it was my entry point into the industry. During those early years, I spent much of my time tinkering with programming projects outside of work.
In 2009, while working as a front-end developer, I was doing more JavaScript work during the rise of jQuery. Front-end development was evolving into a more serious software engineering discipline at that time.
When one of our clients asked about building an iPhone app, our sales team was like: "sure, sure, we know all about that", but internally no one really knew... I had been reading about iOS development and saw an opportunity. Despite not even owning an iPhone, I decided to take on the project, and that's how it all started.
Swift Toolkit
I assume you had a Mac 😁
Nick
Yeah, yeah. I'd been an Apple fan for many years. I didn't get the 1st generation iPhone, but I got the second, the iPhone 3G pretty much as soon as it came out in the UK.
Swift Toolkit
And then a few years later, you wrote the CoreAnimation book. How did you jump from a regular developer who just started developing on iOS to an author of a book on CoreAnimation?
Nick
Great question.When I started iPhone development, there was no significant open source community around iPhone and Objective-C. If you needed something that wasn't built-in, you had to build it yourself. Working at an agency, I noticed many patterns repeating across different client projects.
One common request was for Cover Flow, which Apple used extensively but didn't provide as a component. Designers and clients expected these UI elements to be available, similar to what they saw in Apple's apps.
After a year of iOS development, I had gained a good understanding of the platform. I discovered that CoreAnimation, which powers UIKit, had 3D capabilities. Existing Cover Flow libraries used OpenGL, making them difficult to integrate with interactive UI elements.
I realized CoreAnimation could handle 3D rotations, so I decided to build a solution using it instead of OpenGL - which is quite hard to integrate into a user interface, it basically just render images. The CoreAnimation approach would allow for proper integration with UIKit and support interactive controls within the carousel views.
Since client code couldn't be reused across projects, I decided to work around this problema and release some of it as open source. This way, the code was available to everyone, and I could reuse my own solutions without ownership conflicts. This led to the creation of iCarousel.
Swift Toolkit
But did you have any experience previously on 3D graphics?
Nick
I had some experience with 3D graphics as a hobbyist. I had written a couple of games using OpenGL, though not specifically for iPhone. This self-taught experience helped me understand the basic principles, though I'm sure my implementations weren't the most efficient.
But CoreAnimation is a high-level API that handles most of the complexity. You don't need deep mathematical knowledge - just a basic understanding of concepts like 4x4 matrices and how they manipulate values. The framework handles all the complex math for you.
iCarousel was one of my first major open source releases and became my most popular project. I had created like 50 different open source libraries for various purposes, but iCarousel really helped establish my name in the iOS community.
Swift Toolkit
You had also iVersion, right?
Nick
Yeah! And I also had a library called iRate, which was basically for showing a rating prompt... because at the time everybody lived and died on how many stars they had on the AppStore. That turned out to be quite controversial. It sort of got some negative attention. It was also very popular, but not in the same league as iCarousel.
Swift Toolkit
And by building iCarousel, you got all the knowledge about CoreAnimation? How did you learn all the little details about it,did you have any experience on CoreAnimation on the Mac, maybe?
Nick
No, no, not at all! CoreAnimation did come out for the Mac originally. It was first released on Mac OS Tiger about a year before the iPhone announcement, but I was never really a Mac programmer. Even today, I've written far more iOS code than AppKit code.
My understanding is that CoreAnimation was actually created for the iPhone, even though it debuted on the Mac first. It was one of Apple's first, kind of, cross-platform APIs and helped bridge the gap between macOS and iOS development.
I learned CoreAnimation purely through my work on iPhone development. The knowledge came from trying to implement the intricate designs that clients and designers requested, often solving problems that no one was really sure how to do.
Swift Toolkit
And nowadays they're much easier with SwiftUI. right. You just with a few lines. You can declare things that, to build with CoreAnimation, would require much more verbose code.
Nick
I think SwiftUI still uses CoreAnimation under the hood, but it's much more declarative and less explicit. CoreAnimation was already quite declarative compared to other animation libraries at the time - you could simply specify the start and end positions, and the duration, and it would handle the animation for you.
There was an interesting relationship between UIKit and CoreAnimation. In CoreAnimation, everything animates by default, while in UIKit you have to opt in to animation. Exploring how these two systems worked together was very interesting.
I didn't learn CoreAnimation from building iCarousel - I built iCarousel because I already had learned some CoreAnimation. The success of iCarousel led to a publisher, Pearson, to approach me about writing a book. While I knew the basics, writing the book required deep research that gave me a comprehensive understanding of CoreAnimation from top to bottom.
Swift Toolkit
Yeah, a lot of people, whenever they need to teach it, either it's a talk or a book, that's how you really learn it.
Nick
Right, I think one of the reasons I like to do things like give talks or, you know, write posts about things, is because it's a good way to learn. You never learn something as well as when you try and explain it to somebody else.
Swift Toolkit
Yep, totally agree.
And fast forward a few years, Swift is announced. How long after that you came up with the idea of SwiftFormat? When did you feel it was a necessity?
Nick
I had always been frustrated by the lack of good formatting solutions for Objective-C. While there was Clang format, it was fiddly and difficult to configure. I had considered writing my own formatter since I found parsers interesting, but Objective-C's complexity, sitting on top of C with its macros and various syntaxes, made it impractical.
When Swift was announced, it seemed much simpler than Objective-C, without the complexity of macros and syntax variations. It appeared to be a more achievable project for a formatter. Looking back now, it's interesting how Swift has grown into a complex language itself. It didn't have macros and all weird sort of syntax variations.
The immediate motivation came when I joined a new company using Swift heavily. They had no code style standards, with inconsistent indentation and spacing even within the same file. I realized I couldn't make others care about formatting, and didn't want to spend code reviews discussing whitespace. That's not the point of PRs. I decided to create an automatic formatter that would handle styling without requiring anyone to think about it.
Swift Toolkit
So how did you approach the implementation? Because parsing is not a simple topic at all!
Nick
I first looked at existing solutions. Apple had a tool called Swift-Format in their repository, but it seemed like a minimal effort that had been abandoned - it hadn't been updated for a long time.
The more well-known tool at the time was SwiftLint, but my boss was strongly against using it. He found tools that complain about whitespace in PRs very annoying, which reinforced my decision not to be the person nagging about formatting in code reviews.
At that time, SwiftLint didn't have any automatic formatting capabilities. It could only identify issues and flag them, rather than automatically fixing them. This limitation made it clear that a new solution was needed.
Swift Toolkit
That makes sense. And SwiftLint used SourceKitten, right?
Nick
Yes, SwiftLint was built by JP Simard using SourceKitten, a Swift wrapper for Apple's Source Kit compiler library. I looked into using it, but it produces an AST (Abstract Syntax Tree) that strips out whitespace and comments - exactly the things a formatter needs to care about. While you could build a formatter using just an AST, that would require making decisions about every single line break and space, which seemed too ambitious for a first version.
After experimenting with SourceKitten, I realized I just needed token and whitespace information. The initial version of SwiftFormat was quite simple - it didn't even distinguish between keywords and identifiers since that wasn't necessary for basic formatting tasks.
The core of SwiftFormat is a tokenizer that processes the source file string, identifying symbols, brackets, operators, and other elements. Even today, SwiftFormat isn't much more sophisticated than that - it still follows the same basic approach of making surgical changes to whitespace and indentation rather than completely reformatting files.
Swift Toolkit
So how it had evolved from there?
Nick
Well, the main thing that's evolved is just the complexity of the rules. There's now much more ambitious rules than initially. And in many ways, the rules in SwiftFormat are sort of too ambitious, they might be doing things that can't really be done at the level that it's operating.
One of the things that SourceKit does, which SwiftFormat doesn't, is to compile the project and make sure that it's valid code. Most of the time for a formatter you don't need that, but for some things you do, some things can't really safely be done without having that information. People often ask me to write rules: "we have this naming convention. Can you write a rule that renames all of these functions to follow this convention?" It's like, well, I can't really do that because SwiftFormat just...
Swift Toolkit
That's not the point of SwiftFormat?
Nick
Well, it's not that it's not the point. I have no objection to doing that. I think it's a reasonable thing. You know, my view of what a formatter is, is maybe like broader than what lot of people would consider.
Swift Toolkit
You mentioned Swift-Format, the other project by Apple. Nowadays it lives under its own repository, correct?
Nick
Yeah, so the only thing that the new Swift-Format has in common with the old one is the name, as far as I can tell.
At the time when I wrote SwiftFormat, swift-syntax didn't exist. It wasn't available as a library, it didn't even exist as a concept, really. SourceKit isn't suitable for making formatters or operating at this level, as I said, because it basically produces an AST only, and what you want is a CST: a concrete syntax tree.
LibSyntax was the framework that Apple exposed for handling that kind of level of information. And swift-syntax grew out of LibSyntax. Initially, it was just a Swift overlay for LibSyntax, which is a C++ library. And then eventually it became a standalone library, but this was many, many years later. So since 2017, when swift-syntax first appeared, and then a few years later when it eventually became a standalone library, it then became possible to write a formatter based on that. That's what the new Swift-Format from Apple is based on - it's using the swift-syntax library.
Swift Toolkit
So what are the practical differences?
Nick
Swift-syntax is a full parser, unlike SwiftFormat which operates at the token level. While it still processes files individually, it provides complete syntax validation and can handle invalid syntax safely. It's also capable of, applying some correction, it can handle invalid syntax basically as well and do so safely.
The main advantage of swift-syntax is its hierarchical parsing - it automatically understands relationships between code elements, like identifying function declarations. In SwiftFormat, each rule has to build its own mini-parser to understand these relationships.
With swift-syntax, all the parsing work is done for you out of the box, which makes development much more convenient. However, this comes with some significant trade-offs.
The two main costs are size and speed: swift-syntax is a large library that takes time to compile, and while it's fast for what it does, it's still slower than SwiftFormat's simpler lexical processing.
Swift Toolkit
I see. That makes sense.
Now I have a question that is less technical, and more general. You've been doing iOS for a while. How do you keep yourself fresh and challenged? How don't you get bored from doing "regular" stuff?
Nick
I have specific interests like parsing, language design, and 3D graphics that keep me engaged. While my day job doesn't always intersect with these passions, it did happen with SwiftFormat, I was able to do deal with parsing work.
Most of my work involves regular iOS development - the typical JSON to table views workflow. While I enjoy it, there's not always much novelty in it. I find it challenging to learn new things without a concrete project that requires them.
In fact, without my regular iOS job, I probably wouldn't have kept up with technologies like SwiftUI. My side projects tend to stick to what I already know, as I need a practical reason to learn new things.
But between my programming hobbies and the variety of tasks that come up at work, I find enough diversity to keep things interesting and avoid getting bored.
Swift Toolkit
And did you have any opportunity to do Swift on the server?
Nick
Nick
Nick
Swift Toolkit
And What do you feel Swift is missing? Especially when compared to aspects of other languages.
Nick
I'm particularly interested in parsers and syntax because I enjoy meta-programming - building tools that work with the language itself. The Swift ecosystem has tools like Sourcery for code manipulation and now the Macro system.
I recently gave a talk about swift-syntax, exploring the idea of writing an eval function for Swift - could we write Swift code that interprets and runs Swift code? While it's a challenging concept, it's an interesting thought experiment.
Another fascinating development is Swift WASM. There's now a library to run compiled WASM code in Swift. Imagine using swift-syntax as part of a toolchain to compile Swift into WebAssembly at runtime. This could give Swift some capabilities typically found in scripting languages, despite being a compiled static language.
With an end-to-end Swift toolchain, you could create plugin systems. For example, in SwiftFormat, adding a new rule currently requires editing source code, recompiling.
Swift Toolkit
And then redistribute the binary to everyone who's using it.
Nick
Right, dealing with distribution issues like signing and Apple developer accounts. A more dynamic approach would make this much more practical for users.
If you had this kind of ability to just evaluate Swift code at runtime, even if the performance wouldn't necessarily be as good, you could write your SwiftFormat rules just as a text file and then import it and you could have a plugin system, right? You could just write your own rules and run them, without having to rebuild everything and go through Xcode and go through distribution and signing. You could do cool stuff in apps.
It's possible to make apps scriptable right now using JavaScript because Apple provides JavaScriptCore, a runtime for JS. But there's no way to make them scriptable using Swift really, because there's no equivalent thing. So I find that quite interesting.
Swift Toolkit
But do you think it's by design?
Nick
No, I don't think Apple is fundamentally opposed to this idea. I mean, it might introduce some security concerns, but probably nothing that's not already a problem with JavaScript. Over time, Apple has become more relaxed around this. In the early days of the App Store, they had a no virtual machines policy, then that became sort "only our virtual machines" and now it seems to have just pretty much gone away altogether.
I think it's just a matter of focus, right? With server-side Swift, Swift on Android, and on Windows and WASM, like all of these things...
In a lot of the cases, it's actual Apple employees are pushing these things, but it's just not really part of the company strategy. I think that's why there's not a lot of like momentum behind them. It's, you know, people who are enthusiastic about these things are pushing them forward, but it's not Apple themselves.
Swift Toolkit
Yeah, makes sense.
All right. These were all very interesting answers, and it's really interesting to learn about the origins of SwiftFormat and how you built it.
Thank you so much Nick! For your insights, for sharing your experience and your tips. We'll be in touch.
See you next time. Bye bye.
Nick
Thanks, bye!