Interview: Carola Nitz
We talk debugging, mentoring, media players, and more.
Carola Nitz is best-known to many people for her influential debugging presentations, but she’s also worked on the Maps team at Apple and now works on the iOS app for the massively popular VLC media player.
With such a wide range of experience working both in open- and closed-source software, I got in touch with Carola to ask for her advice on debugging, legacy code, mentoring others, and more…
Hacking with Swift: VLC recently passed three billion downloads across all platforms, making it one of the most popular pieces of software ever made. What led you to join the team?
Carola Nitz: I initially started contributing to VLC back in 2013/2014. The reason back then was to get involved with a project that was written in C/C++ to not lose the knowledge that I got from my first job. But as soon as they found out that I’m an iOS Developer I got dragged over into that part of VLC!
I found myself building the Google Drive integration, moving the project over to use CocoaPods, broke VLCKit with the first commit to move over to ARC – which led others to finish that works and many other things over the years. I was just starting out as a junior iOS Developer, not feeling as if I had a lot of impact with my work, but VLC gave me exactly that. Seeing that something that I’ve build was used by a significant amount of our users and even became so popular that it was newsworthy definitely encouraged me and fueled my urge to learn and build more.
“There was a whole new world that I didn’t know existed until I joined this open source project and it helped me grow so much as a developer!”
Additionally VideoLAN, the non-profit behind VLC, regularly flies all of their developers into different cities in Europe to collaborate and I was able to get in touch with brilliant people from Google, Nginx, Vimeo and all sorts of interesting companies over the years. There was a whole new world that I didn’t know existed until I joined this open source project and it helped me grow so much as a developer! Since everything was open source I was able to point other developers to code when they asked, helping me to share my knowledge and additionally get feedback from others on how to improve myself.
I underestimated how much all that meant to me when I joined Apple, which funnily also happened because I was referred by a former VLC developer. While I enjoyed my time at Apple a lot and learned so much, there was still this hurtful feeling of not being a part of VideoLAN anymore, not being able to contribute and share my knowledge, which at some made me so sad that I left.
I didn’t plan on working for Videolabs when I left, I thought I would just contribute like before with a different full-time job. But JB [Jean-Baptiste Kempf, president of VideoLAN] immediately gave me contracting work, without me having to interview and what at first was a supposed to be an interim solution became my main client that I work for remotely, who’s again flying me around the world to represent VLC and allows me to once again give talks at conferences and the ability to work on an App that goes out to more than 20 million people in the world.
HWS: The iOS app is hugely popular in its own right, but how do you coordinate development with other teams to make sure common goals are achieved?
CN: Many people will be surprised to hear this but we’re a fairly small team. On iOS we have two full-time developers with the occasional external contributor, and on Android one, but on the core we have a bunch of developers with 20 people having more than 10 commits in the past year, which partly intersect with all other platforms. We have ~2 developer for dev ops, 3 people on Mac and one for .net and Windows mobile. We’re organizing ourselves with a system called Trac but aim to move over to gitlab at some point.
“On iOS we’re reworking the UI which takes longer than anticipated as always”
The core pretty much determines the big release cycle and what functionalities are added and just last year we brought every platform to release 3.0 and with it features like 360 videos, Chromecast support and Ambisonic sound. Before Android had 1.x iOS 2.x and it was hard to understand which version had which core features. For platform-specific features it’s pretty much up to the developing team and we discuss possible features when we get together.
Other functionality is sometimes the result of client work, when we see that a certain number of people is missing functionality, we build it for them but then make it part of the core. Luckily, since I work on open source I can talk about everything! Interesting projects at the moment include dav1d, a fast AV1 decoder, and on iOS we’re reworking the UI which takes longer than anticipated as always. If you want to see what will change with 4.0 you can take a look here: https://github.com/videolan/vlc/blob/master/NEWS
HWS: VLC is well-known for working well on a number of platforms – do you get much chance to work outside the Apple ecosystem?
CN: I don’t venture away from the Apple code very much. I need to edit from time to time some patches for VLCKit which is the wrapper for the core library libvlc and those would entail writing C code, but often enough I ask coworkers to do it because understanding the inner workings of libvlc takes time. I get to look at the Android codebase from time to time and I do attend a lot of open source and media-related events – but that’s pretty much the extend of it.
HWS: With such a popular app, you must have a pretty strong setup for continuous integration and testing – can you walk us through what you use and why?
“As you heard we don’t have many developers, which leads to people directly committing to master with occasional patch reviews.”
CN: To be quite frank this is an area where we still need to improve. As you heard we don’t have many developers, which leads to people directly committing to master with occasional patch reviews. We always had nightly builds that tested the different platforms once a day so that they build, but when I joined full time there wasn’t a lot in place and even VLCKit was build on a private laptop.
In the last year we added a lot! VLCKit is now built by Jenkins on a clean build environment, we added pull requests for our GitHub mirror, and this year also on our private GitLab. With pull requests we were able to put CircleCI in place to check every commit for build breakage before it lands on master. We didn’t have any tests until last year, but since we really want to change that I mentored a Google Summer of Code project to add a test framework around VLCKit which added the first tests and a code coverage report. We used XCtest for this, but we still have so much to improve in this area!
For iOS and tvOS we at least added a test sheet last year that we go through prior to every release to make sure we’re not breaking core functionality, but I hope to automate that as well in the near future. Sadly with two engineers managing apps for iOS, tvOS, and VLCKit + client work, our time is very limited and this is the part that doesn’t get as much time as it should.
HWS: VLC for iOS and VLC for macOS look like completely different products, but now that Apple is moving towards giving us tools to ship UIKit apps on Mac do you see a grand VLC unification coming?
“I personally believe that React Native, Flutter, or any other cross-platform solution is not a great choice for an app that needs to be very performant”
CN: They are completely different apps besides the core at the moment but we’re trying to move as much as possible to shared components, and one effort of that is to have a shared media library. A grand unification is unlikely. We’re not going through the App Store on Mac and there are many reasons for that – from using GPL-licensed code over to certain APIs that would never pass the review process. I would really like to port our iOS app to macOS and might do it just for fun at some point, but nothing like that is planned officially from VideoLAN and it would result in a light version of the current VLC for Mac with a limited feature set.
I personally believe that React Native, Flutter, or any other cross-platform solution is not a great choice for an app that needs to be very performant or cautious of memory usage. As with every cross-platform solution you add another layer of complexity, and we need to be as close to the hardware as possible because video playback is one of the most performance-intensive things you can do on a mobile device.
We definitely see the effect that Netflix, Amazon, Hulu and co have. The need to get video content yourself and play it has declined, and with that the need for a desktop video player. VLC is still going strong because we’re way more than just a player but we also see increasing number on our mobile ports.
HWS: VLC is unusual in that it has both a corporate side and a large open-source side. How much do you get to work with the wider VLC project?
CN: Actually I wouldn’t say it’s unusual. Many open-source projects belong to a bigger company and have a corporate side – it enables passionate people to work full time on a project they love. I’m looking at Firefox and Mozilla, Travis CI, and Swift at Apple. I constantly get to work and meet with the VLC community; the biggest events for us are certainly FOSDEM in Brussels which is just coming up and the other one is our own conference the VideoLAN Developer Days, where everyone comes together and collaborating. I see these events like family reunions in a way, and I learn a lot about other projects within the community that I otherwise wouldn’t know about.
HWS: You mentioned that you acted as a mentor as part of the Google Summer of Code – how did that go for you?
“I had my proudest mentor moment when I learned that the student that worked on the test framework got a job at Apple on the testing team”
CN: I really, really love Google Summer of Code and I got to mentor two students last year. It’s one of the most gratifying things to teach and help others grow. One of my students integrated the C-based media library into our iOS app successfully, and another built a test framework for VLCKit last year. It was a big learning experience for me and it challenged me to rethink a lot of the choices we made in the past – in a good way.
My biggest take away is that having one-to-ones on a weekly basis is the best thing you can do for your students and yourself. Even though you’re available online it takes still a lot more courage to reach out than asking something during a video chat. It improved communication a lot and helped me know where things where blocking current work. I had my proudest mentor moment when I learned that the student that worked on the test framework got a job at Apple on the testing team, and I can’t wait for this years GSOC. If you’re a student and interested in participating this year please let me know!
HWS: I first encountered you on a YouTube video delivering what I think was the earliest talk about debugging Swift code. Of all the debugging advice you've given folks, of all the tips and tricks you've discovered, what are your top three tips for helping folks find and fix bugs faster?
CN: OK! First, use Charles Proxy to see what requests and responses you really receive and send. Second, make use of symbolic and exception breakpoints. You know where Auto Layout breaks, why the app is crashing or what code is calling a certain function. And third, changing variables at runtime in lldb is the biggest one. You don’t need to restart your app and can try changes immediately – it’s a huge time saver!
HWS: More recently you've been speaking about legacy code – more specifically, how to work make changes with confidence when working with a large, mature project. How much of that came from your experience at VLC?
“That’s when you realize how important it is to have tests, documentation and automation for anyone who is joining your project – and also just for yourself.”
CN: A lot came from working with VLC. The iOS codebase alone without Pods is currently at 38,241 lines but when you add VLCKit and alike we’re at 280,404 and this app was one of the first ones to hit the App Store! I didn’t know about all features of this app until I broke a few of them while refactoring which inspired me to give this talk.
A lot of time was spent in the past year with refactoring the app and that’s when you realize how important it is to have tests, documentation and automation for anyone who is joining your project – and also just for yourself. No one can remember everything! The code base is improving a lot and I look forward to spending more time on new features again, but until then books that I can recommend and who are still helping me these days are Working Effectively with Legacy Code by Michael C. Feathers, Beyond Legacy Code by David Scott Bernstein, and Refactoring by Kent Beck and Martin Fowler.
BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.
Sponsor Hacking with Swift and reach the world's largest Swift community!
