For the last couple of years I've been building static frameworks of common APIs for my iOS projects. I can build a universal binary containing all the architectures (i386, armv6, armv7) and wrap it up in a .framework directory structure. I then stored this in a directory based on the version of the framework. For example ..../myAPI/v0.1.0/myAPI.framework

Once I have this framework I can then easily add it to a project and if I want to advance the version, merely change the framework search paths to the later version.

This works, but the approach is very similar to what I would use in the Java world.

Recently I've been reading about using Git submodules and static framework sub projects in XCode 4.

Im wondering if my currently approach is something that I should consider retiring and what the pros/cons are of the new approach.

I'm weary of just including code because I've already had issues in a work project which had (effectively) multiple versions of a third party API.

Any opinions?

3 Answers 3


It really depends. What is your main focus? Static and reliable versions, or staying in the edge?

This is, more or less, the same dilemma a common user would face when deciding if he wants to install an application from his package manager or directly from the developer's site (for example: Ogre3D's version is well ahead of the one that is on Ubuntu's repositories).

If you want to stay on the edge with your API's, go ahead and use git submodules. It will give you a lot of flexibility when you want to update your software.

If you want to stay with reliable versions, and don't want to change much what functions your code will call (since this is a thing that happens a lot when you update an API), then stay doing the same way you have been doing.


You're really talking about two different things that just happen to solve approximately the same problem. Frameworks are all about deploying multiple versions of a library and associated resources while git is, of course, all about managing multiple versions of your source code. Those sort of amount to the same thing on iOS, where apps aren't allowed to dynamically link to third-party (i.e. non-Apple) frameworks.

So, you've been using frameworks to manage libraries for your app, and now you're thinking of using git submodules instead. Again, because you're not able to take advantage of dynamic linking, you should get about the same result either way. Given that, the main difference is that your workflow may change a bit.

Frameworks surely aren't going away on iOS -- if your current system works well for you, keep using it.

  • true, they do solve the same problem. I'm wondering if as a general development flow, that submodules are easier to manage. Frameworks take complicated scripts to build and when I want to change to a new version, a bit of fiddling around in build settings.
    – drekka
    Commented Jun 22, 2012 at 2:21

Back again. Been playing with some projects to try and get my head around these questions.

It's nice that I can have embedded projects within XCode and Git. However they seem to increase the chances of issues and mistakes. Working this way also means that submodules are scattered all over the place, duplicated many time. This I think increases the chances of code clashes.

There seems to be a lot more complexity in working this way over the way I was working and I'm not sure if I am really gaining much from it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.