Framework vs Library (Static & Shared) in (Cocoa/OSX, Cocoa Touch/iOS)
Written By: Debasis Das (20-Feb-2015)
This article talks about various options of bundling reusable code in your (Cocoa – OSX) or (Cocoa Touch – iOS ) Applications
Before understanding the difference between a framework and a Library lets go through what each is. Eventually we will evaluate the options for Framework vs Library
What is a Library?
Library is a packaged collection of object files that program can link against.
Libraries can be
- Static Library (Packaged into the code of the main executable)
- Shared Library (The linker just stores a reference to the library and the library itself is not packaged in the main executable)
Note: Static Library is the most commonly used option (till iOS8 was released) this was the only option. With iOS8 developers can use Cocoa Touch Framework.
Static Library is commonly used for
- Program to link against
- For simplifying the build system where each major module is put into its own static library. Then all the static libraries are linked together to make the final executable program.
Note: Objects that live in a static library is physically copied into the final executable.
While using a static library, the code is linked physically into your executable program. The problem with static library is if the same static library is being used by multiple programs, the static library will get copied.
The above stated problem can be solved using a shared library. Instead of just copying the code into a program, just the reference is included.
When a program needs a feature from a shared library, the linked just includes the name of the symbol and a pointer to the library.
Steps followed in a shared Library
Program is executed -> Loader Finds the shared Library -> Loads the Shared Library unto memory – > Resolves the symbols or fixes the reference
A shared library appears once in the physical RAM and will be shared amongst multiple applications processes. However the space used the objects of the shared library will be different for different applications
Shared Library on a Mac OSX will have an extension of .dylib (dynamic library)
To see the list of dynamic libraries an application is linked against use the following $ nm -mg /Applications/iTunes.app/contents/MacOS/iTunes
Libraries only has executable code. A framework is a bundle (Directory structure) that contains shared libraries as well as sub directories of headers and other resources
However Frameworks can include the following
- Shared Library
- Header Files describing the API
- Additional Resources
- Custom Appearance/ UI
- Configuration files
- Sub Framework 1
- Sub Framework 2
- Version 1.0
- Version 1.1 (Current Version – Symbolic Link)
How are Frameworks and Library Different from each other?
- Inversion of Control is a key part which makes a framework different from a library. When we call a method from a library we are in control, but with the framework the control is inverted, the framework calls our code. (E.g a GUI framework calls our code through the event handlers)
- A library is essentially a set of functions (well defined operations) that we can call (organized into classes). Each does some work and then returns the control to the client
- A framework embodies some abstract design with more behavior built in. In order to use it, we need to insert our behavior into various places in the framework either by subclassing or by plugging in our code. The framework code then calls our code at these points.
- A framework can also be considered as a skeleton where the application defines the meat of the operation by filling out the skeleton. The skeleton still has code to link up the parts
Libraries or Frameworks?
- Frameworks are great if we are supplying libraries to third parties to be used as is. The users (other developers) can include the framework in their application bundle.
- Including frameworks in the applications bundle works great but if the plan is to put the framework in the /Library/Frameworks/ folder then that would require admin access and might lead to versioning issues.
- Resource Types – We cannot carry assets along with a static library. The .a is separate from the headers and thus the headers also needs to be included. With Frameworks we can package absolutely anything into one single unit
- Packaging – The packaging in nice in frameworks as compared to libraries
- Live Views – If we have custom views included in a framework & the framework is included in a project, All those custom views gets available in the interface builder
- Apps & Extensions – In case of reuse between an application and an extension, rather than putting the code in the target for both, the code should be put in a framework and the framework would be linked from both the app and the extension.
- Setup Effort – Setup effort is lesser as compared to libraries
- Memory Footprint – System loads the framework onto memory as needed & Shares one copy of the resources amongst all applications. On a OSX, the behavior is same for dynamic libraries
- Backward Compatibility – Multiple versions of the framework can be included in the same bundle ensuring backward compatibility.
- Private vs Public – Frameworks can be private (to be used by our own apps only) or public (to be used by other developers). Private frameworks (In the App Bundle – Using a copy file build phase where the resource type is Frameworks, this accounts to increase in the app bundle size similar to the inclusion of Static Libraries)
- Similar to Dynamic Library – The executable code in a framework bundle is a dynamically linked shared library or simply a dynamic shared library.
Location / Deployment of Frameworks
- /Library/Frameworks (for all users)
- ~/Library/Frameworks (for one users)
- /Network/Library/Framework (slowest – performance penalties)
- /System/Library/Frameworks (Reserved for Apple provided frameworks only)
- In the App Bundle – Private frameworks (Using a copy file build phase where the resource type is Frameworks)
Reference & Further Read
- Advanced Mac OS X Programming: The Big Nerd Ranch Guide by Mark Dalrymple
- Framework Programming Guide https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html#//apple_ref/doc/uid/10000183i
- Dynamic Library Programming Topics – https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40001869