The Cocoa Touch layer contains the key frameworks for building iOS applications. The technologies in this layer provide the infrastructure you need to implement the visual interface of your application and interact with many high-level system services. When developing your applications, you should always start with these frameworks and drop down to lower-level frameworks only as needed.
The following sections describe some of the more common features you might want to support in your applications.
Applications built using iPhone SDK 4.0 or later (and running in iOS 4.0 and later) are no longer terminated when the user presses the Home button; instead, they now shift to a background execution context. For many applications, this means that the application enters a suspended state of execution shortly after entering the background. Keeping the application in memory avoids the subsequent launch cycle and allows an application to simply reactivate itself, which improves the overall user experience. And suspending the application improves overall system performance by minimizing power usage and giving more execution time to the foreground application.
Although most applications are suspended shortly after moving to the background, applications that need to continue working in the background may do so using one of the following techniques:
An application can request a finite amount of time to complete some important task.
An application can declare itself as supporting specific services that require regular background execution time.
An application can use local notifications to generate user alerts at designated times, whether or not the application is running.
Regardless of whether your application is suspended or continues running in the background, supporting multitasking does require some additional work on your part. Background applications can still be terminated under certain conditions (such as during low-memory conditions), and so applications must be ready to exit at any time. This means that many of the tasks you used to perform at quit time must now be performed when your application moves to the background. This requires implementing some new methods in your application delegate to respond to application state transitions.
For more information on how to handle the new background state transitions, and for information on how to continue running in the background, see iOS Application Programming Guide.
Applications that work with sensitive user data can now take advantage of the built-in encryption available on some devices to protect that data. When your application designates a particular file as protected, the system stores that file on-disk in an encrypted format. While the device is locked, the contents of the file are inaccessible to both your application and to any potential intruders. However, when the device is unlocked by the user, a decryption key is created to allow your application to access the file.
Implementing data protection requires you to be considerate in how you create and manage the data you want to protect. Applications must themselves be designed to secure the data at creation time and to be prepared for changes in access to that data when the user locks and unlocks the device.
For more information about how to add data protection to the files of your application, see “Implementing Standard Application Behaviors” in iOS Application Programming Guide.
In iOS 3.0 and later, the Apple Push Notification Service provides a way to alert your users of new information, even when your application is not actively running. Using this service, you can push text notifications, trigger audible alerts, or add a numbered badge to your application icon. These messages let users know that they should open your application to receive the related information.
From a design standpoint, there are two parts to making push notifications work for your iOS applications. First, you need to request the delivery of notifications to your iOS application and then you need to configure your application delegate to process them. The delegate works together with the shared UIApplication object to perform both of these tasks. 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 application to use remote notifications, see Local and Push Notification Programming Guide.
Introduced in iOS 4.0, local notifications complement the existing push notifications by giving applications an avenue for generating the notifications locally instead of relying on an external server. Background applications can use local notifications as a way to get a user’s attention when important events happen. For example, a navigation application running in the background can use local notifications to alert the user when it is time to make a turn. Applications can also schedule the delivery of local notifications for a future date and time and have those notifications delivered even if the application is not running.
The advantage of local notifications is that they are independent of your application. Once a notification is scheduled, the system manages the delivery of it. Your application does not even have to be running when the notification is delivered.
For more information about using local notifications, see Local and Push Notification Programming Guide.
Introduced in iOS 3.2, gesture recognizers are objects that you attach to views and use to detect common types of gestures. After attaching it to your view, you tell it what action you want performed when the gesture occurs. The gesture recognizer object then tracks the raw events and applies the system-defined heuristics for what the given gesture should be. Prior to gesture recognizers, the process for detecting a gesture involved tracking the raw stream of touch events coming to your view and applying potentially complicated heuristics to determine whether the events represented the given gesture.
UIKit now includes a UIGestureRecognizer class that defines the basic behavior for all gesture recognizers. You can define your own custom gesture recognizer subclasses or use one of the system-supplied subclasses to handle any of the following standard gestures:
Tapping (any number of taps)
Pinching in and out (for zooming)
Panning or dragging
Swiping (in any direction)
Rotating (fingers moving in opposite directions)
Long presses
For more information about the available gesture recognizers, see Event Handling Guide for iOS.
Applications that want to make user data files accessible can do so using application file sharing. File sharing enables the application to expose the contents of its /Documents directory to the user through iTunes. The user can then move files back and forth between the iPad and a desktop computer. This feature does not allow your application to share files with other applications on the same device, though. To share data and files between applications, you must use the pasteboard or a document interaction controller object.
To enable file sharing for your application, do the following:
Add the UIFileSharingEnabled key to your application’s Info.plist file and set the value of the key to YES.
Put whatever files you want to share in your application’s Documents directory.
When the device is plugged into the user’s computer, iTunes 9.1 displays a File Sharing section in the Apps tab of the selected device.
The user can add files to this directory or move files to the desktop.
Applications that support file sharing should be able to recognize when files have been added to the Documents directory and respond appropriately. For example, your application might make the contents of any new files available from its interface. You should never present the user with the list of files in this directory and ask them to decide what to do with those files.
For additional information about the UIFileSharingEnabled key, see Information Property List Key Reference.
In iOS 3.0 and later, peer-to-peer connectivity over Bluetooth is provided by the Game Kit framework. You can use peer-to-peer connectivity to initiate communication sessions with nearby devices and implement many of the features found in multiplayer games. Although primarily used in games, you can also use these features in other types of applications.
For information about how to use peer-to-peer connectivity features in your application, see Game Kit Programming Guide. For an overview of the Game Kit framework, see “Game Kit Framework.”
Many of the frameworks in the Cocoa Touch layer contain view controllers for presenting standard system interfaces. You are encouraged to use these view controllers in your applications so as 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 Event Kit 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 UIDocumentInteractionController class in the UIKit framework.
Take a picture or choose a photo from the user’s photo library - Use the UIImagePickerController class in the UIKit framework.
Shoot a video clip - Use the UIImagePickerController class 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 the corresponding framework reference.
Introduced in iOS 3.2, iOS–based devices can be connected to an external display through a set of supported cables. When connected, the associated screen can be used by the application to display content. Information about the screen, including its supported resolutions, is accessible through the interfaces of the UIKit framework. You also use that framework to associate your application’s windows with one screen or another.
The UIScreen class provides support for retrieving screen objects for all available screens (including the device’s main screen). Each screen object contains information about the properties of the screen itself, including the dimensions that correctly take into account the size and pixel aspect ratio of the screen.
The UIScreenMode class provides information about one particular size and pixel aspect ratio setting of a screen.
Windows (represented by the UIWindow class) can now be assigned to a specific screen. To mirror content, you must provide two separate windows and display the same content in both.
For more information about the support offered by these classes, see the individual class descriptions in UIKit Framework Reference.
The following sections describe the frameworks of the Cocoa Touch layer and the services they offer.
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 application and also ensures that your application uses the same interfaces as other applications, 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.
Introduced in iOS 4.0, the Event Kit UI framework (EventKitUI.framework) provides view controllers for presenting the standard system interfaces for viewing and editing events. This framework builds upon the event-related data in the Event Kit framework, which is described in “Event Kit Framework.”
For more information about the classes and methods of this, see Event Kit UI Framework Reference.
Introduced in iOS 3.0, the Game Kit framework (GameKit.framework) lets you add peer-to-peer network capabilities to your applications. Specifically, this framework provides support for peer-to-peer connectivity and in-game voice features. Although these features are most commonly found in multiplayer network games, you can incorporate them into non-game applications as well. The framework provides you with networking features through a simple (yet powerful) set of classes built on top of Bonjour. These classes abstract out many of the network details, making it easy for developers who might be inexperienced with networking programming to incorporate networking features into their applications.
For more information about how to use the Game Kit framework, see Game Kit Programming Guide and Game Kit Framework Reference.
Introduced in iOS 4.0, the iAd (iAd.framework) lets you deliver banner-based advertisements from your application. 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 ad service to automatically handle all the work associated with loading and presenting the ad content and responding to taps in those ads.
For more information about using iAd in your applications, see iAd Framework Reference.
Introduced in iOS 3.0, the Map Kit framework (MapKit.framework) provides a map interface that you can embed into your own application. Based on the behavior of this interface within the Maps application, this interface provides a scrollable map view that can be annotated with custom information. You can embed this view inside of your own application views and programmatically set various attributes of the map, including the currently displayed map region and the user’s location. You can also define custom annotations or use standard annotations (such as a pin marker) to highlight regions of the map and display additional information.
In iOS 4.0, this framework added support for draggable annotations and custom overlays. Draggable annotations allow you to reposition an annotation, either programmatically or through user interactions, after it has been placed on the map. Overlays offer a way to create complex map annotations that comprise more than one point. You can use overlays to layer information such as bus routes, election maps, park boundaries, or weather information (such as radar data) on top of the map.
For more information about the classes of the Map Kit framework, see Map Kit Framework Reference.
Introduced in iOS 3.0, the Message UI framework (MessageUI.framework) provides support for composing and queuing email messages in the user’s outbox. The composition support consists of a view controller interface that you can present in your application. You can populate the fields of this interface with the contents of the message you want to send. You can set the recipients, subject, body content, and any attachments you want to include with the message. The user then has the option of editing the message prior to accepting it. Once accepted, the message is queued in the user’s outbox for delivery.
In iOS 4.0 and later, this framework provides a view controller for presenting an SMS composition panel. You can use this view controller to create and edit SMS messages without leaving your application. As with the mail composition interface, this interface gives the user the option to edit the message before sending it.
For more information about the classes of the Message UI framework, see Message UI Framework Reference.
The UIKit framework (UIKit.framework) contains Objective-C programming interfaces that provide the key infrastructure for implementing graphical, event-driven applications in iOS. Every application in iOS uses this framework to implement its core set of features:
Application management
User interface management
Graphics and windowing support
Multitasking support
Support for handling touch and motion-based events
Objects representing the standard system views and controls
Support for text and web content
Cut, copy, and paste support
Support for animating user-interface content
Integration with other applications on the system through URL schemes
Support for the Apple push notification service; see “Apple Push Notification Service”
Accessibility support for disabled users
Local notification scheduling and delivery
PDF creation
Support for using custom input views that behave like the system keyboard
Support for creating custom text views that interact with the system keyboard
In addition to providing the fundamental code for building your application, UIKit also incorporates support for some device-specific features, such as the following:
Accelerometer data
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.
Last updated: 2010-07-08