Anatomy of MacOS application sets
What is in MacOS and what does it do? MacOS applications look like monolithic files, but they are more folders with nice icons called bundles. Open these bundles and you will find a number of files required by the application. What does all this do? Understanding these bundles is useful for developers, administrators, game editors, Hackintosh builders, security-conscious users, and anyone troubleshooting the application.
What are macOS application packages?
Like defined by apple, a bundle is “a directory with a standardized hierarchical structure that contains executable code and the resources used by that code”. Another name for it is an application. Developers need to follow a certain structure and format to ensure that their applications work properly. Violate these conventions and will probably violate your application. If something isn’t working properly, a number of apps can be a useful place to troubleshoot.
Applications are not the only bundle. Bundles are also used for files with .framework extensions, .packaging, .plugin and .kext. Bundles are displayed as unit objects in the Finder until you open them by opening the bundle package.
Opening application packages
Unlike directories, opening application packages requires a short dance.
1. Right-click the application icon under “/ Applications /”.
2. Click “Show package contents” in the context menu.
3. Double-click the “Content” folder to access the root directory of the application.
Anatomy of the MacOS application suite
You will find several files in the Contents folder of the series. All macOS applications must contain at least the following files:
- Info.plist: Contains the required configuration information and application identification strings.
- MacOS / executable: Code that launches when a user launches an application in the MacOS folder. Without an executable file, you don’t have a lot of packages.
You’ll probably also find several other files in a few public folders:
- Extensions: Extension-type mini-executable files that extend the functionality of the main executable file. Unlike static resources, plug-ins dynamically add functionality to an application.
- Resources: Support files on which your application is based. This folder contains, but is not limited to, images, icons, sounds, fonts, nib files, locations, and data warehouses. Unlike plug-ins, these resources support the basic functions of an executable file.
- Frame: Like plug-ins, the high-level frames required by your application are themselves bundles. However, they use a different hierarchical structure.
- Signature code: A structured plist file used to sign code for each part of an application. These signatures allow the application and macOS to verify the integrity of the application and prevent application hijacking attacks.
IOS application packages use the same basic structure and file format, although they often appear in different hierarchies.
Info.plist is your app’s basic population data. This includes your plan ID, which must be unique from all other plan IDs. To simplify this process, Apple recommends reverse domains such as “com.apple.siri.launcher” or “org.videolan.vlc”. For more information on Info.plist, see Apple’s key list and consider what each key does.
This file also contains basic application information, such as the application icon, application name, version number, copyright information, links to error reporting, and the default language. According to the contract and the rules of the system, the letter “I” in the letter “Info” is always in capital letters.
Here is the main code of your application. When the application is open, macOS executes the code contained in the executable file in the package’s MacOS directory. Almost all applications have only one executable file, although two or more can be used as auxiliary files. This file is usually of no interest to anyone other than the software developer because it cannot be easily viewed or edited by the user.
Additional resources and support files
Everything you need for your application must be included in its package. If it is not part of an executable file, it should go to one of the resource folders in the package. These resources can be stored in the Resources root folder or divided into different folders.
- If you are unsure, most of the resources will go to the “Resources” folder.
- The frames go to the “Frameworks” folder.
- Plug-ins are moved to the Plugins folder.
- The localization files (.lproj directories) are located in the Resources folder.
In addition to these requirements, Apple provides many suggestions and practices that must be followed unless you have a valid reason to do otherwise.
MacOS applications are included in bundles, which are hierarchical repositories of application files. The basic structure is the same for every application. The files of most interest to the user can be found in the Resources folder of the application package.