Destructive iOS libraries
Libraries and frameworks in iOS development are great stuff. They can save us a lot of time, so we don’t need to reinvent the wheel. Libraries significantly reduce the cost of the project and they have a lot of other advantages. You don’t need to write your own Google Maps, a scanner for credit cards, animation engines, and other. And I really like it. But what about the hidden damage?
A lot of junior developers use 3rd party libraries in their projects. They don’t have the experience to implement their own components at the beginning. And so they can visit cocoapods.org or github.com to find the libraries that can solve their problem. It’s not guilty at all, but I need to point this out — you need to stop using 3rd party libraries (when you can replace them spending a minimum time). You need to jump to the next level in your career.
I don’t mean you need to remove all the pods and other libraries from your project right now. I just want you to try to implement your own solution and deeply understand how does it work inside. And figure out that you can remove some pods, and write your own code for your needs. So here is my top of libraries that probably can do harm to developers.
Everyone heard about these libraries. And some people use these libraries without understanding how the networking works. There’s also a term for it — AFNetworking programmer. These guys haven’t ever tried to perform network requests via NSURSession or NSURLConnection.
I strongly recommend you guys to write your own network layer! It will not take much time and it has a lot of benefits. First of all, it’s interesting. Secondly, you are not a professional developer if you don’t know how to use NSURLSession and NSURLConnection and build your own network layer. Thirdly, you may love these libraries more, because you will understand how much time they saved you.
This library is popular and people use it when it comes to database fetching. “Super Awesome Easy Fetching for Core Data” they call themselves. In my opinion, many people use it to simplify the access, managing and updating data in a database via Core Data. But here is one thing — when you use this library, make sure that you understand Core Data stack. Otherwise — try to remove this library and use Core Data directly. There is a chance that you will remove MagicalRecord and will use your own solution. Thus you can remove 3rd party dependencies in your project.
Most popular UI libraries are SVProgressHUD, MBProgressHUD, Pop and other animation engines. I’ve been using it successfully in many projects. But there is one thing: sometimes you see nice animation examples of 3rd party library and it looks great. But you can write your own activity indicator, can’t you? My point here is simple: use as fewer UI libraries as you can. The user interface is changing rapidly. And adding a new UI library in your project sometimes is not a good idea. There are two sides to this: these libraries are very scalable or they are not scalable at all.
A quick example: your designer asked you to implement an activity indicator. And you found that library “A” is good and suitable for you. You have written some code using this library. Time has passed and the designer wanted to expand the behavior of your activity indicator. And you couldn’t use library “A” anymore because it is not scalable enough. So you need to rewrite your code and remove the library “A” from your project. So I recommend you to write your own code as much as you can.
I’m not against the use of these libraries in your projects. They are great and they saved me a lot of time. But the most important thing here is to understand the basics. Some libraries are built over system mechanisms and frameworks you should know about.