Yep, the iPhone SDK does not support dynamically linked libraries. And that’s truly fantastic news for all iPhone developers wishing to leverage existing code out there. You can, of course, use a statically linked library in your code, or — if you have the code for the third-party libraries you’re going to be using — copy the files in your project and compile them together with your own source.
One way to facilitate the inclusion of third party code, is by using what Apple calls, sparse SDKs, or additional SDKs. These are what some people call custom SDKs. From the XCode Build System Guide:
There may be times when, in addition to a system SDK, you need link against sparse SDKs. A sparse SDK is an SDK that is not a system SDK. Sparse SDKs may be provided by third parties, or you may build them yourself.
“Build them ourselves”, they said. “Develop for the iPhone, they said”. 🙂
Sadly there is practically no documentation for building custom SDKs for XCode. Some people have used the existing toolchain and some ‘inventive’ cooking of the accompanying metadata files to create custom SDKs for use in the iPhone, but I guess your mileage may vary.
Which brings us to the main point here; Apple has been prodigiously improving their platform over the past seven years; from what was a kludge, a crude amagalm of classic Mac OS and NeXT APIs has become the state-of-the-art platform of our time. Yet, over the years I’ve come to realise that Apple’s developer documentation — while steadily improving — is almost as bad as Microsoft’s code quality. The documentation — especially in newly released SDKs — ranges between sparse and non-existent. Coupled with the numerous bugs one’s bound to come across in the process of developing even a smallish application, bad documentation really detracts from the experience. And while — I’m sure — everyone will agree that good code is arguably better than good documentation, Apple could certainly improve there. At least the company seems to be using meaningful naming. 🙂