Why When and How to Open Source iOS Components

We all do some specific UI controls for different iOS projects and sometimes even see the parts that can be reused in other or future projects. And that’s a good opportunity to save some time for us in the future as well as learn something new and become better.

I do believe in Open Source and we all see a lot of great libraries and very strong communities behind them. Most of us use many of these libraries on daily basis, like AFNetworking/Alamofire or SDWebImage. Instead of implementing your own solution (even if it’s “lightweight”) and then extend it every time you need to support new protocol or feature like caching — it’s way more efficient to take existing library that was used and field-tested by thousands other developers.

But aside of this great cause — I just wanted to share my code, I thought of this as a great new experience, new adventure. My control was simple and I thought that there is nothing to fix neither to improve. “I will just put it out and wait” I thought. But I was so surprised with the outcome I’ve got and things I’ve learned!

That’s why I encourage you to try it yourself too, because It’s hard to understand initially what we can get from it, but only when you start giving you start receiving twice more in response.

Some of the stuff we create doesn’t mean to be shared or it’s hard to share. I believe the first question you should ask component you want to share: Why would somebody use it? Like in S.O.L.I.D. principles where S stands for Single Responsibility Principle, it’s best when your library solves only one primary problem: handling http-requests, manages ftp-connection, shows date picker, etc.

Multi-purpose libraries like many Utils libraries usually aren’t used so often, because most developers only need “one string operation” from it that easier to copy-paste than add additional dependency. Just ask any front-end developer about JQuery and how they like it. Though it can be very useful in some heavy projects with very specific elements’ querying — some developers are so lazy that they add it as dependency to micro projects, when all they need is simple getElementById function available in pure javascript out of the box.

Also it’s very important to make your library as independent as possible, because the more dependencies you have — the less people would want to rely on your library and spend fortune on fixing everything after each major iOS version update.

When you finally decide that you want to Open Source some part of your code, either it is a control or a library, be sure to prepare for some additional time to spend on finalizing and preparing clear interfaces for your classes and code.

Now we get to the most interesting point — finally doing it.

Remove as much dependencies as you can. Some of the problems easier to fix inline in your repo than follow a chain of dependencies to fix something and then updating your repo again to update required dependency version.

I saw many times when some controls depend on hex-color libraries for 2–3 default colors constants. It make no sense to have such dependency if you use it to define constant value. Just replace it with simple UIColor(R:G:B:A:) call to describe the same color.

For my control I decided to avoid any dependencies and during major iOS releases I had no need to update anything. The control just worked as expected. So unless it’s really necessary — remove the dependencies and make your control as independent as possible.

I also saw different controls that depend on some specific architecture like MVVM for example. It’s really cool that creator of the control is using MVVM or VIPER in his projects, but try to think about standard Apple Controls Library, Does they force you to use their MVC? You can use any standard Apple Control with any architecture, so why to add such dependency for your control and reduce the scope of possible clients of your library?

To create a clear interface for your classes in library or control — try to think of it as a fresh user, that want just to solve the problem your control is solving. Try to approach your library as this fresh new user who doesn’t know anything about the problems you need to overcome to accomplish it. Try to think what is the best interface for such user, that would prevent him from going into your code to learning what and why.

It can be a very creative step and I probably can’t provide too much info on this one rather than share my experience.

While your control is solving the developer’s problem, it doesn’t necessary align with every UI/UX designer vision. So every element user (developer) see on the screen is a subject of change.

The easiest way is just to provide a way to change every color, font and other elements used in your control, in my case there were following customization properties:

However, sometimes that is not enough, and you should not forget to use your creative thinking.

In my case I provided customization for all the elements, but still learned the new use-cases from my users. For example in my controls there is a HintView in the center of progress bar and user can define what text to write inside based on progress parameter. I decided to provide user with special StringGenerationBlock that takes float progress and return NSString* so user can define what text to show based on progress. That looks enough but later I’ve got feature request for NSAttributedString* support. It looks so natural to provide initially, but I haven’t even thought about such scenario. Your users really help you to improve your interface providing new use-cases.

That’s became the most valuable part for me, but only after a few months of initial release of this control. At first I was sharing this control because of my ego, I just wanted to ship this control so other people would use it and make me feel good about it. But only when I started to give I finally felt that I started to receive as well, way more than I was giving. The support and community that builds up around your control/library helps you to find issues in your implementation, to provide you with second opinion or fresh look, and finally to learn from it to become better.

First of all your users help you to fix issues in your code and discover some wrong logic. For example I haven’t tried to use my control with transparent background — but one of my users reported that there is a bug. Because it does sounds like a standard behavior you would expect from UI control — I fixed it.

The other user reported that when you update progress very often, for example in some progress update block during file upload — it does not able to do it in time (update progress calls more frequent than update animation duration). And even that this is very expected thing to support — I haven’t tested it heavily in this scenario.

The other important thing aside of fixes is new features and use-cases. That’s what really makes your control/library better.

My idea was to create a small easy to integrate, easy to use and easy to customize control. It should be pretty clear that such small library can’t grow into large essential library many developers would use on daily basis. Big communities around big libraries would require much more contributions management and participants discussions about library vision.

But I do believe if there will be more good independent small components that solve exactly one problem at a time — we can build applications much faster and easier. That’s why I encourage you to try it on your own and get this valuable experience, that will change the way you think.

Thanks for reading! I hope you find it useful or at least it gives you some fresh ideas. Tried to keep it short, but if you want some more particular examples and/or have suggestions — Please let me know in comments below!

Related posts:

CPI Financial is proud to announce the shortlist for the Banker Middle East Industry Awards 2019. The winners for each of the 32 shortlisted categories, as well as the two individual awards Banker of…