Bundle (macOS)
Filename extension |
.app, .framework, .kext, .plugin, .docset, .xpc, .qlgenerator, .component, .saver, .mdimporter, etc. |
---|---|
executable binary, metadata , other bundles, any other file needed to run the application. |
In
Examples of bundles that contain executable code include
Examples of bundles that do not contain executable code include document packages (iWork documents) and media libraries (iPhoto Library).
Bundles are programmatically accessed with the NSBundle
class in Cocoa, NeXTSTEP and GNUstep's Foundation frameworks, and with CFBundle
in Core Foundation. Bundles often include an Info.plist file for metadata.[1] The Uniform Type Identifier (UTI) for an Apple bundle is com.apple.bundle
.[2]
Application bundles
Filename extension |
.app |
---|---|
executable binary | |
Extended from | Bundle |
Application bundles are directory hierarchies, with the top-level directory having a name that ends with a .app
extension.
In a macOS application bundle, the first directory in the bundle underneath the top-level directory is usually named Contents
. Within Contents
there is usually another directory, called MacOS
, which contains the application's executable code. The Contents
folder contains a file named Info.plist
, which contains application information, such as the software vendor's name, name of the files that contain the applications executable and icon, the version of the application, permissions requested, etc. Within the Contents
folder there is usually also a directory called Resources
, which contains the resources of the application.[3]
Among other things, the Resources
folder contains localized versions of the application's nib files.
Other common subdirectories include Plugins
, Frameworks
, _CodeSignature
and Shared Frameworks
. The Frameworks
directory contains frameworks used by the application, and are used even if another version of the framework exists on the system. The Shared Frameworks
directory contains frameworks that can be used both by the application that contains them, and other applications; they are used only if a newer version does not exist elsewhere on the system. Plugins
contains extensible code used by the application. The _CodeSignature
folder contains information used by the system to validate that the package to establish that the package originates from a trusted party, and has not been tampered with.
By default, the Finder displays application bundles, which can also be referred to as packages, as opaque files with no underlying structure; the contents of the bundle can be shown with the "Show Package Contents" context menu item.
GNUstep by default uses the name of the application to name the folder that contains application code. An alternative is to name them by the computer architecture and OS the code is intended for to form a fat binary, so the application can be opened on many platforms.[4][5]
macOS framework bundles
Filename extension |
.framework |
---|---|
Uniform Type Identifier (UTI) | com.apple.framework |
Extended from | bundle |
macOS frameworks are also stored as bundles;Resources
. The Versions
directory also contains a symbolic link Current
to the directory for the current version of the framework. In the top-level directory are symbolic links to the contents of Versions/Current
.[7]
The Finder displays framework bundles as directories rather than as opaque files.
Although GNUstep uses frameworks, they are not usually stored as bundles. This is because the full semantics of framework loading are considered too alien to other platforms.[8]
Loadable bundles
Loadable bundles are bundles which contain code that can be loaded at runtime.[9] Loadable bundles usually have the extension .bundle
, and are most often used as plug-ins. On macOS, there is a way to load bundles even into applications that do not support them, allowing for third party hacks for popular applications, such as Safari[10] and Apple Mail.[11][12] A feature inherited from NeXTSTEP, GNUstep has the -[NSBundle principalClass]
interface too.
By default, the Finder displays loadable bundles, which can also be referred to as packages, as opaque files with no underlying structure; the contents of the bundle can be shown with the "Show Package Contents" context menu item.
Other bundle formats
There are many macOS applications which utilize their own custom bundle format (e.g. CandyBar .iContainer
, Aperture .aplibrary
, VMware Fusion .vmwarevm
, etc.).
.lproj
An .lproj file is a bundle that contains
See also
- Application Directory — the RISC OSanalogue to an application bundle
- AppImage— A Linux application that makes use of similar principles
- App — A HarmonyOS application that makes use of similar principles
- Rich Text Format Directory — the RTF extension by Apple using bundles
References
- ^ "Information Property List - Bundle Resources". Apple Developer Documentation.
- ^ "System-Declared Uniform Type Identifiers". Uniform Type Identifiers Reference. Apple Inc. Retrieved 2012-06-10.
- ^ "Bundle Structures". Bundle Programming Guide. Apple Inc. 2017-03-27. Application Bundles.
- ^ "PackagingDrafts/GNUstep". Fedora Project Wiki.
- ^ "gnustep/tools-make: README.Packaging". GitHub. 5 December 2021.
- ^ "Framework". developer.apple.com. Retrieved 2020-10-06.
- ^ "Bundle Structures". Bundle Programming Guide. Apple Inc. 2017-03-27. Anatomy of a Framework Bundle.
- ^ "User FAQ". GNUstep.
- ^ Code Loading Programming Topics for Cocoa: About Loadable Bundles
- ^ "Pimp My Safari: plugins". Archived from the original on 2007-10-31.
- ^ "Apple Mail plug-ins and tools". Archived from the original on 2009-03-08. Retrieved 2007-11-04.
- ^ "Hawk Wings — Plug-ins for Apple Mail". Archived from the original on 2007-08-31.
External links
- Bundle Programming Guide at Apple Developer Connection
- NSBundle documentation from the GNUstep project
- Platypus — a tool to create application bundles around scripts
- File extension details