library, frameworks, and bundles in Mac OS X are similar in that you can think of them as pre-packaged code meant to be used from within another library or application. They’re all meant to improve or expand the functionality of an executable (including those that are part of the operating system) by making their code available to it.
library
The term library has the same meaning on every platform. A library is the most basic form of prepackaged, shared code meant to be reused in multiple applications. Mac OS and iOS come with a number of standard C libraries and libraries specifc to the operating system. In the Mac and iOS world, static libraries have the .a extension (a static object code library archive), while dynamically loaded libraries have a .dylib extension.
Static libraries are linked into the executable by the linker at build time. That is, the code in the library is un-archived and copied into the executable along with your program’s compiled object (.o) files. Static libraries result in a larger executable because the library’s code isn’t shared but merely “available to copy.” An example of a common static library is libc.a, the standard C library.
Dynamic libraries can be loaded at launch time or when needed at runtime. The code from the library is shared and is not part of the executable. This gives the potential for faster launch times, smaller executables, and less wasted space (as a result of many executables carrying the same code linked from a static library). An example of a popular dynamic library Cocoa developers use every day (perhaps without realizing it) is libobjc.a.dylib, which contains the Objective-C runtime library.
framework
A framework is a bundle of files and folders that can contain dynamic shared libraries, Interface Builder files, localized (translated) strings, headers, and media resources. It could contain nothing but a dynamic library or nothing but resources. If you’ve used Cocoa, you’ve used a collection of frameworks already.You’ve likely heard Cocoa being called “the Cocoa frameworks.” That’s because Cocoa.framework actually is an “umbrella framework” that encompasses a number of sub-frameworks. One such sub-framework is Foundation.framework, which gives you basic strings, container classes, and so on. On a Mac, things like windows, buttons, and drawing routines come from AppKit.framework, a Cocoa sub-framework. The same goes for AppKit’s iOS cousin, UIKit.framework. Unless your Cocoa application is fairly simple, it’s likely you’ll be using other frameworks, provided by the system or by third parties, that can be linked against to provide functionality not found in the core Cocoa frameworks themselves. At the very least, you may end up using a Cocoa framework that’s not normally automatically linked. In fact, when you created the TestApp project and specifed it should use Core Data, Xcode automatically included CoreData.framework and added it to the Link Binary With Libraries build phase of the TestApp target.
bundle
A bundle is a directory structure that appears to the end user as a single file. Applications, frameworks, plug-ins, and kernel extensions are all specifIc kinds of bundles. A loadable bundle contains code and resources that can be loaded and unloaded at runtime. This enables developers to divide up their applications into modules and even provide extensibility in the form of plug-ins. For example, the Spotlight search system comes with a core set of plug-ins that teach it how to index various types of fIles. Third-party developers can create Spotlight importer plug-ins to allow Spotlight to index even more filetypes (usually fIles created by their own applications). Screen savers are another example. Each screen saver is a plug-in (a bundle) that teaches the screen saver application how to display yet another form of eye candy, while the screen saver application itself only takes care of loading the effects or topping when the user moves the mouse (and possibly provides a password to unlock the screen). Xcode comes with a dazzling array of bundle types. There are templates to create plug-ins for Spotlight, Address Book, QuickLook, System Preferences, Automator, Dashboard, and even the kernel. Alternatively, you can just choose the generic Bundle template (found under the Framework & Library template group) and optionally tack on your own extension (such as test app-plugin) to stand out from the crowd.
Loadable bundles are like libraries or frameworks that your users can install and remove by drag and drop. Although things like Spotlight plug-ins often come embedded within an application bundle (which Spotlight automatically finds), their power as standalone plug-ins that a user can add or remove themselves is often overlooked. It’s important to be aware that loadable bundles can just as often be a product in themselves as a component embedded in another product.