Overview

understand the macOS design choices

We discuss macOS conventions, patterns and defaults, and try to understand the design choices behind them.

Property list files

A .plist file (Property List) commonly stores a set of user-preferences or some metadata about an app. It is a list of key-values.

The data's format is either binary or XML.

We may view or edit data with Xcode or plutil. We may use a text editor for XML ones.

plutil -p Info.plist
plutil -p "/Applications/Discord.app/Contents/Info.plist"

we may use file to detect if it's binary or XML:

file Info.plist
## Info.plist: XML 1.0 document text, ASCII text

Application bundle

A pattern where we bundle the executable along with supporting files in a directory that looks like the application itself, at least in the Finder, as it has an .app suffix and as it comes with special behaviour and appearance:

  • The double-click runs the program instead of opening the directory
  • Finder shows the application's icon instead of a directory icon.

The content is semi-standardized. It includes

  • the icons
  • the internationalization strings
  • metadata about the app
  • frameworks and libraries, separated from the executable.
ls -1p "/Applications/Google Chrome.app/Contents/"

Frameworks/
Library/
Resources/
_CodeSignature/
MacOS/

Info.plist
PkgInfo

Such content should be treated as read-only, as tampering it triggers a signature change and security measures that prevent the executable from running.

The application's dynamic data and preferences are stored outside the bundle.

Application's persisted data

The Library directory, located in the user's directory, helps to store data and preferences on behalf of applications.

While it has many directories, the ones that applications should use are as follows:

~/Library/Application\ Support/
~/Library/Caches
~/Library/Preferences

preferences

The Preferences directory stores lightweight user-preferences files related to a given program. They represent persisted user-specific settings. For example, com.apple.dock.plist stores the Dock settings.

ls ~/Library/Preferences/

com.microsoft.VSCode.plist
com.blizzard.diablo3.plist
com.apple.dock.plist

plutil -p ~/Library/Preferences/com.apple.dock.plist

application support

Application Support is the general purpose storage area where each application may persist arbitrary data, such as databases, downloaded content, or extensions.

caches

Caches stores cached data on behalf of applications. Those are usually artifacts produced by network fetches, which cache the network responses to keep them available across runs.

Launch processes automatically

register a process for automatic launch

Applications (or simple processes) may request the OS to automatically launch them at boot-up or at user-login.

Boot-up items start before login, for critical services that should run as soon as possible and regardless of the user.

Login items start on user login, and may launch applications automatically.

traditional registration process

We craft a plist file that identifies a process and provides some settings such as the launch arguments. We then place it in a hardcoded directory.

We place it in /Library/LaunchDaemons if it has to start on boot-up. We place it in either /Library/LaunchAgents or ~/Library/LaunchAgents if it has to start on user login.

macOS manages a distinct database to keep track of which item has been disabled from the OS login-items settings.

open /Library/LaunchDaemons
open /Library/LaunchAgents
open ~/Library/LaunchAgents

sfltool dumpbtm

launchctl print-disabled user/$(id -u)

modern registration process

applications are now encouraged to store the plist files inside their bundles and register them through a macOS API. This ends the pattern of having plist files outside of their bundles.

MyApp.app/
 └── Contents/
      ├── Info.plist
      ├── MacOS/
      │    └── MyApp  (The main executable)
      └── Library/
           └── LaunchAgents/
                └── com.myapp.helper.plist

Default directories and files

disk root directory

The root location aka / contains:

  • the UNIX-style directories aka bin, usr, and more. The etc, tmp and var directories are aliases: they live in private/.
  • the user-facing folders such as Users, Applications, Library, System and Volumes.
┌── Applications/
├── Library/
├── System/
├── Users/
├── Volumes/
│
├── bin/
├── cores/
├── dev/
├── etc/
├── home/
├── opt/
├── private/
├── sbin/
├── tmp/
├── usr/
└── var/

user's root directory

The user's root directory, that we may refer to as ~, contains:

┌── Desktop/
├── Documents/
├── Downloads/
├── Movies/
├── Music/
├── Pictures/
│
├── Public/
└── Library/

earlymorning logo

© Antoine Weber 2026 - All rights reserved

Overview

understand the macOS design choices

We discuss macOS conventions, patterns and defaults, and try to understand the design choices behind them.

Property list files

A .plist file (Property List) commonly stores a set of user-preferences or some metadata about an app. It is a list of key-values.

The data's format is either binary or XML.

We may view or edit data with Xcode or plutil. We may use a text editor for XML ones.

plutil -p Info.plist
plutil -p "/Applications/Discord.app/Contents/Info.plist"

we may use file to detect if it's binary or XML:

file Info.plist
## Info.plist: XML 1.0 document text, ASCII text

Application bundle

A pattern where we bundle the executable along with supporting files in a directory that looks like the application itself, at least in the Finder, as it has an .app suffix and as it comes with special behaviour and appearance:

  • The double-click runs the program instead of opening the directory
  • Finder shows the application's icon instead of a directory icon.

The content is semi-standardized. It includes

  • the icons
  • the internationalization strings
  • metadata about the app
  • frameworks and libraries, separated from the executable.
ls -1p "/Applications/Google Chrome.app/Contents/"

Frameworks/
Library/
Resources/
_CodeSignature/
MacOS/

Info.plist
PkgInfo

Such content should be treated as read-only, as tampering it triggers a signature change and security measures that prevent the executable from running.

The application's dynamic data and preferences are stored outside the bundle.

Application's persisted data

The Library directory, located in the user's directory, helps to store data and preferences on behalf of applications.

While it has many directories, the ones that applications should use are as follows:

~/Library/Application\ Support/
~/Library/Caches
~/Library/Preferences

preferences

The Preferences directory stores lightweight user-preferences files related to a given program. They represent persisted user-specific settings. For example, com.apple.dock.plist stores the Dock settings.

ls ~/Library/Preferences/

com.microsoft.VSCode.plist
com.blizzard.diablo3.plist
com.apple.dock.plist

plutil -p ~/Library/Preferences/com.apple.dock.plist

application support

Application Support is the general purpose storage area where each application may persist arbitrary data, such as databases, downloaded content, or extensions.

caches

Caches stores cached data on behalf of applications. Those are usually artifacts produced by network fetches, which cache the network responses to keep them available across runs.

Launch processes automatically

register a process for automatic launch

Applications (or simple processes) may request the OS to automatically launch them at boot-up or at user-login.

Boot-up items start before login, for critical services that should run as soon as possible and regardless of the user.

Login items start on user login, and may launch applications automatically.

traditional registration process

We craft a plist file that identifies a process and provides some settings such as the launch arguments. We then place it in a hardcoded directory.

We place it in /Library/LaunchDaemons if it has to start on boot-up. We place it in either /Library/LaunchAgents or ~/Library/LaunchAgents if it has to start on user login.

macOS manages a distinct database to keep track of which item has been disabled from the OS login-items settings.

open /Library/LaunchDaemons
open /Library/LaunchAgents
open ~/Library/LaunchAgents

sfltool dumpbtm

launchctl print-disabled user/$(id -u)

modern registration process

applications are now encouraged to store the plist files inside their bundles and register them through a macOS API. This ends the pattern of having plist files outside of their bundles.

MyApp.app/
 └── Contents/
      ├── Info.plist
      ├── MacOS/
      │    └── MyApp  (The main executable)
      └── Library/
           └── LaunchAgents/
                └── com.myapp.helper.plist

Default directories and files

disk root directory

The root location aka / contains:

  • the UNIX-style directories aka bin, usr, and more. The etc, tmp and var directories are aliases: they live in private/.
  • the user-facing folders such as Users, Applications, Library, System and Volumes.
┌── Applications/
├── Library/
├── System/
├── Users/
├── Volumes/
│
├── bin/
├── cores/
├── dev/
├── etc/
├── home/
├── opt/
├── private/
├── sbin/
├── tmp/
├── usr/
└── var/

user's root directory

The user's root directory, that we may refer to as ~, contains:

┌── Desktop/
├── Documents/
├── Downloads/
├── Movies/
├── Music/
├── Pictures/
│
├── Public/
└── Library/