Cocoa Touch Layer
The Cocoa Touch layer contains key frameworks for building iOS apps. These frameworks define the appearance of your app. They also provide the basic app infrastructure and support for key technologies such as multitasking, touch-based input, push notifications, and many high-level system services. When designing your apps, you should investigate the technologies in this layer first to see if they meet your needs.
The following sections describe some of the key technologies available in the Cocoa Touch layer.
iOS 8 lets you extend select areas of the system by supplying an app extension, which is code that enables custom functionality within the context of a user task. For example, you might supply an app extension that helps users post content to your social sharing website. After users install and enable this extension, they can choose it when they tap the Share button in their current app. Your custom sharing extension provides the code that accepts, validates, and posts the user’s content. The system lists the extension in the sharing menu and instantiates it when the user chooses it.
In Xcode, you create an app extension by adding a preconfigured app extension target to an app. After a user installs an app that contains an extension, the extension can be enabled by the user in the Settings app. When the user is running other apps, the system makes the enabled extension available in the appropriate system UI, such as the Share menu.
iOS supports app extensions for the following areas, which are known as extension points:
Share. Share content with social websites or other entities.
Action. Perform a simple task with the current content.
Widget. Provide a quick update or enable a brief task in the Today view of Notification Center.
Photo editing. Perform edits to a photo or video within the Photos app.
Document provider. Provide a document storage location that can be accessed by other apps. Apps that use a document picker view controller can open files managed by the Document Provider or move files into the Document Provider.
Custom keyboard. Provide a custom keyboard that the user can choose in place of the system keyboard for all apps on the device.
Each extension point defines appropriate APIs for its purposes. When you use an app extension template to begin development, you get a default target that contains method stubs and property list settings defined by the extension point you chose.
For more information on creating extensions, see App Extension Programming Guide.
Handoff is a feature in OS X and iOS that extends the user experience of continuity across devices. Handoff enables users to begin an activity on one device, then switch to another device and resume the same activity on the other device. For example, a user who is browsing a long article in Safari moves to an iOS device that's signed into the same Apple ID, and the same webpage automatically opens in Safari on iOS, with the same scroll position as on the original device. Handoff makes this experience as seamless as possible.
To participate in Handoff, an app adopts a small API in Foundation. Each ongoing activity in an app is represented by a user activity object that contains the data needed to resume an activity on another device. When the user chooses to resume that activity, the object is sent to the resuming device. Each user activity object has a delegate object that is invoked to refresh the activity state at opportune times, such as just before the user activity object is sent between devices.
If continuing an activity requires more data than is easily transferred by the user activity object, the resuming app has the option to open a stream to the originating app. Document-based apps automatically support activity continuation for users working with iCloud-based documents.
For more information about how to support Handoff, see Handoff Programming Guide.
The document picker view controller (
UIDocumentPickerViewController) grants users access to files outside your application’s sandbox. It is a simple mechanism for sharing documents between apps. It also enables more complex workflows, because users can edit a single document with multiple apps.
The document picker lets you access files from a number of document providers. For example, the iCloud document provider grants access to documents stored inside another app’s iCloud container. Third-party developers can provide additional document providers by using the Storage Provider extension.
For more information about how to use the document picker, see the Document Picker Programming Guide.
AirDrop lets users share photos, documents, URLs, and other kinds of data with nearby devices. Support for sending files to other iOS devices using AirDrop is built into the existing
UIActivityViewController class. This class displays different options for sharing the content that you specify. If you are not yet using this class, you should consider adding it to your interface.
To receive files sent using AirDrop, your app must do the following:
Declare support for the appropriate document types in Xcode. (Xcode adds the appropriate keys to your app’s
Info.plistfile.) The system uses this information to determine whether your app can open a given file.
application:openURL:sourceApplication:annotation:method in your app delegate. (The system calls this method when a new file is received.)
Files sent to your app are placed in the
Documents/Inbox directory of your app’s home directory. If you plan to modify the file, you must move it out of this directory before doing so. (The system allows your app to read and delete files in this directory only.) Files stored in this directory are encrypted using data protection, so you must be prepared for the file to be inaccessible if the device is currently locked.
For more information about using an activity view controller to share data, see UIActivityViewController Class Reference.
TextKit is a full-featured, high-level set of classes for handling text and fine typography. Using TextKit, you can lay out styled text into paragraphs, columns, and pages; you can flow text around arbitrary regions such as graphics; and you can use it to manage multiple fonts. If you were considering using Core Text to implement text rendering, you should consider TextKit instead. TextKit is integrated with all UIKit text-based controls to enable apps to create, edit, display, and store text more easily—and with less code than was previously possible in iOS.
TextKit comprises new UIKit classes, along with extensions to existing classes, including the following:
NSAttributedStringclass has been extended to support new attributes.
NSLayoutManagerclass generates glyphs and lays out text.
NSTextContainerclass defines a region where text is laid out.
NSTextStorageclass defines the fundamental interface for managing text-based content.
For more information about TextKit, see Text Programming Guide for iOS.
Apps can now specify dynamic behaviors for
UIView objects and for other objects that conform to the
UIDynamicItem protocol. (Objects that conform to this protocol are called dynamic items.) Dynamic behaviors offer a way to improve the user experience of your app by incorporating real-world behavior and characteristics into your app’s user interface. UIKit dynamics supports the following types of behaviors:
UIAttachmentBehaviorobject specifies a connection between two dynamic items or between an item and a point. When one item (or point) moves, the attached item also moves. The connection is not completely static, though. An attachment behavior has damping and oscillation properties that determine how the behavior changes over time.
UICollisionBehaviorobject lets dynamic items participate in collisions with each other and with the behavior’s specified boundaries. The behavior also lets those items respond appropriately to collisions.
UIGravityBehaviorobject specifies a gravity vector for its dynamic items. Dynamic items accelerate in the vector’s direction until they collide with other appropriately configured items or with a boundary.
UIPushBehaviorobject specifies a continuous or instantaneous force vector for its dynamic items.
UISnapBehaviorobject specifies a snap point for a dynamic item. The item snaps to the point with a configured effect. For example, a dynamic item can snap to the point as if it were attached to a spring.
Dynamic behaviors become active when you add them to an animator object, which is an instance of the
UIDynamicAnimator class. The animator provides the context in which dynamic behaviors execute. A given dynamic item can have multiple behaviors, but all of those behaviors must be animated by the same animator object.
For information about the behaviors you can apply, see UIKit Framework Reference.
Battery life is an important consideration for users of iOS devices and the multitasking model in iOS is designed to maximize battery life while giving apps the time they need to do critical work. When the user presses the Home button, the foreground app shifts to a background execution context. If the app has no more work to do, it is suspended from active execution and put into a "freeze-dried” state, where it remains in memory but does not execute any code. Apps that do need specific types of work can ask the system for background execution time. For example:
An app can request a finite amount of time to complete some important task.
An app that supports specific services (such as audio playback) can request time to provide those services.
An app can use local notifications to generate user alerts at designated times, whether or not the app is running.
An app can download content periodically from the network.
An app can download content in response to a push notification.
For information on how to support the iOS multitasking model, see App Programming Guide for iOS.
Auto layout helps you build dynamic interfaces with very little code. Using Auto Layout, you define rules for how to lay out the elements in your user interface. These rules express a larger class of relationships and are more intuitive to use than the springs and struts model that was used previously. For example, you can specify that a button always be 20 points from the left edge of its parent view.
The entities used in Auto Layout are Objective-C objects called constraints. Constraints provide several benefits:
They support localization through the swapping of strings alone, instead of requiring you to update your layouts.
They support mirroring of user interface elements for right-to-left languages, such as Hebrew and Arabic.
They promote a better separation of responsibilities between objects in the view and controller layers.
A view object usually has values for its standard size, its positioning within its superview, and its positioning relative to its sibling views. A view controller can override these values if something nonstandard is required.
For more information about using Auto Layout, see Auto Layout Guide.
Storyboards are the recommended way to design your app’s user interface. Storyboards let you design your entire user interface in one place so that you can see all of your views and view controllers and understand how they work together. An important part of storyboards is the ability to define segues, which are transitions from one view controller to another. These transitions allow you to capture the flow of your user interface in addition to the content. You can define these transitions visually, in Xcode, or initiate them programmatically.
You can use a single storyboard file to store all of your app’s view controllers and views, or you can use multiple view storyboards to organize portions of your interface. At build time, Xcode takes the contents of the storyboard file and divides it into discrete pieces that can be loaded individually for better performance. Your app never needs to manipulate these pieces directly. The UIKit framework provides convenience classes for accessing the contents of a storyboard from your code.
For more information about using storyboards to design your interface, see Xcode Overview. For information about how to access storyboards from your code, see the UIStoryboard Class Reference.
UI State Preservation
State preservation provides a seamless experience for users by having your app appear to be always running, even when it was not. If the system encounters memory pressure, it may be forced to terminate one or more background apps quietly. When an app moves from the foreground to the background, it can preserve the state of its views and view controllers. During its next launch cycle, it can use that preserved state information to restore its views and view controllers to their previous configurations and make it appear as if the app had never quit.
For more information about how to add state preservation support to your app, see App Programming Guide for iOS.
Apple Push Notification Service
Apple Push Notification service provides a way to alert users about new information, even when your app is not actively running. Using this service, you can push text notifications, add a badge to your app icon, or trigger audible alerts on user devices at any time. These messages let users know that they should open your app to receive the related information. In iOS 7, you can even push silent notifications to let your app know that new content is available to download.
From a design standpoint, there are two parts to making push notifications work for iOS apps. First, the app must request the delivery of notifications and process the notification data once it is delivered. Second, you need to provide a server-side process to generate the notifications in the first place. This process lives on your own local server and works with Apple Push Notification Service to trigger the notifications.
For more information about how to configure your app to use remote notifications, see Local and Remote Notification Programming Guide.
Local notifications complement the existing push notification mechanism by giving apps a way to generate the notifications locally instead of relying on an external server. Apps running in the background can use local notifications as a way to get a user’s attention when important events happen. For example, a navigation app running in the background can use local notifications to alert the user when it is time to make a turn. Apps can also schedule the delivery of local notifications for a future date and time and have those notifications delivered even if the app is not running.
An advantage of local notifications is that they are independent of your app. After a notification is scheduled, the system manages the delivery of it. Your app does not even have to be running when the notification is delivered.
For more information about using local notifications, see Local and Remote Notification Programming Guide.
Gesture recognizers detect common types of gestures, such as swipes and pinches in your app’s views. Because they use the same heuristics as the system for detecting gestures, gesture recognizers offer a consistent behavior for your apps. To use one, you attach the gesture recognizer to your view and give it an action method to perform when the gesture occurs. The gesture recognizer does the difficult work of tracking the raw touch events and determining when they constitute the intended gesture.
All gesture recognizers are based on the
UIGestureRecognizer class, which defines the basic behavior. UIKit supplies standard gesture recognizer subclasses to detect taps, pinches, pans, swipes, rotations. You can also tailor the behavior of most gesture recognizers to your app’s needs. For example, you can tell a tap gesture recognizer to detect a specific number of taps before calling your action method.
For more information about the available gesture recognizers, see Event Handling Guide for iOS.
Standard System View Controllers
Many system frameworks define view controllers for standard system interfaces. Whenever possible, use the provided view controllers rather than create your own. You are encouraged to use these view controllers in your apps to present a consistent user experience. Whenever you need to perform one of the following tasks, you should use a view controller from the corresponding framework:
Display or edit contact information. Use the view controllers in the Address Book UI framework.
Create or edit calendar events. Use the view controllers in the EventKit UI framework.
Compose an email or SMS message. Use the view controllers in the Message UI framework.
Open or preview the contents of a file. Use the
UIDocumentInteractionControllerclass in the UIKit framework.
Take a picture or choose a photo from the user’s photo library. Use the
UIImagePickerControllerclass in the UIKit framework.
Shoot a video clip. Use the
UIImagePickerControllerclass in the UIKit framework.
For information on how to present and dismiss view controllers, see View Controller Programming Guide for iOS. For information about the interface presented by a specific view controller, see View Controller Catalog for iOS.
Cocoa Touch Frameworks
The following sections describe the frameworks of the Cocoa Touch layer and the services they offer.
Address Book UI Framework
The Address Book UI framework (
AddressBookUI.framework) is an Objective-C programming interface that you use to display standard system interfaces for creating new contacts and for editing and selecting existing contacts. This framework simplifies the work needed to display contact information in your app and also makes sure that your app uses the same interfaces as other apps, thus ensuring consistency across the platform.
For more information about the classes of the Address Book UI framework and how to use them, see Address Book Programming Guide for iOS and Address Book UI Framework Reference for iOS.
EventKit UI Framework
The EventKit UI framework (
EventKitUI.framework) provides view controllers for presenting the standard system interfaces for viewing and editing calendar-related events. This framework builds upon the event-related data in the EventKit framework, which is described in Event Kit Framework.
For more information about the classes and methods of this framework, see Event Kit UI Framework Reference.
The GameKit framework (
GameKit.framework) implements support for Game Center, which lets users share their game-related information online. Game Center provides support for the following features:
Aliases, to allow users to create their own online persona. Users sign in to Game Center and interact with other players anonymously through their alias. Players can set status messages as well as mark specific people as their friends.
Leaderboards, to allow your app to post user scores to Game Center and retrieve them later. You might use this feature to show the best scores among all users of your app.
Matchmaking, to allow you to create multiplayer games by connecting players who are logged into Game Center. Players do not have to be local to each other to join a multiplayer game.
Achievements, to allow you to record the progress a player has made in your game.
Challenges, to allow a player to challenge a friend to beat an achievement or score. (iOS 6 and later)
Turn-based gaming, to create persistent matches whose state is stored in iCloud.
For more information about how to use the GameKit framework, see Game Center Programming Guide and Game Kit Framework Reference.
The iAd framework (
iAd.framework) lets you deliver banner-based advertisements from your app. Advertisements are incorporated into standard views that you integrate into your user interface and present when you want. The views themselves work with Apple’s iAd Service to automatically handle all the work associated with loading and presenting rich media ads and responding to taps in those ads.
For more information about using iAd in your apps, see iAd Programming Guide and iAd Framework Reference.
The MapKit framework (
MapKit.framework) provides a scrollable map that you can incorporate into your app’s user interface. Beyond just displaying a map, you can use the framework interfaces to customize the map’s content and appearance. You can flag points of interest using annotations, and you can use custom overlays to intersperse your own content with the map content. For example, you might use an overlay to draw a bus route, or use annotations to highlight nearby shops and restaurants.
In addition to displaying maps, the MapKit framework integrates with the Maps app and Apple’s map servers to facilitate directions. From the Maps app, users can delegate the providing of directions to any app that supports directions. Apps that provide specialized types of directions, such as subway routes, can register to provide those directions when asked. Apps can also request walking and driving directions from Apple servers and merge that route information with their custom directions to provide a complete point-to-point experience for the user.
For more information about using classes of the MapKit framework, see Location and Maps Programming Guide and Map Kit Framework Reference.
Message UI Framework
The Message UI framework (
MessageUI.framework) provides support for composing email or SMS messages from your app. The composition support consists of a view controller interface that you present in your app. You can populate the fields of this view controller to set the recipients, subject, body content, and any attachments you want to include with the message. After presenting the view controller, the user then has the option of editing the message before sending it.
For more information about the classes of the Message UI framework, see Message UI Framework Reference. For information about using the classes of this framework, see System Messaging Programming Topics for iOS.
Notification Center Framework
The Notification Center framework (
NotificationCenter.framework) provides support for creating widgets that display information in Notification Center. For information about how to create notification center widgets, see App Extension Programming Guide and Notification Center Framework Reference.
The PushKit framework (PushKit.framework) provides registration support for VoIP apps. This framework replaces the previous APIs for registering VoIP apps. Instead of keeping a persistent connection open, and thus draining the device’s battery, an app can use this framework to receive push notifications when there is an incoming call.
For information about the interfaces of this framework, see the framework header files.
The Twitter framework (
Twitter.framework) has been replaced by the Social framework, which supports a UI for generating tweets and support for creating URLs to access the Twitter service. For more information, see Social Framework.
The UIKit framework (
UIKit.framework) provides crucial infrastructure for implementing graphical, event-driven apps in iOS, including the following:
Basic app management and infrastructure, including the app’s main run loop
User interface management, including support for storyboards and nib files
A view controller model to encapsulate the contents of your user interface
Objects representing the standard system views and controls
Support for handling touch- and motion-based events
Support for a document model that includes iCloud integration; see Document-Based App Programming Guide for iOS
Graphics and windowing support, including support for external displays; see View Programming Guide for iOS
Multitasking support; see Multitasking
Printing support; see Drawing and Printing Guide for iOS
Support for customizing the appearance of standard UIKit controls
Support for text and web content
Cut, copy, and paste support
Support for animating user-interface content
Integration with other apps on the system through URL schemes and framework interfaces
Accessibility support for disabled users
Support for the Apple Push Notification service; see Apple Push Notification Service
Local notification scheduling and delivery; see Local Notifications
Support for using custom input views that behave like the system keyboard
Support for creating custom text views that interact with the system keyboard
Support for sharing content through email, Twitter, Facebook, and other services
In addition to providing the fundamental code for building your app, UIKit also incorporates support for some device-specific features, such as the following:
The built-in camera (where present)
The user’s photo library
Device name and model information
Battery state information
Proximity sensor information
Remote control information from attached headsets
For information about the classes of the UIKit framework, see UIKit Framework Reference.