Finding an elegant way to reuse and share code (i.e., libraries) across separate iPhone applications can be a bit tricky, especially considering Apple’s restrictions on dynamic library linking and customFrameworks.
Most people agree that the best way to re-use code is to use static libraries. This tutorial builds on that solution, showing how your Xcode project can reference a second Xcode project — one which is used to build a static library.
This approach allows you to automatically build that static library with the rest of your app, using your current build configuration (e.g., debug, release, etc.) and avoid pre-building several versions of the library separately (where each version was built for a specific environment/configuration).
Wanted: An Elegant Way To Share Code Across Projects
If you want to reuse/share code across different iPhone applications, you only have two options that I’m aware of:
- Copy all of the source code from the “shared” library into your own project
- Keep the shared library code in a separate Xcode project and use it to build static libraries (e.g., libSomeLibrary.a, also referred to as “archive files”) that can be referenced by your project and used via static linking.
The first option, copying the files, should be avoided when possible since it’s inherently redundant and contrary to the goal of keeping “common code” modular and atomic.
It’s a much better idea to put the code in a static library (see since, as mentioned in the introduction, dynamic linking to custom libraries/frameworks isn’t allowed by Apple when it comes to iPhone apps.
For instructions on creating a static library from your code see this tutorial on the Stormy Productions blog.
We’ve established that the second option is preferable, but there’s a catch: you’ll need to build and distribute multiple versions of the static library–one for each runtime environment and build configuration. For example, you would need to build both “release” and “debug” versions of the library for the Simulator, as well as other pairs for the iPhone or iPod device itself.
So, how can we avoid manually pre-building and managing separate .a files?
Solution: Static Libraries Built On-Demand Via Xcode Cross-Project References
The trick to avoid pre-building static libraries for each environment is to use an Xcode “cross-project reference” so that those libraries are built dynamically (i.e., when you build your own app) using your app’s current build configuration.
This approach allows you to both reuse shared source code and avoid the headache of managing multiple versions of the library. Here’s how it works at a high level:
- The shared code lives in its own Xcode project that, when built, results in one or more static libraries.
- You create an Xcode environment variable with a path to the directory that contains the static library’s *.xcodeproj file.
- All iPhone apps that need the static library will use the aforementioned environment variable toreference the library’s Xcode project, including any static library in that project and the related header files.
- Each time you build your project for a specific configuration/runtime environment, the shared project library will also be built for that config/environment–if it hasn’t already–and linked with your executable.
In addition to solving the main problem (reusing code and avoiding management of multiple library versions), there are a couple of nice benefits to this strategy:
First, if you make changes to the shared library source code, those changes will immediately be included the next time you build your own project (via the cross-project reference).
Second, you can modify the Xcode environment variable to point to different versions of any project. For example, you might have separate directories for “somelibrary-1.0″ and “somelibrary-2.0″; as you’ll see in the detailed solution instructions, it’s easy to modify the environment variable and switch your project to a different version of “somelibrary.”
Implementing Cross-Project References
The instructions for setting up cross-project references to shared static libraries can be split into two parts:
- Part 1: Global Xcode Settings
- Part 2: Project-Specific Settings
I’ll be using an example in the instructions to help illustrate things. A suitable example would be an application that needs to use a shared static library from a separate project. In this case, I’ll use a sample iPhone app called “
No comments:
Post a Comment