When is building a library worth it?

Question

I have been developing iOS apps for about a year. During this time, I developed quite a few classes, which I often process from application to application. For example, I have a bunch of classes related to simplifying the writing of table views for managing settings in an application.

Right now, I'm just grabbing these classes from one application and pasting them into the next. My question is: at what point is it easier to create and use a static library?

Answer 1

Static libraries have their problems.

• Using a static library prevents troubleshooting as you see them, because the code is in another project, and this becomes unpleasant.
• GCC has an error, while any method defined in a category is optimized from a static library. It is not good if the library code consists of many and many categories of convenience for existing classes.

So what you want is a solution in which you can add dependencies to the original source code. This way you avoid the annoying GCC mistake, and the scout boy rule is encouraged!

Our solution is a simple dependency system based on Rake. It creates sim links to the source code of shared libraries and hard copies when building on the build server (you should never create distribution files on your own development machine!).

Sim links allow developers to edit common code as if it were part of the current project, with any corrections, bug fixes, etc. always distributed in one repository and brought benefits to everyone using a shared library.

Hard copies on the assembly server allow you to exchange shared libraries for the version, so the exact assembly v1.0 that you sent to the App Store is permanently reproducible!

My colleague reported creating a build server for continuous integration here: http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/

I will impose a blog on him and share the Rake-based dependency system. These are just a few lines with a Ruby script.

Answer 2

I have my own library of different materials.

I add to it things that, in my opinion, are quite universal and that I can use them in the future in the future.

In the end, there is no harm in adding it to your library, even if you never use it again.

Answer 3

Once you get tired of copy and paste, you should create a library. Or, as soon as you make your first mistake (wrong) copying and (wrong) pasting.

Or in more business terms: when the net present value exceeds the net present value.

Answer 4

If you want to distribute your classes in your “team”, you don’t have to worry about the changes they make to your code, thereby maintaining consistency.

Or, if you want to sell your classes as an API to another DEV team, then you can hide the source code from the API user.

I have several “utility” classes that I find well-groomed, and I tend to discard the class file in my solution, as I find it simpler and faster (not that 2 to 3 clicks are important), so really suppose that I am doing this from habbit more than anything.

Answer 5

Another solution is to use a version control system (e.g. git) that supports submodules. You can wrap each of these helper classes (or even a set of classes) in your own repository, which can be imported into the main repository of your code.

This way you don't have to worry about cutting and pasting errors. In addition, if you improve these classes, they can be extended to other projects that use them (if you want), but you can always revert to previous versions to fix / test errors.

It's generally accepted to find such helper code on sites like github example

Answer 6

I have a static library that is in a separate project. That way, I can fully develop the library, complete with unit tests, etc., and then just reuse it, making another project dependent on it.

This means that I do not need to cut / paste, and it also means that I have to find / fix the error or add / change the library function, then it can be easily tested with regression.

Now all projects that use this library can come in handy.

So, for my money, it's time to turn a collection of "useful code" into a library, of course, when you find that you want to use it again.

(Of course, we all have useful snippets of code that we reuse by copying / pasting from a previous project - this is not always correct in order to be in the library.)