A collection of information about the current process.
- iOS 2.0+
- macOS 10.0+
- tvOS 9.0+
- watchOS 2.0+
Each process has a single, shared
Process object, known as a process information agent.
The process information agent can return information such as arguments, environment variables, host name, and process name. The
process class method returns the shared agent for the current process—that is, the process whose object sent the message. For example, the following line returns the
Process object, which then provides the name of the current process:
Process class also includes the
operating method, which returns an enum constant identifying the operating system on which the process is executing.
Process objects attempt to interpret environment variables and command-line arguments in the user's default C string encoding if they cannot be converted to Unicode as UTF-8 strings. If neither the Unicode nor C string conversion works, these values are ignored by the
The system has heuristics to improve battery life, performance, and responsiveness of applications for the benefit of the user. You can use the following methods to manage activities that give hints to the system that your application has special requirements:
In response to creating an activity, the system will disable some or all of the heuristics so your application can finish quickly while still providing responsive behavior if the user needs it.
You use activities when your application is performing a long-running operation. If the activity can take different amounts of time (for example, calculating the next move in a chess game), it should use this API. This will ensure correct behavior when the amount of data or the capabilities of the user's computer varies. You should put your activity into one of two major categories:
User initiated: These are finite length activities that the user has explicitly started. Examples include exporting or downloading a user specified file.
Background: These are finite length activities that are part of the normal operation of your application but are not explicitly started by the user. Examples include autosaving, indexing, and automatic downloading of files.
In addition, if your application requires high priority I/O, you can include the
latency flag (using a bitwise
OR). You should only use this flag for activities like audio or video recording that really do require high priority.
If your activity takes place synchronously inside an event callback on the main thread, you do not need to use this API.
Be aware that failing to end these activities for an extended period of time can have significant negative impacts to the performance of your user's computer, so be sure to use only the minimum amount of time required. User preferences may override your application’s request.
You can also use this API to control automatic termination or sudden termination (see Sudden Termination). For example:
is equivalent to:
Because this API returns an object, it may be easier to pair begins and ends than when using the automatic termination API—if the object is deallocated before the
end call, the activity will be automatically ended.
This API also provides a mechanism to disable system-wide idle sleep and display idle sleep. These can have a large impact on the user experience, so be sure not to forget to end activities that disable sleep (including
macOS 10.6 and later includes a mechanism that allows the system to log out or shut down more quickly by, whenever possible, killing applications instead of requesting that they quit themselves.
Your application can enable this capability on a global basis and then manually override its availability during actions that could cause data corruption or a poor user experience by allowing sudden termination. Alternately, your application can just manually enable and disable this functionality.
disable decrement or increment, respectively, a counter whose value is
1 when the process is first created. When the counter's value is 0 the application is considered to be safely killable and may be killed by the system without any notification or event being sent to the process first.
Your application can support sudden termination upon launch by adding a key to the application’s Info.plist. If the
NSSupports key exists in the Info.plist and has a value of
true, it is the equivalent of calling
enable during your application launch. This renders the application process killable right away. You can still override this behavior by invoking
Typically, you disable sudden termination whenever your application defers work that must be done before the application terminates. If, for example, your application defers writing data to disk, and sudden termination is enabled, you should bracket the sensitive operations with a call to
disable, perform the necessary operations, and then send a balancing
In agents or daemon executables that don't depend on AppKit you can manually invoke
enable right away. You can then use the enable and disable methods whenever the process has work it must do before it terminates.
Some AppKit functionality automatically disables sudden termination on a temporary basis to ensure data integrity.
Usertemporarily disables sudden termination to prevent process killing between the time at which a default has been set and the time at which the preferences file including that default has been written to disk.
NSDocumenttemporarily disables sudden termination to prevent process killing between the time at which the user has made a change to a document and the time at which the user's change has been written to disk.
Thermal State and App Performance in macOS
In macOS, use the current thermal state to determine if your app should reduce system usage. In macOS 10.10.3 and later, you can register for the
thermal to be notified when the thermal state changes. Use
thermal to query the current state. Your app should reduce system usage at higher thermal states. For recommended actions, see