I’ll try again soon, and see if I can get it work this time. Thanks!

Regarding the shared build output dir, I haven’t noticed any problems since I started using it in about four months ago. I have a custom logging library, for example, that is shared amongst several iPhone and OS X apps. The OS X versions show up in “Release” and “Debug” directories, the simulator versions in “Release-iphonesimulator” and “Debug-iphonesimulator”, and finally the device versions in “Release-iphoneos” and “Debug-iphoneos.” In other words, none of the builds seem to be overwriting each other (unless I’m totally missing something).

Of course I’m not disputing the issues you’re saying occurred on your machine; I’ve only used the “shared build output dir” in my own environment. That said, the Apple documentation actually suggests doing this (see the last paragraph in the “Referencing Other Projects” section of “Xcode Project Mangagement Guide”–http://tinyurl.com/c6c9vo), so hopefully it’s just a config problem on your machine?

yeah. the more persepctives the better – there’s so many pitfalls in this!

I had a quick look over your instructions and I’d be interested in how the shared output build dir worked for you. As far as I can see, Xcode has some awesome fundamental bugs that make that a bad idea – e.g. I believe (as in – it happened when I tried it, but I wasn’t sure why, and maybe I just made a config mistake) that this will cause e.g. a debug build to overwrite the libs for the release build in that dir.

No problem?

Well, yes, actually, the moment you need to export that file to e.g. check it in to SVN. Or to email it to a client. Just one accidental rebuild of ANY of your projects using that directory while they are in the “wrong” mode will vaporize your otherwise working binary.

Of course, you shouldn’t be exporting direct from an output directory, but I haven’t yet worked out how to get Xcode to behave like a normal IDE and just do custom build outputs in a sensible manenr (I’m sure it’s possible, I’ve heard other people have done it, I just haevn’t worked it out yet myself)

If you’re a lone-wolf coder just sharing a library between a couple of your own apps, then linking projects is probably the most convenient way to go. On the other hand, if you have three developers, one working on App A, another on App B, and a third on shared library X, then you can easily get into a situation where you want App A linked to libX-1.0, App B linked to libX-2.0, and Developer X working on libX-3.0.

Linking dependent projects ensures that all of your apps use the latest code, but it also forces you to upgrade all of your apps every time you want to upgrade your library; releasing and linking against specific versions of your library separates the decision to upgrade your library from the decision to upgrade your apps–which allows you to be more strategic in how you allocate your development time.

Being explicit about the Xcode bugs and flaws is IMHO an essential part of explaining the process; people need to know that when it goes weird it (probably) isn’t that they’ve done something wrong, it’s Xcode being passive-aggressive towards them.

If Xcode’s flaws and Apple’s bad docs (which tell you to use dynamic libs instead … despite the fact that apple has *banned* us from using dybamic libs on iphone) were not such a core part ofthis particular process then I wouldn’t mention them.

Except maybe for comic effect / sharing the pain – this is a blog after all, not a peer-reviewed tech journal. I get to be flippant and emotional :).

By the way, I’d like to stress the “secretly using files that aren’t in the project but still on your harddrive” error in XCode. I’ve had it jump to an old implementation (the ctrl+alt+up shortcut) after renaming a .m file to .mm.

You can also delete .h files at random (delete references but leave the file on the HD) and your project will compile and run without trouble.