iOS developers have had it lucky when it comes to security concerns. For starters, we get to develop against one of the most security-minded platforms in the world; however, that doesn’t mean that we should let security slip by the wayside. Instead, iOS developers should carefully consider their tooling, third party code packages, and so much more.
One such careful consideration of security on iOS was brought to our attention again this month with the security breach found within the CocoaPods package manager. CocoaPods has never fully been adopted by the iOS developer community at large, with many developers choosing to specifically not adopt the package manager solution over Xcode project corruption concerns and other risk factors.
This hack was a security flaw that allowed malicious actors to claim ownership over pods and be able to essentially redirect a developer when downloading pods to download malicious code that could then get bundled into an app.
We certainly don’t want to discredit CocoaPods a developer tool solution, but this hack shows that choosing your stack, tool and other developer solutions should be something not taken lightly. Instead, you should weigh your options and stick with solutions that are industry-proven and security conscious.
Modern iOS development over the past few years has centered around using Swift Package Manager, an official package management solution from Apple that relies on individual repositories on GitHub or other git-compatible services rather than a central listing of packages. While this certainly doesn’t limit developers from putting malicious code in their repositories, it does lessen the likelihood that a central listing service could be compromised for every package like it could’ve been in the case of the CocoaPods security flaw.
iOS developers have such a wonderful, rich resource of frameworks, services and APIs that Apple provides that can do a myriad of jobs without the need to turn to third party solutions. iOS is not a platform like Android where every task is controlled by third party libraries for simple things like networking or database CRUD. Instead, iOS provides developers with almost everything they could need or desire for building apps for their platforms. It’s very rare that you should need to turn to a third party library or framework over using the built-in tooling. The first step in building for a platform is understanding what can be done on the platform, where you need to turn to third party tooling, and embracing first-party libraries and frameworks over third party code.
Every time that you introduce third party code into your project, you’re introducing a gateway for malicious code, potential security issues, or abandoned code. While Apple’s frameworks can certainly still have issues with security, their code is well-maintained and goes through security audits and is more likely to be patched faster than some open source code on GitHub. In addition, Apple has a great bug bounty program for people actively hunting for security issues.
Like Apple, MartianCraft is focused on security and aims to provide solutions to our customers that not only stand the test of time, but also puts security and code quality first.
At MartianCraft, we have strict standards of how we choose solutions that go into the creation of our products. First and foremost, we choose to build our apps with Apple’s libraries, frameworks, and APIs over using third party code. If there’s something that Apple’s libraries cannot handle, then we will build a custom solution that can be easily maintained by our developers who have full access to the underlying code. Only if the client demands (or it’s just too time consuming vs. return on investment) do we turn to third party code.
When we do decide to look at third party frameworks and libraries, we also apply an equally stringent set of rules to the third party code. We evaluate how popular the project is, how frequently the code is updated, does the code use the most modern coding techniques that we prefer, and are there outstanding issues listed in the repository for the code. These items tell us a few things: First, we get to see if the project is updated frequently and how many users might be using it (which means that bugs are being reported and the project is keeping up to date with iOS), second it tells us the quality of the code based on bug reports and fixes and whether or not the developer of the codebase is using modern coding practices. We also evaluate whether or not we have access to fork the repository, which allows us to keep a copy of the code if the original were to disappear — something that’s important for the longevity of the project and allows us to provide bug fixes and updates ourselves. Which comes to the last part of this: Whenever you implement third party code in your project, you should own the code, meaning that if something breaks you should be able to understand the code enough to fix it yourself and not rely on the original developer. Just because you imported someone else’s code doesn’t mean you shouldn’t treat it like your own — you still own the project as a whole and should be able to maintain it like your own.
As the iOS development industry progresses, we likely will see more and more third party code use, which is ultimately going to lead to more security concerns that impact millions of users. As developers, we have the ability to combat that by ensuring that our tooling, code, and best practices lead to building the best and most secure software possible.
