If you are looking to share code between projects or distribute a 3rd party framework (such as a product API) a bit of googling will find you a solution. Or two. Or three. The solutions are all similar with some subtle differences. Here I’ve collected the best solutions I’ve found (going back to 2008) and which one worked well for me.
For the impatient, I recommend this iOS universal framework solution.
The problem: dynamic linked libraries, architectures and performance
All the system libraries for iOS are dynamically linked. This allows dynamic loading and sharing of libraries between applications for more efficient memory management. In order to simplify the handling of applications, this is not allowed for libraries shipped with an app even if two apps use the same library. These libraries must be statically linked. This is an issue simply because Xcode 4 does not directly support creating static iOS frameworks.
Additionally, libraries need to support multiple architectures: arm6 / arm7 on the devices and i386 when run in the simulator. Distributing a fat binary allows developers to drop the framework into their project but embedding the whole fat binary in the application should be avoided as it can substantially increase the size of the deployed app.
The developer experience is also important. For instance, if you are developing the framework in the context of an app that is using it, minimizing turn-around time for changes in the framework appearing in the app could be a big win (as it likely is for most).
iOS-Framework by Jeff Verkoeyen
My preferred solution is by Jeff Verkoeyen (jverkoey). It’s an evolution on the older solutions and focuses on an easier, faster build process while maintaining a good integration experience for users and optimal deployment. It still has some improvements to be made:
- A manual process. It’s easy, but not exactly a 1-step process. He’s documented it well enough that you could do it for a new project quickly if you couldn’t remember all the steps.
- Bundling resources requires more work on the part of both the framework author and users. Code-only frameworks shouldn’t have to deal with this, luckily.
Blog post by Jonah Williams of Carbon Five
This post offers a well-written guide and explanation of the problem. However, it’s not as comprehensive as the others. It also uses the framework in a way that isn’t entirely representative of the way your users will. This increasing the risk that you might be missing something big when cutting a distribution. However, it’s a good guide and shares a lot of similarities with jverkoey’s approach.
iOS-Universal-Framework by Karl Stenerud
iOS-Universal-Framework offers a way of bending Xcode to your will so it will produce a static framework by introducing a new project template, possibly making life better if you need to do this a lot. The solution by jverkoey specifically improves on the method in a some marginal, yet important, ways such as resource handling and compile time. As with Chris Boyd, this method has made some people very happy.
See iOS-Universal-Library-Template for a similar project not focused on frameworks.
Blog post by db-in
As noted by jverkoey, the approach in this post is essentially the same as iOS-Universal-Framework but not as good.
An assortment of useful links related to this:
- Compile, Build or Archive problems with Xcode 4
- Getting headers into frameworks in xcode
- Xcode workspaces and adding projects to workspaces
- Xcode docs on dynamic libraries
- Creating Frameworks
- Framework Programming Guide
- Bundle Programming Guide
- Creating static libraries for iOS
- Building a Universal Framework for iOS
Older, probably totally out of date (but possibly informative):