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.