iOS App Development: Using 3rd Party Libraries
You find yourself working on the app that helps you purchase stocks, create a new market for your users, or make your coffee maker turn on just with a few swipes on your phone. You have talked to a designer and together you thought through every little detail which resulted in a great looking mockup. Now you’re finally ready to start the implementation phase. Congratulations - you’re about to make your app live!
As you’re moving along with development you realize that timeline is getting longer, the important milestones are delayed, and it’s taking forever to build all these logic and little details you carefully thought through. Why is that? You’re starting to get worried and looking for a way to make development process go faster. You’re thinking that maybe there’s a way to help your developer achieve those milestones and get back on track. You turn to an enormous amount of open source 3rd party libraries that carry a promise of easing your development and saving you time.. After all you’ve heard that everyone is doing that and it just works.
Now here’s the problem - it may not always be that easy and smooth-running as one would hope for. I had to learn it hard way myself and now I’d like to share my findings and help you make right decisions in the future when it comes to 3rd party library integration.
What happens exactly once you integrate someone else’s code into your application? That’s right - you’re now responsible for that chunk of code. Any issue that occurs within that code is something you’re as an app creator would have to address. Original library owner won’t be around helping you resolve any problems within it. Be ready to roll up your sleeves and do a full inspection / debugging session within someone else’s code with almost no documentation. And yes, it’s as bad as it sounds - I’ve been there myself a few times.
New version of iOS is coming out (and it does come out new every single year) - you have to make sure all your libraries are compatible and there’s no regression.
Your business logic changes? You have to adapt your integrated libraries to support it. As your app gets bigger and more complicated with different functionality and logic that grows around those 3rd party libraries, you would find it really hard to replace them with different ones which would better support your updated business logic.
As a rule of thumb, open source 3rd party libraries are usually written in a very generic way. They’re very customizable and potentially could be applicable to plenty of use cases. That’s what makes them so appealing in the beginning - you plug it in your code and it plays nicely within your app with very little work on your part. However, that generalization comes with a price. First, you have to carry along all that extra code you probably don’t need since you only care about one use case you’re solving for and nothing else. That extra code could have bugs, it could also carry a lot of inefficiencies in it - slow algorithms, memory leaks, memory overuse.
Chances are everything will work nicely at the initial stage of development and you won’t see any issues. Indeed, you’ll be amazed and excited how well it works and how fast your app is being developed. However, what do you do when your beta testers start reporting that something weird is happening with your app? It’s crashing and it’s super slow at times. Finding the root cause in someone else’s code (now you remember all that libraries and components you’ve integrated?) could take days and then fixing it will take even longer. Always think long term!
One of the most integral parts of an app is keeping user data safe and secure. While you trust your developer to implement your app with user’s security and privacy in mind, how can you trust all these 3rd party libraries and SDKs to do the same? Quite often we’re seeing reports how millions of applications are leaking and exposing user’s location and other private data back to developers and other parties. However as an app owner you’re now taking full responsibility for what your app does, therefore you need to be mindful of what code goes into your app.
It’s not all that bad
What do you say? Ready to take down all the opened source libraries you’ve so happily integrated? Wait a minute. We’re not saying that all libraries are evil and need to be avoided. Some have earned a good reputation and are playing by now an important part in our apps lifecycle. For example, while Apple simplified and improved their networking SDK for us iOS developers to take use of, I would argue it still makes sense in some cases to use 3rd party libraries to support your application’s networking needs. It’s ok to use a well written wrapper around the networking low level protocol.
In another example, take a machine learning framework that would help create a trained model for object detection. Majority of us won’t have time and resources to spend months developing those algorithms. It’s ok to use what others have done for you in this case.
We only ask, that you take the necessary steps and do your technical due diligence before integrating that code into your app. Be sure to test all the edge cases! The dark side of open source libraries is the fact that developers and startups use too many to get the job done and get to market faster without any foresight into scaling and other issues down the line.