Dev Conversations #12: Bruno Rocha
👍 0
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.
Bruno’s first moments with programming were with Flash and ActionScript, and a few years later, when deciding what to study, he didn’t choose Computer Science: he went instead for game design. After working on it for a while, his interest shifted into iOS Development, when he joined an Apple Developer Academy program.
When working in Brazil’s leading food delivery app, he had a chance to work on the infrastructure of the app. As a team of more than 30 iOS developers, the regular approach with Xcode didn’t scale well, and that’s when Bruno had a chance to implement a better modularization, and a new build system: Bazel. Being one of the first companies in Brazil to adopt Bazel (if not the first), it forced him to learn about it on a deeper level.
Bruno shares these learnings, amongst other types of work he faces nowadays while working at Spotify, on his SwiftRocks.com blog. There, you won’t find the typical UIKit/SwiftUI content, but rather posts related to the Swift compiler, reverse engineering, git internals, and other advanced topics in the world of Swift, iOS, or Software Engineering as a whole.
In this episode, Bruno shares a bit of his story, from Brazil to Sweden, from game design to iOS development, and as a developer tooling and infrastructure engineer at Spotify. We also talk about his contribution to Swift with the SE-290 proposal (and its implementation in Swift 5.6), his open source projects, and what motivates him to understand deeply how things work under the hood.
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 Bruno, how's it going?
Bruno
All good, thank you, happy to be here and chat about Swift stuff.
Swift Toolkit
Of course, happy to have you here! As I always do, tell me a little bit about your first steps in programming.
Bruno
I started programming when I was a kid. Basically, I was a huge fan of those old Flash animations back when it still was a huge thing. I think the first thing that I tried was playing around with Flash a little bit. I remember my dad gave me a programming book about ActionScript at the time.
Then I started doing... I was always a video game fan, so I was always trying to play with RPG Maker, that was an engine from 20 years ago that you could make a sort of Final Fantasy clone with very little to no coding. I think those were my first steps with programming.
And then when I became an adult and I started getting into iOS development, that's when I started learning real programming.
Swift Toolkit
Do you have any formal academic background?
Bruno
Yeah. So I did game design actually because I wanted to work with game development and I hated the idea of having to study theory - algorithms, data structures, this sort of stuff. Now I really regret that. But at the time I thought that way.
So I went into a game design course that we had in a university in my city in Brazil because that was a very practical way to learn, not just programming. So I could start learning game design as quickly as possible, which was the thing that I wanted to do. And there was no theory involved.
Other than that, after I left that, I worked a little bit with games. But then I decided that I wanted something more stable in my life because the games industry is quite tough. So I had an opportunity in my city to do the Apple Developer Academy where they teach people iOS development in Brazil and in some other countries too. And I was accepted into that and that's how I moved into iOS.
Swift Toolkit
Was it already Swift?
Bruno
It was in the very beginning of Swift. I think it was maybe Swift 1 or 2. So I started learning Objective-C at this course, but very quickly we switched back into Swift. And I was happy for that because I think having a base in Objective-C is actually quite helpful for iOS even nowadays with all of the layers being in Objective-C. So I think that was a lucky thing on my front.
Swift Toolkit
Yeah, I totally agree! I share some stuff in common - programming for Flash and playing with Flash was also my first experience and I also learned by myself programming in Objective-C. And tell me, so your first real job was...
Bruno
So it depends if we're talking about the game world or the iOS world. There's this company in Brazil called Movile. I think actually today they're called something else. This was a really long time ago. But they were a holding company for a bunch of other companies, one of them being iFood, which at the time was the largest food delivery app there.
And they had a really big app with lots of developers. And it was probably one of the only places in Brazil where you could actually work at that type of scale. And probably we were one of the first, together with some other companies that were similar to us, to actually bring some of these concepts to Brazil because very few people were actually working at that size.
Swift Toolkit
How big was the iOS team there?
Bruno
I would say close to 50.
Swift Toolkit
What was the consequence of having such a big team and how did you handle that?
Bruno
So when you get to this kind of scale, this is where you start to notice that what we usually learn for iOS development doesn't really apply. Because a lot of the tips that you learn and what you see in those tutorial websites and so on, everything is geared toward smaller-scale apps, maybe you have five people working on something and that's the entire company.
But when you go to more than 50 things change a lot because a lot of these processes don't scale very well, especially Xcode. So probably the biggest example is that companies at this level don't actually use Xcode at all in terms of building. You have the IDE because you don't have much choice, but you don't actually use Xcode for building.
You use either at the time you had Buck and Bazel, today people just go straight into Bazel. They don't look into Buck at all. So you have all this sort of custom infrastructure. And in Brazil, we didn't really have anyone who did that that you could copy. At the time of iFood, we had to research all this stuff ourselves. And that was quite a fun and challenging experience.
Swift Toolkit
What can you tell about introducing Bazel in an app that is standard, 100% Xcode based? And for those who don't know, what can you also explain a little bit about Bazel?
Bruno
Yeah, so Bazel is an alternate build system. When we say Xcode, we are usually referring to the whole package, the IDE and the building. But actually, these are different things. You have the IDE Xcode, which is where you write the code. But you also have the Xcode build system, which is what gathers your files, processes the dependencies, and provides you with the final binary.
The problem with Xcode is that it's sort of designed for very small projects. If you get to certain scale, you will notice several flaws with Xcode. First of all, Xcode doesn't really do caching very well. So if you have multiple projects and you have libraries that are shared between these projects, what you want to do in practice is that if you compile a library for one project and then you move to the other project, you want to reuse this cache. Xcode doesn't really do that very well.
Another problem is that Xcode doesn't let you do remote caching. So if I build something here on my machine, then in theory, if you, Natan, build something on your machine that is exactly the same thing, you don't have to do that because I already built it. So I could transfer this cache to you and then things are faster for you.
So there are lots of things that we can talk about and these are things that Xcode doesn't do. But when you go to a certain scale, you start needing those things. And this is what Bazel is. It's basically an alternative build system built by Google a long time ago that is essentially built for this type of scale. The downside is that it's very tricky to maintain. So this is why you don't see this being recommended overall, even though it sounds like a good idea. It's very hard to use. So people usually only do this at large companies because you generally need very specialized teams to do this.
Swift Toolkit
From there you moved on to Spotify, right? Which is where you're currently at.
Bruno
Yeah, I moved to Spotify five years ago in 2020, just before COVID. And I joined to essentially do the same thing. I joined the platforming division.
I started working more directly with iOS, which is what I was doing in iFood, so taking care of the architecture of the app itself and those infra-ish details, but very specific to iOS. And nowadays I do something more general. I take care of infrastructure, period. So not necessarily the iOS app, but the entire repo and all of the other client offerings that we have. So the Android app, we have a C++ layer that connects everything, this sort of stuff. So nowadays I'm at the level of abstraction lower than what I used to do.
Swift Toolkit
And what things fascinate you the most?
Bruno
So I always really enjoy understanding how things work under the hood. And when you work with this sort of platformy thing, you have a lot of space to really look at how things work under hood. How does the Swift compiler handle a specific type of thing that you write in the code? How does that actually translate to the binary? What are the steps in between? How is the compiler involved? What are the flags involved into this? How you can modify this?
Because when you're trying to make the builds as fast as possible or make the binary as small as possible, you end up getting into this sort of rabbit hole. And personally, I'm lucky that I actually enjoy this sort of stuff. That's part of how I even started a blog is just looking into how things work in the compiler and then taking notes of it and then publishing it. And in this job, I'm basically paid to do this sort of stuff. So it's very fun.
Swift Toolkit
And how do you begin this? Because it's not a standard programming routine, right? Which tools do you use and what is the cycle? When programming for iOS, let's say you build your view, your view model or your models, the controllers, and you iterate over it. How is the cycle for this kind of work?
Bruno
I think the tooling is not so different, it's just what exactly you're looking at. So for example, if I'm trying to optimize cloning in the repo, so I just want cloning to be fast. It's not necessarily a matter of that I'm coding something else. It's just the nature of the research.
So if you're doing iOS things, you would go to Stack Overflow, you would search your problem and then you have your whole discussion there. The difference here is that I have other places to look at. Maybe I have the actual Git source code on GitHub. I look at discussions from a really long time ago where they mentioned change logs and certain stuff. There are different Slack workspaces for this sort of stuff. There's a big Bazel Slack, for example, with a lot of people from big companies there you can have some interesting discussions about this kind of work.
But there's also a lot of reverse engineering work that I do and that will actually answer your question. There's, for example, one tool that I use a lot that's called Hopper, which is a disassembler. So when I have questions, for example, how is Xcode doing this thing when I press this button, I look at the assembly code and I try to piece things together based on this tool, which helps us retranslate assembly back into something that is kind of the original source code, but not really.
So there are lots of things like that, and also I actually have it right next to me - there are lots of books about this sort of stuff. This one is called The Art of Mac Malware. It sounds completely unrelated but usually these sorts of books tell you how Mac works, so if you're trying to debug things and understand how things work, these resources tell you how to do this sort of stuff. So that's also how I learned a lot of things related to this.
Swift Toolkit
This book is in your list of book recommendations, isn't it?
Bruno
Yeah, I read the first one. This is the second edition. I'm still trying to get through it.
Swift Toolkit
You have one Swift evolution proposal that was accepted and implemented. SE-290. Can we talk a little bit about that? How was the process and how did you implement this?
Bruno
Yeah, I guess that must be the availability one. Because I have done a couple of things for Swift mostly on the indexing part because I had this project called Swift Shield that relied on that. So that's a little bit of how I got to know a little bit of the Swift compiler.
This thing there, the context is that we were trying to do what at the time we called a reverse availability check, because I don't remember what exactly I was working on at the time, but I remember we had something in the app delegate that we wanted to do a check, not if something was available, but if something was not available. But this was not possible in Swift because back then, I think it's not the case anymore, you couldn't store the result of availability into a property. You had to actually just write the whole thing.
And then I figured out, this is an interesting project to learn more about Swift. So I opened up Xcode, I cloned the entire source code and little by little using those debugging tricks that I was mentioning from these resources, I kind of started piecing things together and eventually I was able to do it. It took a lot of reviewing work from the Apple folks so I certainly wouldn't be able to do it alone. But yeah, it's an example of if you put the time to understand how things work, you can really work with this type of stuff even if it looks extremely complicated.
Swift Toolkit
And you mentioned Swift Shield - this is the next topic I wanted to talk a little bit about.
Bruno
This is something that I don't do much of anymore, but back then, more than five years ago, I was using open source projects as a way to just learn more about coding in general, just practice. And one project that I had was this thing called Swift Shield, which was basically the first, I think, code-based code obfuscator for iOS.
So you get your entire source code, you run that, and this thing will actually just make everything gibberish so that you can publish on the store and then people have a hard time getting through that. And the reason is because if you know a little bit about Objective-C, you'll learn that all of your function names and classes, this sort of stuff, it gets shipped into your compiled code. So it's very easy for someone to inspect how your code works.
The way I implemented that was... in the Swift compiler, they have this thing called SourceKit, which is basically the indexing engine. It's the thing that if you pass a certain piece of code, it will tell you what that is. This is what does the code completion and highlighting in Xcode. So when you see everything painted correctly, what is doing that in the background is this thing called SourceKit.
And you can use that separately. So I found a way to do that. I was able to grab something that compiles your app, run everything through SourceKit so I could tell, this class is used here, here, and here. Okay, so I'm gonna replace all of this with some gibberish, essentially. But the thing is that SourceKit is not perfect. It works to a big extent, but there are some issues in the database that it produces. And eventually I got tired of Swift updates breaking the tool because they used to change SourceKit all the time, add new Swift features and this would cause bugs.
Swift Toolkit
And what are you working on right now?
Bruno
Yeah, so what I'm working right now, I haven't officially publicly announced this, but the repo is public, so it's already out there for everyone to see. I'll make a bigger announcement sometime next week. But what I have been playing around recently was precisely with the idea of not needing to use Xcode anymore for iOS development, because for companies of our size, this is little bit of a problem.
The reason this was not a thing is not because necessarily Apple didn't want it to, it's just that nobody pieced everything together. Because Apple always had the Swift Language Server Protocol, the LSP, which is basically what modern IDEs use to add functionality for certain programming languages, and Swift always had that. So you could always use Swift for VS Code, Cursor, this sort of stuff.
It's just that the LSP itself was hard coded to only work with the Swift Package Manager. So you couldn't use it for iOS development specifically. But what happened is that last November, Apple actually opened this up. So you can now sort of hook the LSP into something else that they call a build server protocol.
And as long as you implement this build server protocol correctly, you can make Swift work with anything on any IDE that supports that. So at Spotify, we built this, including iOS.
Swift Toolkit
Including iOS, right? Because we had, for example, we have the official Swift plugin for VS Code or Cursor, but it doesn't support iOS, that's what you're saying.
Bruno
Yes. Yeah, so the plugin installs the LSP, but the LSP by default is on the Swift Package Manager. But if someone builds this thing called the Build Server Protocol for Xcode, which people have, you can find it already on Google, then you can actually use that for iOS on those IDEs that have those extensions. It's the building part, but in theory, yes, you can build those abstractions.
Swift Toolkit
And launching simulators and so on.
Bruno
But what we did at Spotify was to build one of these for Bazel specifically. So it's on GitHub already. We will announce this better sometime next week. But using this, you can actually build Bazel-based iOS projects in any IDE that has those LSPs. So in my case, I use Cursor.
So if you're doing something that doesn't require very specific Xcode tooling - those memory debuggers, you have the SwiftUI previews and this sort of stuff - if you're just working more generically and you don't need those special things, then with this tool, you can just skip Xcode entirely.
You can have all the building, the simulator launching, the LLDB debugging, all into, in my case, I use Cursor, but this will also work in VScode and probably a bunch of other stuff too, even Sublime Text if you have the LSP plugin. So yeah, this is something that I'm very excited about because personally, I never really liked using Xcode at scale.
Some people enjoy it, but they are probably on smaller projects, which is Xcode's main focus and for that for sure it works very well. But on larger projects it's just a mess. The entire format of Xcode projects is very hard to deal with at scale.
Swift Toolkit
Yeah, it doesn't scale so much. Yeah, congrats on such an achievement. And to wrap up, if you could leave some tips for people who want to get deeper on software engineering at all and Swift development, tips?
Bruno
Yeah, something that I always say, even on many of the posts that I wrote, is that there's a huge benefit to learning how things work under the hood because it helps you make more informed decisions. People talk a lot about, this API does this, this API does that, and what should I use? And often you can find out the answer to those things by just knowing what happens under the hood.
If you just use what's given to you without regards to what actually is enabling that to be possible. You can code, everyone does that, but you don't really know what is going on. So you can say that you have control over what you're doing. But if you take the time to actually understand things, you will see that you can develop some pretty powerful stuff and make some very strong optimizations on your code and just be able to do anything really.
Tips on how to do that. I have a couple of book recommendations that teach you this, more for macOS specifically, it's just so you know how to debug stuff. If you want to look at how some software was built, you can decompile things, debugging tricks. What else? Terminal tricks. There's a lot of really good terminal CLIs that are already installed on your Mac, but nobody knows because it's very underground stuff, but also very powerful for development.
I have this thing that I use a lot that is called pgrep which is basically, it's the same as looking at the process list, which people might know as this "ps aux" for looking at what's running on your Mac, but it's for just very quickly locating instances of certain programs. And then with that result, you have the identifier of a program. And then with that, you can just do infinite other things. You can inspect the state of the program. You can look at what the program is doing under the hood, which file descriptors they are looking at, which is just this whole other topic. So it just goes forever. The types of things that you can learn with this.
Swift Toolkit
Anything else?
Bruno
I feel curiosity is a very strong motivator for some of this stuff.
Swift Toolkit
Totally! Thank you so much Bruno. Bye bye!
Bruno
Thank you, Natan! Bye