views:

334

answers:

1

(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... ;)

+1  A: 

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.

Dan J
Sounds like a reasonable approach. The versioning is a bit tricky, as some of the third party libraries are distributed in source form and don't have explicit versioning. But I suppose I could point to a specific Github commit or date.You mentioned the possibility of including an (unsupported) process for customers to upgrade 3rd party libraries. How would I actually go about this? It seems like this would result in a conflict, since the 3rd party symbols effectively become part of our own SDK.
Mirko Froehlich
Haven't had time to think about this, but does "weak linking" help you at all? http://developer.apple.com/iphone/news/archives/november2009/#adding3xto2x
Dan J
I guess you could give them a script to rebuild the overall product (which includes your library, and the other 3rd party ones)? As long as they have the (>2GB) iPhone SDK installed you can give them a script that invokes xcodebuild for a simple Xcode project that holds everything together? Bit of a mess though. Easiest thing is to mandate the versions and insist they contact you (and pay) for a new release against the upgraded libraries. You can include a bit of acceptance testing in the price too... IMO it is totally reasonable for you to do that.
Dan J
I'll read up on weak linking. If this provides a way for my SDK to build against third party static libraries without actually including them in our static library, this may very well do the trick.
Mirko Froehlich
As for your other comment: Just to clarify, there are really three parties: Myself, my client, and the client's customers. I'm a consultant, but for all intents and purposes I'm representing the client in this case. It's really the client's customers I'm concerned about. The SDK enables them to integrate my client's functionality into their own iPhone apps. The problem is that some of the third party libraries we are using (such as Three20) are popular, so there's a good chance the client might already be using these (and perhaps different versions).
Mirko Froehlich
And it looks like in my feeble attempt to clarify things, I made things more confusing. ;) The last sentence above should have read: The problem is that some of the third party libraries we are using (such as Three20) are popular, so there's a good chance the client's customer might already be using these (and perhaps different versions).
Mirko Froehlich
Just delete and re-add the comment!
Dan J