I have been developing iOS apps for about a year. In that time, I have developed a fair number of classes that I frequently recycle from app to app. For example, I have a bunch of classes related to making it easier to write table views to control in-app settings.
Right now, I simply grab these classes from one app and paste them into the next one. My question is -- at what point is it likely to be easier to create and use a static library?
Static libraries have their problems as well.
So what you want is a solution where you can add dependencies to actual source code. This way you avoid the nasty GCC bug, and the boy scout rule is encouraged!
Our solution is a simple dependency system based on Rake. It creates sym-links to the source code of the shared libraries, and hard copies when building on the build server (You should never build the distribution binaries on a developers own machine!).
The sym-links allow developers to edit the shared code just as if it was part of the current project, while ensuring any cleanups, bug-fixes, etc. are always propagated to a single repository and benefits all projects using the shared library.
The hard-copies on the build server allows for the shared libraries to be tagged for version, so that the exact build of v1.0 you sent to App Store is forever reproducible!
A colegue of mine have blogged about setting up a build server for continious integration here: http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/
I will nag him to blog and share the Rake based dependency system as well. It is basically just a handful of lines with Ruby script.
I have my own library of miscellaneous stuff.
I add things to it that I deem to be reasonably generic and that I can envisage using in the future at some point.
After all, there's no harm in adding it to your library, even if you never use it again.
As soon as you tire of copying and pasting you should create a library. Or, as soon as you make your first mistake (mis-)copying and (mis-)pasting.
Or, in more business-like terms: when the net present value exceeds the net present cost.
If you want to distribute your classes out to your "team", then you will not have to worry about changes they make to your code, thus keeping the libary consistant.
Or if you wanted to sell your classes as API's to another DEV team then your can hide the source code from the API user.
I have a few "utility" classes that I find usuful and I do tend to drop the class file into my solution as I find it easier and quicker, (not that the extra 2 to 3 clicks matter), so really i suppose i do it out of habbit more than anything else.
Another solution is to use use a version control system (such as git) that supports submodules. You can wrap up each of these helper classes (or even a collection of classes) in its own repository which can be imported into the main repository of your code.
In this way you don't have to worry about cutting and pasting errors. Also, if you make improvements to these classes they can be propagated to other projects that use them (if you want to), yet you can always roll back to previous versions for bug fixing / testing.
It is common to find such helper code on sites such as github example
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 simply re-use it by making another project dependant on it.
It means I don't have to cut/paste, and it also means that should I find/fix a bug, or add/modify a feature of the library, then it can be regression tested easily.
Now all the projects that use that library can benefit.
So for my money, the time to turn a collection of 'useful code' into a library is certainly when you find you want to use it again.
(Of course we all have useful code snippets we re-use by copy/paste from a previous project - those aren't necessarily right for being in a library.)
