Library (.a file) or framework in iOS, what is a better choice

Question

I have an indecision about converting my project in to lib or to framework in order to use it in another project and hide my code.

I've been looking the web for some material about what is better, framework or lib. There are few kinds of frameworks (most of them are not supported by Apple, and usually it need some "legal hacks" to build them, e.g fake framework and dynamic framework..).

Can someone recommend and explain what is better choice to use? Framework or lib (.a file).

Answer 1

This started as a comment, but I ran out of space. Everything H2CO3 said is correct, but it's worth going into a bit more detail on the 2 flavors of static libraries. When distributing your code to others, the consumer needs 2 things: your public headers, and your compiled object files. The two approaches vary slightly in their delivery of said things.

Vanilla Static Library (libMyCoolCode.a)

These have the benefit of being easy to build. Xcode already has a project template for you. While they're not awful to consume, they're also not great. You have to give out your compiled object archive (the .a file) and you also have to provide all the public headers somehow. The client then has to link to your library and manually tell Xcode where to look for the headers.

Fake Framework (MyCoolCode.framework)

Traditional frameworks contain dynamic libraries. Some people out there have figured out a way to make identical constructs around static libraries. A .framework is simply a directory structure with a deterministic layout. It's designed to include all the header files needed for use. This is very easy to consume. You simply drag-and-drop, and Xcode will automatically know where to find the headers. It has the downside of being harder to produce. Xcode doesn't have a project template for this, so you'll need find literature about the process online and add your own build script to Xcode to produce the framework.

All that said, it's up to you to decide based on how your library is going to be used. It's a simple trade-off between easy-to-build but tedious to consume, and hard-to-build but easy to consume.