Question

Here is what I’m looking for:

I’d like to separate pieces of functionality into modules or components of some sort to limit visibility of other classes to prevent that each class has access to every other class which over time results in spaghetti code.

In Java & Eclipse, for example, I would use packages and put each package into a separate project with a clearly defined dependency structure.

Things I have considered:

1. Using separate folders for source files and using Groups in Xcode:
   • Pros: simple to do, almost no Xcode configuration needed
   • Cons: no compile-time separation of functionality, i.e. access to everything is only one #import statement away
2. Using Frameworks:
   • Pros: Framework code cannot access access classes outside of framework. This enforces encapsulation and keeps things separate
   • Cons: Code management is cumbersome if you work on multiple Frameworks at the same time. Each Framework is a separate Xcode project with a separate window
3. Using Plugins:
   • Pros: Similar to Frameworks, Plugin code can’t access code of other plugins. Clean separation at compile-time. Plugin source can be part of the same Xcode project.
   • Cons: Not sure. This may be the way to go…

Based on your experience, what would you choose to keep things separate while being able to edit all sources in the same project?

Edit:

• I’m targeting Mac OS X
• I’m really looking for a solution to enforce separation at compile time
• By plugins I mean Cocoa bundles (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html)

Answer 1

I have worked on some good-sized Mac projects (>2M SLOC in my last one in 90 xcodeproj files) and here are my thoughts on managing them:

• Avoid dynamic loads like Frameworks, Bundles, or dylibs unless you are actually sharing the binaries between groups. These tend to create more complexity than they solve in my experience. Plus they don’t port easily to iOS, which means maintaining multiple approaches. Worst, having lots of dynamic libraries increases the likelihood of including the same symbols twice, leading to all kinds of crazy bugs. This happens when you directly include some “helper” class directly in more than one library. If it includes a global variable, the bugs are awesome as different threads use different instances of the global.

• Static libraries are the best choice in many if not most cases. They resolve everything at build time, allowing code stripping in your C/C++ and other optimizations not possible in dynamic libraries. They get rid of “hey, it loads on my system but not the customer’s” (when you use the wrong value for the framework path). No need to deal with slides when computing line numbers from crash stacks. They catch duplicate symbols at build time, saving many hours of debugging pain.

• Separate major components into separate xcodeproj. Really think about what “major” means here, though. My 90-project product was way too many. Just doing dependency checking can become a very non-trivial exercise. (Xcode 4 can improve this, but I left the project before we ever were able to get Xcode 4 to reliably build it, so I don’t know how well it did in the end.)

• Separate public from private headers. You can do this with static libs just as well as you can with Frameworks. Put the public headers in a different directory. I recommend each component have its own public include directory for this purpose.

• Do not copy headers. Include them directly from the public include directory for the component. Copying headers into a shared tree seems like a great idea until you do it. Then you find that you’re editing the copy rather than the real one, or you’re editing the real one, but not actually copying it. In any case, it makes development a headache.

• Use xcconfig files, not the build pane. The build pane will drive you crazy in these kinds of big projects. Mine tend to have lines like this:

---

common="../../common"
foo="$(common)/foo"
HEADER_SEARCH_PATHS = $(inherited) $(foo)/include

---

• Within your public header path, include your own bundle name. In the example above, the path to the main header would be common/foo/include/foo/foo.h. The extra level seems a pain, but it’s a real win when you import. You then always import like this: #import <foo/foo.h>. Keeps everything very clean. Don’t use double-quotes to import public headers. Only use double-quotes to import private headers in your own component.

• I haven’t decided the best way for Xcode 4, but in Xcode 3, you should always link your own static libraries by adding the project as a subproject and dragging the “.a” target into your link step. Doing it this way ensures that you’ll link the one built for the current platform and configuration. My really huge projects haven’t been able to convert to Xcode 4 yet, so I don’t have a strong opinion yet on the best way there.

• Avoid searching for custom libraries (the -L and -l flags at the link step). If you build the library as part of the project, then use the advice above. If you pre-build it, then add the full path in LD_FLAGS. Searching for libraries includes some surprising algorithms and makes the whole thing hard to understand. Never drop a pre-built library into your link step. If you drop a pre-built libssl.a into your link step, it actually adds a -L parameter for the path and then adds -lssl. Under default search rules, even though you show libssl.a in your build pane, you’ll actually link to the system libssl.so. Deleting the library will remove the -l but not the -L so you can wind up with bizarre search paths. (I hate the build pane.) Do it this way instead in xcconfig:

---

LD_FLAGS = "$(openssl)/lib/libssl.a"

---

• If you have stable code that is shared between several projects, and while developing those projects you’re never going to mess with this code (and don’t want the source code available), then a Framework can be a reasonable approach. If you need plugins to avoid loading large amounts of unnecessary code (and you really won’t load that code in most cases), then bundles may be reasonable. But in the majority of cases for application developers, one large executable linked together from static libraries is the best approach IMO. Shared libraries and frameworks only make sense if they’re actually shared at runtime.