Hi, and welcome to the 30th episode of my podcast. My name is Leenarts. And I've been doing this podcast for quite a while now. And today I'm going to do something a little bit different than what I usually do on my Monday recordings, I'm actually going to talk about a specific topic. And the the topic that I'm going to talk about is on iOS dependencies, dependencies is something that we all have to deal with in our code bases. So if you develop some software on iOS, you can use something called a dependency to get a framework or a library from a third party provider into your codebase. This helps you because you don't have to write the code yourself. But it also has some risks that are involved. And recently, there has been some discussion online about the topic of dependencies in iOS code basis, should you use them? Or should you maybe not use them. Of course, there are situations that you have to use a specific dependency, for instance, a third party framework provided by a supplier that allows you to actually connect to the platform. For instance, the Firebase SDK is a great example of that you can't use their tool chain, if you don't integrate with their SDK. But there are cases that you also pick up a dependency because it is convenient, it saves you some time, and it allows you to not have to write the code yourself. Of course, dependencies is something it's in the name, it's a dependency, you depend on the appointment. So there are some risks involved and the risks that I personally oversee with the with these dependencies it that is that there are situations that they can become are unmaintained, they contain code that you do not need. And this can create various issues amongst them security issues, because there's an increased attack surface, but also functionality that might cause strange behaviors in other parts of the code base. And also, its code. So there will be bugs involved. So how should you deal with bugs in dependencies. And also, when dealing with dependencies, there's a big difference between when you create more like an agency style project. So that's something that you work on for like maybe two months, or if it's a code base that you have to maintain for months, or years to come into the future. And it's, it's a balancing act really, personally, on the projects that I work, we really have a strict policy against introducing dependencies. And also we actively try to get rid of dependencies. So that's completely on the one end of the spectrum. We don't want to have dependencies, or at least as few as possible. Why do we do this? And the reason is quite simple. It's of course, a little bit, not invented here syndrome. But also we've seen in the past with this project. That's the impact of code becoming unmaintained or bugs in the code or complexities in the dependencies that we don't want to have entered, we definitely don't need is, is more of a cost to us than actually creating stuff for ourself. And, of course, it's it's a gradual thing that happens, because like two years ago, we had like a lot more dependencies. But slowly, but surely, we've been getting rid of all these dependencies. And actually, we've also gotten rid of one of the biggest third party dependency managers, which is cocoa pods. Talking about dependency managers, there's a number of options out there for iOS and Xcode based code bases. And, yeah, it's really up to you to decide which one you like which one you prefer, I do know that a CocoaPods is the easiest to get started with and to to find actual dependencies. Because what CocoaPods really does is it also provides like a great index. And by chance, de fer is also creating a Swift package index that should provide a similar similar solution that the cocoa pods index provides, because if you go to coke bottle.org, you can actually search for dependencies and get, get an overview of what is available. But, again, a third party dependency manager is also again, a dependency, it's not a dependency on your code base per se, in the sense that it's something that you deploy and put in production, but in the development process, it is dependency. So if you have a build server or you get a new person on the team, it's something they have to have on the machine to actually be able to compile your code. So something to be aware of really, that the dependency manager itself is also a dependency. So what should you do in these cases? Should you rely on dependencies should you actively try to avoid using dependencies? Well, that's hard to say, in a broad sense, but I do think it is good to be aware of what dependencies are in your code base, and whether or not you want these dependencies in your code base, because really try and look at the quality of the products, the amount of people that are using a specific dependency when selecting one. Or if you pick a specific dependency that is not widely used, make sure that there is a small piece of code that you can inspect front to back and that you can understand entirely before you actually integrate it in your code base. might sound like a bit of a hassle, but in my experience, it's always good to be familiar with all the codes that is available or use in your product. So these are my thoughts on dependencies. I'm still trying to create a more concise position on this and maybe in the near future. I will spend some more time talking about this in other formats and with other people. I hope you liked it and talk to you soon.
