Dev Conversations #14: Antoine van Der Lee
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.
Antoine van Der Lee is the creator behind SwiftLee, one of the most popular Swift development blogs, and RocketSim, a powerful iOS development tool. With over 7 years at WeTransfer and now as an indie developer, Antoine has built a significant following in the Swift community through consistent weekly content and innovative developer tools.
He started his programming journey with ActionScript and Flash, eventually finding his way to iOS development, at an agency. Later on, his transition from agency work to WeTransfer, a high-scale environment, taught him valuable lessons about code quality and collaboration. There, he also contributed to several open-source projects while building the company’s iOS apps from the ground up.
Since 2017, Antoine has maintained SwiftLee with weekly articles, building an audience that eventually enabled him to go indie in 2024. RocketSim, which started as a simple deep link testing tool, has evolved into a comprehensive iOS development suite with over 30 utilities, including unique features like camera simulation and network speed control.
In this episode, Antoine shares his journey from Flash developer to indie success, the technical challenges behind RocketSim’s unique features, his approach to consistent content creation and audience building, and some tips for a successful migration to Swift 6’s strict concurrency.
Also available in your favorite podcast player 
Swift Toolkit
Hey Antoine, how's it going?
Antoine
Hey, how's it going? Exciting to see where we can go to chat about anything.
Swift Toolkit
As I do with all guests, tell me about your beginnings with programming.
Antoine
I do quite a lot of things - SwiftLee, RocketSim and so on. People often ask how I manage it all, especially when I was working full time at WeTransfer with a kid, dog, and chickens.
It's something I built up over time. I'm quite structured - when I go bouldering, I stick to a single route all evening until I finish it. That's my career journey approach too.
My first website was when I was 13, playing a video game. I created an HTML website with a TK domain, then built Flash advertisements with ActionScript. Eventually HTML with CSS became prominent, so I started doing that and wrote PHP, built my own CMS.
That continued until I got an offer to work on Windows Phone. I was like "Yeah, sure! I want to build apps for an actual phone!" Then my neighbor, a colleague developer, was working on iOS. I couldn't afford an iPhone back then, but that's where the real dream started.
Swift Toolkit
The first thing I learned was also ActionScript and Flash. Many developers learned Flash back in the day.
Antoine
Those were the days.
Swift Toolkit
Tell me about WeTransfer - any interesting open source projects or big challenges you had there?
Antoine
When I was at an agency before WeTransfer, I started as a junior and became a senior team lead. At some point I was in my bubble and believed there wasn't much more I could learn.
Then I joined WeTransfer's team - one internal iOS engineer and two externals who worked for Uber and Sketch Cloud before, quite high level. That's when I learned where I actually was with my skills, which was nothing close to what I thought.
The PRs didn't get approved. I used third party libraries for everything - didn't get approved. I really thought I went a step up, but feeling-wise, went three steps back.
I worked seven and half years at WeTransfer until I went indie in 2024. Over those years, we started with nothing - an app built by an agency that was removed from the App Store because the quality was so low.
Antoine
We rebuilt from the ground up, starting with the Collect app. Building that up, I knew every piece of code or at least reviewed it in a PR. For such high scale - the website was serving 80-90 million users - you put an app against it and immediately receive a lot of traffic.
WeTransfer was really into open sourcing. We thought it would attract new engineers and put us on the map as an engineering brand. It paid itself back eventually.
Two really stand out to me. One is Mocker - we built it to mock HTTP requests from URLSession without changing anything in your code. You configure a URL protocol and it intercepts requests, returning the JSON you configured.
The other is Diagnostics, which is truly my little baby. I'm still using it for RocketSim. It's a way for users to report issues, but with that email report, an HTML file gets added showing all sessions, system logs, debug logs - everything I'd normally have during development.
Swift Toolkit
So the support team could use that directly?
Antoine
Exactly. The number of times they reached out to engineers lowered quite a bit because we created smart insights. We parse the logs and when you encounter certain strings, you get a smart insight saying "The user had this error, which is known and we're working on it."
The support agent could read that in the HTML file and directly reply to the user. That's still working today, which is super helpful.
Swift Toolkit
We spoke about SwiftLee already. When did you have the idea to share your knowledge with other developers and what were your goals?
Antoine
I always said to myself, I'm writing for myself and others can benefit - that's their win. There's no pressure for me to put out quality because I'm writing for myself. That really lowered the barrier to just write articles and publish them quickly.
I'm often finding my own articles. Sometimes it's surprising - I'm searching on Google and I'm like "Oh, I wrote about it two years ago."
Swift Toolkit
It happened to me this week. I needed help with server side stuff and searched my own blog.
Antoine
It's the best thing, isn't it? I started the blog officially in 2015. Didn't do much in 2016, 2017. In 2017, I joined WeTransfer and wanted to speak at conferences more.
Even though I worked at what I thought was a known company, I didn't get any accepted proposals. It was really hard to get in. I saw many similar names at all conferences, so I concluded they are known names.
It makes sense - if conferences get known names, they sell more tickets. There's always spots assigned to thought leaders. So I thought "I might as well become a thought leader."
That's when I started writing an article every week, consistently. I still do that - every single Tuesday since 2017, I send out a new article. That really ramped up, gained more followers, more reach, became a more known name.
Antoine
Eventually conferences started asking me to give talks rather than me sending proposals. I would never have gone indie if I didn't start blogging back then. It resulted in a newsletter, sponsorships, reach for RocketSim - my whole business is built around the audience I started building in 2017.
Swift Toolkit
Consistency is the hardest thing for me with kids and a full-time job. Finding subjects too - sometimes you don't have a subject ready. How do you manage that?
Antoine
This is often the difference between wanting to write consistently but failing versus succeeding. You need structure and technique. I used to create a Trello board with all ideas I had to write about.
I look at what I'm building this week - what's high up in my mind in terms of context? Is that something I can turn into an article? Writing such articles is super easy because you're already in that context.
Nowadays I also look at search engine insights - what are popular keywords. I try to pick ones that speak to me in terms of interest. I don't want to write about SwiftUI animations because it's not my best skill, but if I see something about concurrency, which I'm a big fan of, that would be something to consider.
It's structured in terms of when you write. For me, it's always Tuesday morning. I block time to write an article. There must be a super important meeting to not do it Tuesday morning. I did that at WeTransfer, I still do it now as an indie.
Swift Toolkit
If you step out of structure, it's hard to get back. Two weeks ago I went on vacation for a week to the US and didn't publish for two weeks. It was hard getting back to the routine.
Antoine
I go on holiday too. My wife and family know this is my business, so even on holiday, I write my articles Tuesday morning.
Instead of writing a whole new article, which takes more time and energy, I pick an article I already wrote that's outdated. Instead of rewriting completely, I focus on how to rewrite it to be up to date in a more modern way.
That often leads to enough new visitors and feels like a new article for that week. Once again, I'm writing for myself in a way.
Swift Toolkit
Not only that, the Antoine of today is different from the Antoine of three, four, five years ago.
Antoine
Yeah, and Swift and SwiftUI today are different too. That all compounds.
Swift Toolkit
What about tooling? How is the website built and do you have any specific tools around it?
Antoine
I tried to stay away from the rabbit hole called static website generators. WordPress is what I'm using. It's serving 35% of all websites on the web. It's so big, there's a plugin for everything.
Eventually I got sponsors so I could invest in premium plugins. I still statically serve the website via Cloudflare, which makes it as fast as most static websites.
It allows me to focus on what I want to do - writing articles. I don't want to focus on creating a website from beginning to end. I just install Yoast SEO and it does it all for me. You want to optimize as much as possible and buy yourself back time to build things that have impact.
Swift Toolkit
The reason you're here is because of RocketSim and the tooling around iOS. Tell me how the idea was born. There's also ControlRoom, an open source version of something similar.
Antoine
RocketSim started in 2019. I was working at WeTransfer and we had many different file transfers to test every time. I created an HTML page with a simple ordered list with all those links of transfers that would be universal links opening the simulator.
But you open a different simulator, you don't have that HTML link in your Safari history, you need to type it yourself, open it in Safari, click the link - it's repetitive and slow.
That's when I figured Apple provides a tool called simctl - a terminal command line tool with an action to open deep links. I might as well create my first Mac app and see how Mac development works.
That was the first version of RocketSim - a simple status bar app. You're right there are many open source tools available, but it was fun to build and I figured I could make other developers more productive.
Antoine
The first two years, I didn't make any money with it. I think lifetime was like $10. I still had lifetime back then - I don't anymore. The main goal was finding things that are cumbersome and making them easier to use as an iOS engineer.
That compounded into many more features. Today, RocketSim offers about 30+ utilities for the simulator, including many features that no competitors offer.
Swift Toolkit
You did camera support recently, right?
Antoine
The funny thing is I started in 2019 and some features I already had in mind then, but I had no clue how to build them. You start diving deeper into the whole world of simulators.
I even had a chance to talk with Apple developers who work on the simulator. They gave me some internal insights. You build up knowledge that isn't necessarily available online or that ChatGPT can tell you - it's really niche knowledge you build over time.
That allowed me to build features based on internals, like network speed control which slows down the network for just your app while your Mac connectivity remains fast. It's like a network link conditioner for the simulator.
The camera on the simulator doesn't work - it opens a black screen or sometimes doesn't do anything. I thought that's so stupid. Why didn't Apple build this? What if I can stream the Mac camera and use that as input for the iOS camera?
Antoine
I finally figured out how to do it after years. It works a little too good - the simulator thinks there's a hardware device connected, so it tries to connect and there's a five-second delay before it times out.
I had to swizzle the start running on AVCaptureSession and let that run on a background thread instead of being blocking to make it feel instant.
One of the largest camera apps tried it out and is even considering it. Think about it - if you have an app focused on camera functionality and always test on actual device, but now you can use the simulator, it's a game changer for productivity.
In the future, we want to allow pre-recorded videos streamed to the simulator. If you have CoreML features to recognize something in a video, you can film that car outside and use it constantly for development.
Swift Toolkit
That's a game changer. You could also offer tools for testing - maybe mocking video streams could make testing easier.
Antoine
One request I often get is command line interface or shortcuts integration or MCP. Imagine the network requests - when I offer that data to AI, you have a bug in your app, you could ask AI "These are the requests RocketSim captured. Can you look into the responses and see what's wrong?"
That's the next level simulator development. I have tens of big major features I could build and I'm constantly picking the ones that are high impact, low effort.
Swift Toolkit
Do you have interesting stories about technical challenges that were hard to get done?
Antoine
The network speed control - I had that in mind forever because I knew the network link conditioner, but had no clue how to build it. I eventually found out and it took like a day to actually build. It was really the whole route towards finding out how it works.
Several chats at WWDC, posts in Apple forums, going deep into the kernel to see how Charles proxy works - basically building up knowledge until you find it.
The funniest story is about simulated camera. I went debugging on an actual device, started logging private API methods to gain insights into how AVCaptureSession logic works, ran into issues, found private header files on GitHub.
Had a proof of concept, went to WWDC, talked with engineers who work on the framework, impressed them with the proof of concept, asked how this works internally. Many engineers don't tell you anything, so you get little pieces of insights you need to put together.
Swift Toolkit
It's a puzzle - you have to assemble things.
Antoine
You can search for "macOS streaming for simulated camera" on Google, but nobody built it. You're reinventing something. You can't rely on anything - there's no open source example.
That's the general story with RocketSim. There are many open source alternatives that build a UI around simctl, but the features that RocketSim truly made a success are the features I've built that aren't available in open source.
Swift Toolkit
That's the big differentiator for you. How do you tackle marketing? As a developer, you know how to build an app, but you weren't a marketer before.
Antoine
I'm not the best marketer, I can tell you that. I think I'm super lucky, but it's not only luck. I built an audience and stuck to that single audience.
I'm not creating a soccer app, camera app, and social media app where I have to build an audience three times. I have a single audience - if I improve my newsletter and gain more subscribers, it's likely I also gain more RocketSim subscribers.
The majority of new users come from either SwiftLee, SwiftLee Weekly, or my social media. There's also developer relationship managers at Apple, going to WWDC, hanging out in the community, going to conferences.
The key takeaway is invest in more places where your audience exists. Start a newsletter for your target audience. Work together with influencers targeting your audience - get yourself an Antoine, in a way.
Antoine
We can clearly tell RocketSim has product market fit - the majority of teams that start using it continue using it, renew, buy more seats. But getting into new teams and finding paid acquisition is something I still haven't succeeded in.
It's surprising if you think about it - the LTV per user is quite high, churn is low, so there must be a success path there. That's where the biggest challenge lies now.
It's easy to become lazy because there's organic growth, but I feel like true growth lies in getting more users via paid acquisition and marketing. If you're listening and have golden tips for me, that's still something we're trying to figure out.
Swift Toolkit
To wrap up, the episode with most views was with Matt Massicotte about Swift concurrency. What would be your tips for someone struggling with concurrency or feeling behind, besides learning the default documentation by Apple?
Antoine
This is proof I'm bad at marketing - I didn't even mention I have a course on Swift concurrency.
Swift Toolkit
That wasn't planned, I honestly didn't plan that. I think as I was asking, I remembered, but it's relatively new, isn't it?
Antoine
Yeah, it is. I have the audience and figured building courses is in line with writing articles. I look up to Matt in many ways - he's great, gives workshops, super knowledgeable in this space. I learn a lot from him. Shout out to Matt!
Make sure you follow his content by subscribing to his blog or my newsletter - I mention him there too. The WWDC videos of this year are super great in telling what's new in Swift 6.2.
I wouldn't even look back before Swift 6.2 because there are so many groundbreaking changes that make concurrency much more approachable.
Antoine
Concurrency is a big thing. It's not easy to wrap your head around. It's doable to use AI for it, but AI is not up to date with the latest Swift 6.2 changes. Even though AI and Xcode with integrated AI can help, you still need to be aware of what exists.
Invest in your knowledge. Look at the WWDC videos, look at my course - I think it's valuable too. It has 65 lessons and I'm still adding new ones. There are many great free articles out there too.
Make sure to use it. If you start a new package or project today, make sure it's Swift 6.2 from the get-go with strict concurrency. That forces you to get used to it and doesn't grow your tech debt.
Swift Toolkit
If I can add my own tip - if you have a very modularized app, you can start making the lower frameworks support strict concurrency, then it's easier to do piece by piece. When you finish a layer, go to the upper one. If you have a single target app, it's much harder.
Antoine
I created a migration module in my course with migration habits. One tip I give is what you mentioned - find an isolated part, ideally a package without dependencies.
If you have a package with dependencies and update it to Swift 6.2, maybe add more async/await methods, all dependencies need to work with that new isolation. You might need to add actor isolation in many places.
If you have an isolated package nobody depends on, that could simplify the migration and get yourself up and running with new knowledge. There's migration tooling that works great for packages too.
The non-isolated, non-sending is newest with 6.2 - quite an important change. You don't want to do that manually because you could introduce new threading behavior that breaks your code. Let the migration tooling do it for you.
Swift Toolkit
Antoine, this has been really insightful. Thank you so much for sharing your journey and all the technical details behind RocketSim.
Antoine
Thanks for having me! It was great chatting about all this stuff.