Static (iPhone) libraries, distribution, and dependencies

Question

(Presumably the following question is not iPhone specific, aside from the fact that we would likely use a Framework or dynamic library otherwise.)

I am building a proprietary iPhone SDK for a client, to integrate with their web back-end. Since we don't want to distribute the source code to customers, we need to distribute the SDK as a static library. This all works fine, and I have verified that I can link new iPhone apps against the library and install them on the device.

My concern is around third party libraries that our SDK depends on. For example we are currently using HTTPRiot and Three20 (the exact libraries may change, but that's not the point). I am worried that this may result in conflicts if customers are also using any of these libraries (and perhaps even different versions) in their app.

What are the best practices around this? Is there some way to exclude the dependent libraries' symbols from our own static library (in which case customers would have to manually link to both our SDK as well as HTTPRiot and Three20)? Or is there some other established mechanism?

I'm trying to strike a balance between ease of use and flexibility / compatibility. Ideally customers would only have to drop our own SDK into their project and make a minimal number of build settings changes, but if it makes things more robust, it might make more sense to have customers link against multiple libraries individually. Or I suppose we could distribute multiple versions of the SDK, with and without third party dependencies, to cover both cases.

I hope my questions make sense... Coming mainly from a Ruby and Java background, I haven't had to deal with compiled libraries (in the traditional sense) for a long time... ;)

Answer 1

If it were me I would specify exactly which versions of those 3rd party libraries my library interoperates with. I would then test against them, document them, and probably deliver with those particular versions included in the release.

Two things I would worry about:
-I would want to be sure it 'just works' when my customers install it.
-I wouldn't want to guarantee support for arbitrary future versions of those 3rd party libraries.

It is fine to include a process for the customer to move to newer versions, but if anything doesn't work then I would expect the customer to pay for that development work as an enhancement, rather than it being a free bug fix (unless you include that in the original license/support arrangement).

At that point it becomes an issue of ensuring your specific versions of the 3rd party libraries can work happily alongside anything else the customer needs (in your case a web back-end). In my experience that is usually a function of the library, e.g. some aren't designed so multiple versions can run side-by-side.