Dev Conversations #7: Natalia Panferova
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.
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.
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 Natalia, how's it going?
Natalia
Hi Natan, thank you. Thank you for inviting me.
It's going great.
Swift Toolkit
Sure!
People know you probably most from from your blog and from your books, right? You just published a new book.
Natalia
Yeah, I did. just last week!
Swift Toolkit
Before we jump into the most stuff that you've been doing.
How was your early career and your first moment with programming?
Natalia
It was a while ago. I think I started learning to code about 10 years ago.
I was considering studying computational linguistics because my first degree is in linguistics, teaching foreign languages. And I needed to learn the basics of programming, subjects such as object-oriented programming, algorithms, data structures. So was studying that by myself and I was also invited to attend some lectures at univeristy to prepare.
That's how I got the basics. I started with Java, it was the first programming language I learned, then Python.
Swift Toolkit
And how did you get to the iOS world?
Natalia
I think it took about a year or two before I started learning iOS. I started learning the basics and then I decided to pause it, because I got a job and it was in a company called Paw (now they're called Rapid API). It's a macOS client for HTTP. That was my first real tech job and I was doing a bit of everything.
Swift Toolkit
I love Paw! It's a great app for testing HTTP APIs.
Natalia
It was a nice company to work in. It was a very small team, very nice. I learned a lot there.
I was doing actually more web development for them in React, and also tech support.
The app was in Objective-C back then, but I was writing its extensions in JavaScript: code generators and dynamic values, importers, exporters. And I was doing a bit of web frontend as well in React.
Swift Toolkit
I remember Paw allows you to export requests as code, as curl commands.
Natalia
Yes, that's right.
And then I did a bootcamp in Portugal in Ruby and Rails because I thought: I need to understand a bit more about web development so I can progress.
So after that, I looked for jobs in Ruby, but I felt Ruby doesn't feel quite right for me. I prefer something a bit more strict typed and framed. And Ruby was a bit too dynamic and free form for me.
Swift Toolkit
Yes, interpreted languages have this disadvantage
Natalia
Right. Then I looked I had some idea for a Mac app actually based on my experience with Paw.
I looked for macOS tutorials and there was nothing online available. And I thought "Okay, maybe I'll start learning iOS and Swift and then I'll figure out how to build something for the Mac".
That's how I started learning iOS and I just loved Swift. I felt that's perfect for me. That's how I got into iOS development. And then I got a job being an iOS developer, and it carried on from there.
Swift Toolkit
Before we jump into SwiftUI, what are your favorite things you have done in that era?
Natalia
Definitely contributing to Paw was great, as well as writing the docs. Now I go to the website and they're still there, some articles I wrote, which is quite nice. It was a really nice first job to have.
And then I built a few iOS apps as well with UIKit back then. Unfortunately, they are not on the App Store anymore because I had to remove all of my apps when I joined Apple. And I never had an opportunity to bring them back because I had new ideas to build.
I built a few small apps while I was learning: one for collecting clothing tags, and an app for a similar concept, but for drinks you might like. Sometimes you buy a bottle of wine and you like it, but then in the next time you forget what you liked and what you didn't. So I made an app tracking that as well.
Swift Toolkit
That's good!
Natalia
And then I built a more serious app called Cleora, which was a WebSocket client, first for iPad and then for the Mac as well. It was just before I joined Apple.
Swift Toolkit
That's similar to Paw, but for WebSockets!
Natalia
While I was doing tech support for Paw, we had a lot of requests for developers to add WebSocket support for Paw. They didn't think it quite fits, as Paw is more HTTP focused. So I thought it could be cool to build something for WebSockets.
Swift Toolkit
You found an opportunity! It's always inspiring seeing people building their own ideas, instead of just developing someone else's. It's definitely something to admire in my opinion.
Natalia
It's more motivating, I think, when you want to learn to build something on your own.
Swift Toolkit
Yeah, for sure!
And then you got the job at Apple on the SwiftUI core team, right? I don't know if you feel like talking about how did that happen.
Natalia
They reached out to me after finding my blog. I had started learning SwiftUI right when it was released in 2019 and was building apps with it immediately.
Coming from React, SwiftUI felt more intuitive than UIKit - it was a completely different mindset. Though I was enjoying building apps, the first version was quite limiting, so I had to create many workarounds. I started blogging about these solutions, and the blog kept growing.
The SwiftUI team contacted me saying "We found your blog. You seem passionate about the framework. Would you like to come work here?" It sounded like a great opportunity.
The hiring process took some time since I was in New Zealand and they had to work through a local subsidiary. But eventually, I joined the team in November 2020.
Swift Toolkit
And what can you share about things that you have released maybe?
Natalia
When I first joined, I was just doing some bug fixes first, and then I started working mostly on text for the first year. It was when AttributedString, the Swift version,was released.
Swift Toolkit
Right, not the existing NSAttributedString.
Natalia
Yeah. Then I did markdown support as well in Text views, clickable links, different styling options... Most of my work was focused on text during that time.
And after that, I was still responsible for Text, but then I got also modal presentations. I was working on the new sheet APIs, the ones that support detents, adjusting the height of the sheet, the background of the sheet. This, and popovers.
And then I was also on the working group for navigation when it was redesigned as well. At first we had navigation links with bindings, and then there was the new generation of navigation APIs. You present data and you have a navigation path, which makes it easier to do programmatic navigation. So I was contributing to the design of that.
Swift Toolkit
One question that I wanted to ask you: do you have any tips for people that come from a longer UIKit mentality, such as myself. I'm a really big fan of UIKit and collection views and layouts. And sometimes programming in SwiftUI is really changing your way of thinking.
And also the other way around, if there are people who are newer in the iOS development world, who are used to this way of SwiftUI that just works.
Natalia
For people coming from UIKit, the main concept to understand is that SwiftUI views are not objects - they don't persist. A SwiftUI View isn't something you actually see on screen; it's more of a template defining what you want to see.
In UIKit, you create a UIView and assign properties that modify what appears on screen. SwiftUI doesn't work this way. You can't have a reference to a Text view and update its text directly. Instead, SwiftUI renders the body once, then discards your descriptions. When it needs to render again, it creates new ones.
It's a single-pass approach - you define your view, SwiftUI renders the body, and that's it. There's no persistent reference to what's on screen. To change state, you must use property wrappers such as @State and @Observable.
This allows SwiftUI to allocate state elsewhere and manage it for you. It handles rendering based on changes to these special properties that exist outside the view itself.
Swift Toolkit
Yeah, the view is just a representation of what you want to build, right? The object itself doesn't necessarily live in the memory for a long time.
Natalia
It doesn't at all! It's allocated on the stack. So it doesn't have references. It's not like a class.
Swift Toolkit
SwiftUI takes care of comparing the trees before and after updates and re-render what needs to be.
Natalia
Yes, it builds a special data structure onto the hood, a graph, which it uses your view descriptions to build that views on that graph that it maintains behind the scenes, but you don't have direct access to those.
Swift Toolkit
And for people that work with SwiftUI, and they are more or less new or overwhelmed by the amount of classes in UIKit. Or they are just used to the magic of SwiftUI, what tips would you give the other way around?
Natalia
Hm, I would say more responsibility is on you. You have to make sure that everything is updated in the right order. If you need to update the state, if you need to update some properties of your view, you have to do it manually. You have to make sure you maintain everything in sync.
In SwiftUI multiple views depend on the same observable, all of them will update. In UIKit, you have to update every view manually, make sure that you don't have disparities in your state across different views.
Swift Toolkit
And nowadays we have plenty of libraries to help us with that, right? If you use MVVM, then Combine or RxSwift can be helpful. Or TCA (The Composable Architecture), which can also be used with UIKit.
You said that initially You didn't like so much dynamic aspects of Ruby, and you missed the Java aspect of more strictness. I assume, as you said, that's one of the things that you like in Swift.
In your view, what else are the advantages of Swift and at the same time, what do you like less?
Natalia
I think Swift is pretty easy to learn, even for beginners. It's also easy to understand someone else's code written in Swift - that was actually what I found difficult with Ruby. With Ruby, you can read someone else's code and it might look like a completely new language because there's so much customization possible.
Swift is more straightforward. Once you learn it, you can probably read any project and understand it easily.
You don't need to know all of the advanced features to use it effectively. There are several features of Swift that I don't really use at all. But I do think it's getting more complicated year by year.
Swift Toolkit
I have the same feeling.
Natalia
It's getting harder for me to keep up with everything. Sometimes there's a feature I've never used, and I decide I'll write an article about it, so at least I have some idea about it if I ever need.
That's how I try to keep up but there is still a lot that yeah.
Swift Toolkit
I have friends that, whenever they want to learn a subject, they say: "I'm gonna prepare a talk about it". And then they go all in and learn.
And regarding tooling with Swift, what experiences you think might be worth sharing?
Natalia
Yeah, I tried using Vapor a while ago. I built a server for in-app purchases with that. It was before I joined Apple. It was a bit hard for me. In the end, I rewrote the server in Node, something like that. It was the early days of Swift on the server.
Swift Toolkit
It was before async-await probably
Natalia
Yes, when we had to use Futures.
After that I started working on my website again and it's also in Swift - it uses John Sundell's Publish package to statically generate the website. So there is no server component for that. It's just statically generated website uploaded to AWS.
For the books website, we have Swift Lambda functions that do a bit of logic, when a purchase happens through Stripe. It processes a purchase, sends an email with the link to the user.
We try to use Swift for everywhere we can use it.
Swift Toolkit
And mentioned your books. Books is an interesting topic.
There's something I haven't shared yet about SwiftToolkit. Initially I wanted to write a book on tooling, and I thought to myself "That's gonna be a huge work, and I'm not sure how much interest there's gonna be in the community for such a book". So I decided to start with a blog.
This way I can publish my content in smaller doses, smaller articles and bits.
So when you choose a topic for a book, some ways it's a bet, right? You hope there's going to be enough interest and that it will succeed. How's the process of choosing a topic for these books that you've written so far?
Natalia
For me, it was mostly about what I felt excited to write about at that moment. This way, even if there's no interest, I've still learned something and had fun writing it.
For my first book, which I wrote immediately after leaving Apple, I chose "Integrating SwiftUI into UIKit Apps", because many developers were interested in SwiftUI, but couldn't use it in existing projects so much. Not many had the opportunity to work on fresh projects.
I wanted to describe ways that almost anyone could use SwiftUI in their existing projects - in widgets, collection view cells, or adding new features without rewriting everything from scratch. My goal was to make SwiftUI more approachable for people working with existing UIKit codebases.
Swift Toolkit
Nice! And the second book, is the one with 100 Swift tips, correct?
Natalia
The second book, "Swift Gems" is focused on Swift tips. I had written several blog posts about lesser-known Swift features, that can make code cleaner or faster. I really enjoyed writing this because each tip is self-contained, you can just implement them anytime, anywhere.
It doesn't require projects, or screenshots. So I thought: "That's a fun thing to do. Maybe I'll just collect them all in a book, and see if people like it. And if they don't, at least I'll have the book for myself, and I can always go back and find all of this great Swift features".
And people liked it! So it worked out well.
Swift Toolkit
And the last book is the new one?
Natalia
Yes, SwiftUI Fundamentals. I felt I needed to write it for a while, just never had an opportunity to do. This year I started focusing on NilCoalescing full time (before that I was also employed part time in a different company). So I had time to do that and it was all in my head for a while. I just needed to organize it and put it on paper, and I finally had the opportunity to do that.
Swift Toolkit
How do you measure your success for yourself? Do you have any goals that you define or you just go with the flow?
Natalia
I consider if it payed off the time that I spent on it. Just thinking of the last salary I had, for example, I spent around two months on this book. Did I earn two months worth of salary on it? Usually, yes, or even more. So it's usually worth putting the effort into it.
But also, if it doesn't work out, it's still okay: I still learned something myself. I still organized and deepened my own understanding.
Swift Toolkit
It's part of a bigger process, for sure!
You mentioned now NilCoalescing, that's where you post your articles. How do you split your time? Because you have books, you have articles. And you also offer client and contracting services. How do you, how do you juggle all that?
Natalia
I usually work on whatever is most urgent at the moment. For books, I set myself deadlines to stay focused and ensure projects don't drag on longer than needed.
I have my partner, Matt, who can pick up work while I'm focusing on something else. For example, while I was working on SwiftUI Fundamentals these past months, Matt was managing our clients.
Until mid-December last year, I was employed four days a week, so I had one weekday plus evenings and weekends for my other projects.
With client work, especially web projects, I typically focus on the front-end while Matt handles infrastructure. He sets everything up, and when it's time to refine the UI, I step in. We complement each other well and can cover for each other when needed.
For the blog, I don't enforce any particular schedule. I just write whenever I have a topic to share or feel inspired. This approach works well for me.
Swift Toolkit
Amazing! I think these are good tips for in general for people who maybe want to start a project on the side, or for people considering going indie.
I'm leaving the links to everything we discussed below.
Thank you so much for your time, Natalia! It was a pleasure talking to you!
Natalia
Thank you. It was nice chatting with you. Bye!