UIApplication class provides a centralized point of control and coordination for apps running in iOS. Every app has exactly one instance of
UIApplication (or, very rarely, a subclass of
UIApplication). When an app is launched, the system calls the
UIApplicationMain(_:_:_:_:) function; among its other tasks, this function creates a Singleton
UIApplication object. Thereafter you access the object by calling the
shared class method.
- iOS 2.0+
- tvOS 2.0+
A major role of your app’s application object is to handle the initial routing of incoming user events. It dispatches action messages forwarded to it by control objects (instances of the
UIControl class) to appropriate target objects. The application object maintains a list of open windows (
UIWindow objects) and through those can retrieve any of the app’s
UIApplication class defines a delegate that conforms to the
UIApplicationDelegate protocol and must implement some of the protocol’s methods. The application object informs the delegate of significant runtime events—for example, app launch, low-memory warnings, and app termination—giving it an opportunity to respond appropriately.
Apps can cooperatively handle a resource, such as an email or an image file, through the
openURL(_:) method. For example, an app that calls this method with an email URL causes the Mail app to launch and display the message.
The APIs in this class allow you to manage device-specific behavior. Use your
UIApplication object to do the following:
Temporarily suspend incoming touch events (
Register for remote notifications (
Trigger the undo-redo UI (
Determine whether there is an installed app registered to handle a URL scheme (
Extend the execution of the app so that it can finish a task in the background (
Perform app-level state restoration tasks (methods in the Managing the State Restoration Behavior task group)
Most apps do not need to subclass
UIApplication. Instead, use an app delegate to manage interactions between the system and the app.
If your app must handle incoming events before the system does—a very rare situation—you can implement a custom event or action dispatching mechanism. To do this, subclass
UIApplication and override the
sendEvent(_:) and/or the
sendAction(_:to:from:for:) methods. For every event you intercept, dispatch it back to the system by calling
[super sendEvent:event] after you handle the event. Intercepting events is only rarely required and you should avoid it if possible.