Framework vs Library (Cocoa, iOS)

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)

Static Library

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.

Shared Library

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/


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
  • Documentation
  • Additional Resources
    • Views
    • Controls
    • Custom Appearance/ UI
    • Assets
    • Configuration files


MyCustomFramework.framework structure

  • Sub Framework 1
  • Sub Framework 2
  • Version 1.0
    • Library
    • Header
    • Resources
  • Version 1.1 (Current Version – Symbolic Link)
    • Library
    • Header
    • Resources

 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


Posted in Cocoa, Cocoa Touch, Generic, iOS, Objective C Tagged with: , , , , , , , , ,
4 comments on “Framework vs Library (Cocoa, iOS)
  1. Khant Thu Linn says:

    May I know how I can deploy my framework to network? Is it possible? I thought I can only embed inside my app.

    /Network/Library/Framework (slowest – performance penalties)

    • Debasis Das says:

      it is possible though not advisable. you have to modify your framework link settings to point to a framework on the network path, the network path goes into the absolute path, the downside is the app needs to be connected over the network.
      it is better to include the framework as a copy build phase items for the fastest performance and if your framework is being used by multiple apps, you might want to install that on the users machine and link multiple apps to the framework.

  2. Manjunath K says:

    Very well written.
    I am working on extracting some important functionalities from my app and converting them into a framework. Can you please suggest me the best options to distribute and codesign the framework?

    • Debasis Das says:

      Hi Manjunath,

      You can create a framework by identifying the following
      2. Models &
      3. Controllers.
      Ensure that any point the view is independent until and unless you have a requirement to hold the data (e.g caching) in the view itself.
      Controllers should be created with the mind set that it will be subclassed and the behavior extended.
      You can follow the MMC-VVC Design pattern.
      If you have utilities and extensions keep it separate that it does not depend on either Model, View or controllers and can be used on any MVC objects and need not be dependent on the model views and controllers that you define.
      Design to protocol implementations where you expect developers who are using your framework to follow a particular signature.

      Must is to create a demo app on top of your framework. Sometimes the API definitions and developer guide is not sufficient. Every successful framework has a demo app these days.

      If you expect the developers to change default project settings clearly site that in the readme file.
      Again the project settings in your demo app might not be sufficient. you might want to share the steps.

      If you need any configuration settings to be provided by developers provide the native data structure option as much as possible. Reduce dependency on any custom model defined in your project.

      Finally create your framework making is as loosely coupled as possible.

      Best Regards

1 Pings/Trackbacks for "Framework vs Library (Cocoa, iOS)"

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Recent Posts

Hit Counter provided by technology news