Can Xcode and iPhone handle hundreds of static libraries?

Question

I'm trying keep xcode chaos under control. Namely, how to reuse my small components/classes between projects. One strategy is to make every class, or tightly coupled collection of classes, in to a static library, each being a spawn of a different sub project with a few targets like unit tests, demos, and, of course, the library.

The way it looks now, I could I see a final app being composed of some custom code, and, say, a couple hundred libraries. That scares me, but should it? Would performance suffer? Are there other limitations to the many-library approach that would make it impractical?

Answer 1

Having 100's of static libraries is not keeping chaos under control it's making it far worse. Grouping your code logically into static libraries is a great idea but one per class is far too fine grained. 100's of libraries equals hundreds of projects which is a lot of maintenance.

Answer 2

After some offline-discussion, the consensus was that 100s of libraries would not slow down executions, but could be painful during linking.

The complexity of managing lots of libraries, could, of course, could make the solution worse than the disease.

Answer 3

If your concern is manageability, have you considered using svn:externals or git submodules?

It's a subdirectory from a different repository than the rest of your tree, so you can have multiple projects all using the latest version of your shared code in addition to a project just for testing that shared code. The file hierarchy would look something like:

tests/ <-- svn checkout

• shared-code/
• test-code/

project 1/ <-- svn checkout

• shared-code/ <-- svn:external to tests/shared-code/
• p1-specific-code/

project 2/ <-- svn checkout

• shared-code/ <-- svn:external to tests/shared-code/
• p2-specific-code/

There's a little svn dance to be done when tagging with svn:externals, and I believe git submodules require a different dance when updating their contents to HEAD, but those are both far from the headache involved with keeping common code in sync across multiple projects.