Apple iOS Technical Overview

Core Image provides advanced support for manipulating video and still images; see

“Core Image

Framework”

(page 26).

OpenGL ES and GLKit provide support for 2D and 3D rendering using hardware-‐accelerated interfaces; see

“OpenGL ES Framework”

(page 29) and

“GLKit Framework”

(page 28).

Core Text provides a sophisticated text layout and rendering engine; see

“Core Text Framework”

27).

Image I/O provides interfaces for reading and writing most image formats; see

“Image I/O Framework”

(page

27).

The Assets Library framework provides access to the photos and videos in the user’s photo library; see

“Assets Library Framework”

(page 24).

For the most part, applications running on devices with Retina displays should work with little or no modifications. Any content you draw is automatically scaled as needed to support high-‐resolution screens. For vector-‐based drawing code, the system frameworks automatically use any extra pixels to improve the crispness iOS 6.0 | © 2012 Apple Inc. All Rights Reserved.

Media Layer

Audio Technologies of your content. And if you use images in your application, UIKit provides support for loading high-‐resolution variants of your existing images automatically. For more information about what you need to do to support high-‐resolution screens, see

“App-‐Related Resources” in iOS App Programming Guide .

For information about the graphics-‐related frameworks, see the corresponding entries in

“Media Layer

Frameworks”

(page 24).

Audio Technologies

The audio technologies available in iOS are designed to help you provide a rich audio experience for your users. This experience includes the ability to play high-‐quality audio, record high-‐quality audio, and trigger the vibration feature on certain devices.

The system provides several ways to play back and record audio content. The frameworks in the following list are ordered from high level to low level, with the Media Player framework offering the highest-‐level interfaces you can use. When choosing an audio technology, remember that higher-‐level frameworks are easier to use and are generally preferred. Lower-‐level frameworks offer more flexibility and control but require you to do more work.

●

The Media Player framework provides easy access to the user’s iTunes library and support for playing tracks and playlists; see

“Media Player Framework”

(page 28).

The AV Foundation framework provides a set of easy-‐to-‐use Objective-‐C interfaces for managing audio playback and recording; see

“AV Foundation Framework”

(page 25).

OpenAL provides a set of cross-‐platform interfaces for delivering positional audio; see

“OpenAL

Framework”

The Core Audio frameworks offer both simple and sophisticated interfaces for playing and recording audio content. You use these interfaces for playing system alert sounds, triggering the vibrate capability of a device, and managing the buffering and playback of multichannel local or streamed audio content; see

“Core Audio”

The audio technologies in iOS support the following audio formats:

●

AAC

Apple Lossless (ALAC)

A-‐law

IMA/ADPCM (IMA4)

Linear PCM

Media Layer

Video Technologies

●

DVI/Intel IMA ADPCM

Microsoft GSM 6.10

AES3-‐2003

For information about each of the audio frameworks, see the corresponding entry in

“Media Layer

Frameworks”

(page 24).

Video Technologies

Whether you are playing movie files from your application or streaming them from the network, iOS provides several technologies to play your video-‐based content. On devices with the appropriate video hardware, you can also use these technologies to capture video and incorporate it into your application.

The system provides several ways to play and record video content that you can choose depending on your needs. When choosing a video technology, remember that the higher-‐level frameworks simplify the work you have to do to support the features you need and are generally preferred. The frameworks in the following list are ordered from highest to lowest level, with the Media Player framework offering the highest-‐level interfaces you can use.

●

The

UIImagePickerController class in UIKit provides a standard interface for recording video on devices with a supported camera.

The Media Player framework provides a set of simple-‐to-‐use interfaces for presenting full-‐ or partial-‐screen movies from your application; see

“Media Player Framework”

(page 28).

●

The AV Foundation framework provides a set of Objective-‐C interfaces for managing the capture and playback of movies; see

“AV Foundation Framework”

(page 24). For more information on using the

Core Media describes the low-‐level data types used by the higher-‐level frameworks and provides low-‐level interfaces for manipulating media; see

“Core Media Framework”

(page 38).

The video technologies in iOS support the playback of movie files with the .mov

, .mp4

, .m4v

, and .3gp

filename extensions and using the following compression standards:

●

H.264 video, up to 1.5 Mbps, 640 by 480 pixels, 30 frames per second, Low-‐Complexity version of the H.264

Baseline Profile with AAC-‐LC audio up to 160 Kbps, 48 kHz, stereo audio in

.m4v

.mp4

, and

.mov

file formats

H.264 video, up to 768 Kbps, 320 by 240 pixels, 30 frames per second, Baseline Profile up to Level 1.3 with

AAC-‐LC audio up to 160 Kbps, 48 kHz, stereo audio in .m4v

, .mp4

, and .mov

file formats

MPEG-‐4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-‐LC audio up to 160 Kbps, 48 kHz, stereo audio in .m4v

, .mp4

, and .mov

Media Layer

AirPlay

●

Numerous audio formats, including the ones listed in

“Audio Technologies”

(page 22)

For information about each of the video frameworks in the Media layer, see the corresponding entry in

“Media

Layer Frameworks”

UIImagePickerController class, see

Camera Programming Topics for iOS .

AirPlay

AirPlay is a technology that lets your application stream audio to Apple TV and to third-‐party AirPlay speakers and receivers. AirPlay support is built in to the AV Foundation framework and the Core Audio family of frameworks. Any audio content you play using these frameworks is automatically made eligible for AirPlay distribution. Once the user chooses to play your audio using AirPlay, it is routed automatically by the system.

In iOS 5, users can mirror the content of an iPad 2 to an Apple TV 2 using AirPlay for any application. And developers who want to display different content (instead of mirroring) can assign a new window object to any UIScreen objects connected to an iPad 2 via AirPlay. iOS 5 also offers more ways to deliver content over

AirPlay, including using the AVPlayer class in the AV Foundation framework and the UIWebView class in the

UIKit framework. In addition, the Media Player framework now includes support for displaying “Now Playing” information in several places, including as part of the content delivered over AirPlay.

For information on how to take advantage of AirPlay, see

AirPlay Overview .

Media Layer Frameworks

The following sections describe the frameworks of the Media layer and the services they offer.

Assets Library Framework

Introduced in iOS 4.0, the Assets Library framework ( AssetsLibrary.framework

) provides a query-‐based interface for retrieving photos and videos from the user’s device. Using this framework, you can access the same assets that are normally managed by the Photos application, including items in the user’s saved photos album and any photos and videos that were imported onto the device. You can also save new photos and videos back to the user’s saved photos album.

For more information about the classes and methods of this framework, see Assets Library Framework Reference .

Media Layer

Media Layer Frameworks

AV Foundation Framework

Introduced in iOS 2.2, the AV Foundation framework ( AVFoundation.framework

) contains Objective-‐C classes for playing audio content. You can use these classes to play file-‐ or memory-‐based sounds of any duration. You can play multiple sounds simultaneously and control various playback aspects of each sound.

In iOS 3.0 and later, this framework also includes support for recording audio and managing audio session information.

In iOS 4.0 and later, the services offered by this framework were expanded to include:

●

Media asset management

Media editing

Movie capture

Movie playback

Track management

Metadata management for media items

Stereophonic panning

Precise synchronization between sounds

An Objective-‐C interface for determining details about sound files, such as the data format, sample rate, and number of channels

In iOS 5, the AV Foundation framework includes support for streaming audio and video content over AirPlay using the AVPlayer class. AirPlay support is enabled by default, but applications can opt out as needed.

The AV Foundation framework is a single source for recording and playing back audio and video in iOS. This framework also provides much more sophisticated support for handling and managing media items than higher-‐level frameworks.

For more information about the classes of the AV Foundation framework, see

AV Foundation Framework

Reference .

Core Audio

Native support for audio is provided by the Core Audio family of frameworks, which are listed in Table 2-‐1.

Core Audio is a C-‐based interface that supports the manipulation of stereo-‐based audio. You can use Core

Audio in iOS to generate, record, mix, and play audio in your applications. You can also use Core Audio to trigger the vibrate capability on devices that support it.

Media Layer

Media Layer Frameworks

Table 2-1

Core Audio frameworks

Framework Services

CoreAudio.framework

Defines the audio data types used throughout Core Audio.

Framework Reference .

Core Audio

AudioToolbox.framework

AudioUnit.framework

Provides playback and recording services for audio files and streams.

This framework also provides support for managing audio files, playing system alert sounds, and triggering the vibrate capability on some devices. See Audio Toolbox Framework Reference .

Provides services for using the built-‐in audio units, which are audio processing modules.

Audio Unit Framework Reference .

CoreMIDI.framework

MediaToolbox.framework

Provides low-‐level MIDI services. See Core MIDI Framework Reference .

Provides access to the audio tap interfaces.

For more information about Core Audio, see Core Audio Overview . For information about how to use the Audio

Toolbox framework to play sounds, see Audio Queue Services Programming Guide .

Core Graphics Framework

The Core Graphics framework ( CoreGraphics.framework

) contains the interfaces for the Quartz 2D drawing

API.

Quartz is the same advanced, vector-‐based drawing engine that is used in OS X. It provides support for path-‐based drawing, anti-‐aliased rendering, gradients, images, colors, coordinate-‐space transformations, and

PDF document creation, display, and parsing. Although the API is C based, it uses object-‐based abstractions to represent fundamental drawing objects, making it easy to store and reuse your graphics content.

For more information on how to use Quartz to draw content, see Quartz 2D Programming Guide and Core

Graphics Framework Reference .

Core Image Framework

Introduced in iOS 5, the Core Image framework ( CoreImage.framework

) provides a powerful set of built-‐in filters for manipulating video and still images. You can use the built-‐in filters for everything from simple operations (like touching up and correcting photos) to more advanced operations (like face and feature detection). The advantage of using these filters is that they operate in a nondestructive manner so that your original images are never changed directly. In addition, Core Image takes advantage of the available CPU and

GPU processing power to ensure that operations are fast and efficient.

Media Layer

Media Layer Frameworks

The CIImage class provides access to a standard set of filters that you can use to improve the quality of a photograph. To create other types of filters, you can create and configure a CIFilter object for the appropriate filter type.

For information about the classes and filters of the Core Image framework, see Core Image Reference Collection .

Core MIDI Framework

Introduced in iOS 4.2, the Core MIDI framework (

CoreMIDI.framework

) provides a standard way to communicate with MIDI devices, including hardware keyboards and synthesizers. You use this framework to send and receive MIDI messages and to interact with MIDI peripherals connected to an iOS-‐based device using the dock connector or network.

For more information about using this framework, see Core MIDI Framework Reference .

Core Text Framework

Introduced in iOS 3.2, the Core Text framework ( CoreText.framework

) contains a set of simple, high-‐performance C-‐based interfaces for laying out text and handling fonts. The Core Text framework provides a complete text layout engine that you can use to manage the placement of text on the screen. The text you manage can also be styled with different fonts and rendering attributes.

This framework is intended for use by applications that require sophisticated text handling capabilities, such as word-‐processing applications. If your application requires only simple text input and display, you should continue to use the existing text classes of the UIKit framework.

For more information about using the Core Text interfaces, see Core Text Programming Guide and Core Text

Reference Collection .

Core Video Framework

Introduced in iOS 4.0, the Core Video framework ( CoreVideo.framework

) provides buffer and buffer pool support for the Core Media framework (described in

“Core Media Framework”

(page 38)). Most applications

never need to use this framework directly.

Image I/O Framework

Introduced in iOS 4.0, the Image I/O framework (

ImageIO.framework

) provides interfaces for importing and exporting image data and image metadata. This framework makes use of the Core Graphics data types and functions and supports all of the standard image types available in iOS.

In iOS 6 and later, you can use this framework to access EXIF and IPTC metadata properties for images.

Media Layer

Media Layer Frameworks

For more information about the functions and data types of this framework, see Image I/O Reference Collection .

GLKit Framework

Introduced in iOS 5, the GLKit framework ( GLKit.framework

) contains a set of Objective-‐C based utility classes that simplify the effort required to create an OpenGL ES 2.0 application. GLKit provides support for four key areas of application development:

●

The GLKView and GLKViewController classes provide a standard implementation of an OpenGL

ES–enabled view and associated rendering loop. The view manages the underlying framebuffer object on behalf of the application; your application just draws to it.

The GLKTextureLoader class provides image conversion and loading routines to your application, allowing it to automatically load texture images into your context. It can load textures synchronously or asynchronously. When loading textures asynchronously, your application provides a completion handler block to be called when the texture is loaded into your context.

The GLKit framework provides implementations of vector, matrix, and quaternions as well as a matrix stack operation that provides the same functionality found in OpenGL ES 1.1.

The

GLKBaseEffect

GLKSkyboxEffect

, and

GLKReflectionMapEffect classes provide existing, configurable graphics shaders that implement commonly used graphics operations. In particular, the

GLKBaseEffect class implements the lighting and material model found in the OpenGL ES 1.1 specification, simplifying the effort required to migrate an application from OpenGL ES 1.1 to OpenGL ES 2.0.

For information about the classes of the GLKit framework, see GLKit Framework Reference .

Media Player Framework

The Media Player framework ( MediaPlayer.framework

) provides high-‐level support for playing audio and video content from your application. You can use this framework to play video using a standard system interface.

In iOS 3.0, support was added for accessing the user’s iTunes music library. With this support, you can play music tracks and playlists, search for songs, and present a media picker interface to the user.

In iOS 3.2, changes were made to support the playback of video from a resizable view. (Previously, only full-‐screen support was available.) In addition, numerous interfaces were added to support the configuration and management of movie playback.

In iOS 5, support was added for displaying “Now Playing” information in the lock screen and multitasking controls. This information can also be displayed on an Apple TV and with content delivered via AirPlay. There are also interfaces for detecting whether video is being streamed over AirPlay.

Media Layer

Media Layer Frameworks

For information about the classes of the Media Player framework, see Media Player Framework Reference . For information on how to use these classes to access the user’s iTunes library, see

iPod Library Access Programming

Guide .

OpenAL Framework

The Open Audio Library (OpenAL) interface is a cross-‐platform standard for delivering positional audio in applications. You can use it to implement high-‐performance, high-‐quality audio in games and other programs that require positional audio output. Because OpenAL is a cross-‐platform standard, the code modules you write using OpenAL on iOS can be ported to many other platforms easily.

For information about OpenAL, including how to use it, see

http://www.openal.org

OpenGL ES Framework

The OpenGL ES framework ( OpenGLES.framework

) provides tools for drawing 2D and 3D content. It is a

C-‐based framework that works closely with the device hardware to provide high frame rates for full-‐screen game-‐style applications.

You always use the OpenGL framework in conjunction with the EAGL interfaces. These interfaces are part of the OpenGL ES framework and provide the interface between your OpenGL ES drawing code and the native window objects defined by UIKit.

In iOS 3.0 and later, the OpenGL ES framework includes support for both the OpenGL ES 2.0 and the OpenGL

ES 1.1 interface specifications. The 2.0 specification provides support for fragment and vertex shaders and is available only on specific iOS-‐based devices running iOS 3.0 and later. Support for OpenGL ES 1.1 is available on all iOS-‐based devices and in all versions of iOS.

For information on how to use OpenGL ES in your applications, see OpenGL ES Programming Guide for iOS .

For reference information, see OpenGL ES Framework Reference .

Quartz Core Framework

The Quartz Core framework ( QuartzCore.framework

) contains the Core Animation interfaces.

Core Animation

is an advanced animation and compositing technology that uses an optimized rendering path to implement complex animations and visual effects. It provides a high-‐level Objective-‐C interface for configuring animations and effects that are then rendered in hardware for performance. Core Animation is integrated into many parts of iOS, including UIKit classes such as

UIView

, providing animations for many standard system behaviors. You can also use the Objective-‐C interface in this framework to create custom animations.

For more information on how to use Core Animation in your applications, see

Core Animation Programming

Guide and Core Animation Reference Collection .

Core Services Layer

The Core Services layer contains the fundamental system services that all applications use. Even if you do not use these services directly, many parts of the system are built on top of them.

High-‐Level Features

The following sections describe some of the key technologies available in the Core Services layer.

iCloud Storage

Introduced in iOS 5, iCloud storage lets your application write user documents and data to a central location and access those items from all of a user’s computers and iOS devices. Making a user’s documents ubiquitous using iCloud means that a user can view or edit those documents from any device without having to sync or transfer files explicitly. Storing documents in a user’s iCloud account also provides a layer of safety for that user. Even if a user loses a device, the documents on that device are not lost if they are in iCloud storage.

There are two ways that applications can take advantage of iCloud storage, each of which has a different intended usage:

●

iCloud document storage—Use this feature to store user documents and data in the user’s iCloud account.

●

iCloud key-value data storage—Use this feature to share small amounts of data among instances of your application.

Most applications will use iCloud document storage to share documents from a user’s iCloud account. This is the feature that users think of when they think of iCloud storage. A user cares about whether documents are shared across devices and can see and manage those documents from a given device. In contrast, the iCloud iOS 6.0 | © 2012 Apple Inc. All Rights Reserved.

Core Services Layer

High-‐Level Features key-‐value data store is not something a user would see. It is a way for your application to share very small amounts of data (tens of kilobytes) with other instances of itself. Applications should use this feature to store noncritical application data, such as preferences, rather than important application data.

For an overview of how you incorporate iCloud support into your application, see iCloud Design Guide .

Core Services Layer

High-‐Level Features

Automatic Reference Counting

Introduced in iOS 5, Automatic Reference Counting (ARC) is a compiler-‐level feature that simplifies the process of managing the lifetimes of Objective-‐C objects. Instead of you having to remember when to retain or release an object, ARC evaluates the lifetime requirements of your objects and automatically inserts the appropriate method calls at compile time.

ARC replaces the traditional managed memory model style of programming found in earlier versions of iOS.

Any new projects you create automatically use ARC. And Xcode provides migration tools to help convert existing projects to use ARC. For more information about ARC itself, see Transitioning to ARC Release Notes .

Block Objects

Introduced in iOS 4.0, block objects are a C-‐level language construct that you can incorporate into your C and

Objective-‐C code. A block object is essentially an anonymous function and the data that goes with that function, something which in other languages is sometimes called a closure or lambda . Blocks are particularly useful as callbacks or in places where you need a way of easily combining both the code to be executed and the associated data.

Core Services Layer

High-‐Level Features

●

As a replacement for delegates and delegate methods

As a replacement for callback functions

To implement completion handlers for one-‐time operations

To facilitate performing a task on all the items in a collection

Together with dispatch queues, to perform asynchronous tasks

For an introduction to block objects and their uses, see A Short Practical Guide to Blocks . For more information about blocks, see Blocks Programming Topics .

Data Protection

Introduced in iOS 4.0, data protection allows applications that work with sensitive user data to take advantage of the built-‐in encryption available on some devices. When your application designates a specific 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.

In iOS 5 and later, data protection includes additional security levels for protected files. These levels let you access an open file even if the user locks the device and access a file after device boot and first unlock, even if the user subsequently locks the device again.

Implementing data protection requires you to be considerate in how you create and manage the data you want to protect. Applications must be designed to secure the data at creation time and to be prepared for access changes when the user locks and unlocks the device.

For more information about how to add data protection to the files of your application, see

iOS App Programming

Guide .

File-‐Sharing Support

Introduced in iOS 3.2, file-‐sharing support lets applications make user data files available via iTunes 9.1 and later. An application that declares its support for file sharing makes the contents of its /Documents directory available to the user. The user can then move files in and out of this directory as needed from iTunes. This feature does not allow your application to share files with other applications on the same device; that behavior requires the pasteboard or a document interaction controller object.

To enable file sharing for your application, do the following:

Add the to

YES

UIFileSharingEnabled key to your application’s Info.plist

file and set the value of the key

Put whatever files you want to share in your application’s Documents directory.

Core Services Layer

High-‐Level Features

When the device is plugged into the user’s computer, iTunes 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 .

Grand Central Dispatch

Introduced in iOS 4.0, Grand Central Dispatch (GCD) is a BSD-‐level technology that you use to manage the execution of tasks in your application. GCD combines an asynchronous programming model with a highly optimized core to provide a convenient (and more efficient) alternative to threading. GCD also provides convenient alternatives for many types of low-‐level tasks, such as reading and writing file descriptors, implementing timers, and monitoring signals and process events.

For more information about how to use GCD in your applications, see Concurrency Programming Guide . For information about specific GCD functions, see Grand Central Dispatch (GCD) Reference .

In-‐App Purchase

Introduced in iOS 3.0, in-‐app purchase gives you the ability to vend content and services from inside your application. This feature is implemented using the Store Kit framework, which provides the infrastructure needed to process financial transactions using the user’s iTunes account. Your application handles the overall user experience and the presentation of the content or services available for purchase.

In iOS 6, support was added for content hosting and for purchasing iTunes content from inside your app. With content hosting, you can now store your downloadable content on Apple’s servers. With iTunes purchase, your app identifies the items you want to make available for purchase but the rest of the transaction is handled for you by Store Kit.

For more information about supporting in-‐app purchase, see In-App Purchase Programming Guide . For additional information about the Store Kit framework, see

“Store Kit Framework”

(page 42).

Core Services Layer

Core Services Frameworks

SQLite

The SQLite library lets you embed a lightweight SQL database into your application without running a separate remote database server process. From your application, you can create local database files and manage the tables and records in those files. The library is designed for general-‐purpose use but is still optimized to provide fast access to database records.

The header file for accessing the SQLite library is located in

<iOS_SDK>

/usr/include/sqlite3.h

, where

<iOS_SDK> is the path to the target SDK in your Xcode installation directory. For more information about using SQLite, go to

http://www.sqlite.org

XML Support

The Foundation framework provides the NSXMLParser class for retrieving elements from an XML document.

Additional support for manipulating XML content is provided by the libXML2 library. This open source library lets you parse or write arbitrary XML data quickly and transform XML content to HTML.

The header files for accessing the libXML2 library are located in the

<iOS_SDK>

/usr/include/libxml2/ directory, where <iOS_SDK> is the path to the target SDK in your Xcode installation directory. For more information about using libXML2, go to

http://xmlsoft.org/index.html

Core Services Frameworks

The following sections describe the frameworks of the Core Services layer and the services they offer.

Accounts Framework

Introduced in iOS 5, the Accounts framework (

Accounts.framework

) provides a single sign-‐on model for certain user accounts. Single sign-‐on improves the user experience, because applications no longer need to prompt a user separately for login information related to an account. It also simplifies the development model for you by managing the account authorization process for your application. In iOS 5.0, applications can use this framework in conjunction with the Twitter framework to access a user’s Twitter account.

For more information about the classes of the Accounts framework, see Accounts Framework Reference .

Core Services Layer

Core Services Frameworks

Address Book Framework

The Address Book framework ( AddressBook.framework

) provides programmatic access to the contacts stored on a user’s device. If your application uses contact information, you can use this framework to access and modify the records in the user’s contacts database. For example, a chat program might use this framework to retrieve the list of possible contacts with which to initiate a chat session and display those contacts in a custom view.

In iOS 6 and later, access to a user’s contacts requires explicit permission from the user. Apps must therefore be prepared for the user to deny that access. Apps are also encouraged to provide Info.plist

keys describing the reason for needing access.

For information about the functions in the Address Book framework, see

Address Book Framework Reference

for iOS .

Ad Support Framework

Introduced in iOS 6, the Ad Support framework (

AdSupport.framework

) provides access to an identifier that apps can use for advertising purposes. This framework also provides a flag that indicates whether the user has opted out of ad tracking. Apps are required to read and honor the opt-‐out flag before trying to access the advertising identifier.

For more information about this framework, see Ad Support Framework Reference .

CFNetwork Framework

The CFNetwork framework ( CFNetwork.framework

) is a set of high-‐performance C-‐based interfaces that use object-‐oriented abstractions for working with network protocols. These abstractions give you detailed control over the protocol stack and make it easy to use lower-‐level constructs such as BSD sockets. You can use this framework to simplify tasks such as communicating with FTP and HTTP servers or resolving DNS hosts. With the CFNetwork framework, you can:

●

Use BSD sockets

Create encrypted connections using SSL or TLS

Resolve DNS hosts

Work with HTTP servers, authenticating HTTP servers, and HTTPS servers

Work with FTP servers

Core Services Layer

Core Services Frameworks

CFNetwork is based, both physically and theoretically, on BSD sockets. For information on how to use CFNetwork, see CFNetwork Programming Guide and CFNetwork Framework Reference .

Core Data Framework

Introduced in iOS 3.0, the Core Data framework ( CoreData.framework

) is a technology for managing the data model of a Model-‐View-‐Controller application. Core Data is intended for use in applications in which the data model is already highly structured. Instead of defining data structures programmatically, you use the graphical tools in Xcode to build a schema representing your data model. At runtime, instances of your data-‐model entities are created, managed, and made available through the Core Data framework.

By managing your application’s data model for you, Core Data significantly reduces the amount of code you have to write for your application. Core Data also provides the following features:

●

Storage of object data in a SQLite database for optimal performance

A NSFetchedResultsController class to manage results for table views

Management of undo/redo beyond basic text editing

Support for the validation of property values

Support for propagating changes and ensuring that the relationships between objects remain consistent

Support for grouping, filtering, and organizing data in memory

If you are starting to develop a new application or are planning a significant update to an existing application, you should consider using Core Data. For an example of how to use Core Data in an iOS application, see

Core

Data Tutorial for iOS . For more information about the classes of the Core Data framework, see Core Data

Framework Reference .

Core Foundation Framework

The Core Foundation framework ( CoreFoundation.framework

) is a set of C-‐based interfaces that provide basic data management and service features for iOS applications. This framework includes support for the following:

●

Collection data types (arrays, sets, and so on)

Bundles

String management

Date and time management

Raw data block management

Core Services Layer

Core Services Frameworks

●

URL and stream manipulation

Threads and run loops

Port and socket communication

The Core Foundation framework is closely related to the Foundation framework, which provides Objective-‐C interfaces for the same basic features. When you need to mix Foundation objects and Core Foundation types, you can take advantage of the “toll-‐free bridging” that exists between the two frameworks.

Toll-free bridging

means that you can use some Core Foundation and Foundation types interchangeably in the methods and functions of either framework. This support is available for many of the data types, including the collection and string data types. The class and type descriptions for each framework state whether an object is toll-‐free bridged and, if so, what object it is connected to.

For more information about this framework, see Core Foundation Framework Reference .

Core Location Framework

The Core Location framework ( CoreLocation.framework

) provides location and heading information to applications. For location information, the framework uses the onboard GPS, cell, or Wi-‐Fi radios to find the user’s current longitude and latitude. You can incorporate this technology into your own applications to provide position-‐based information to the user. For example, you might have a service that searches for nearby restaurants, shops, or facilities, and base that search on the user’s current location.

In iOS 3.0, support was added for accessing compass-‐based heading information on iOS-‐based devices that include a magnetometer.

In iOS 4.0, support was introduced for a low-‐power location-‐monitoring service that uses cellular towers to track changes in the user’s location.

For information about how to use Core Location to gather location and heading information, see

Location

Awareness Programming Guide and Core Location Framework Reference .

Core Media Framework

Introduced in iOS 4.0, the Core Media framework ( CoreMedia.framework

) provides the low-‐level media types used by the AV Foundation framework. Most applications never need to use this framework, but it is provided for those few developers who need more precise control over the creation and presentation of audio and video content.

For more information about the functions and data types of this framework, see

Core Media Framework

Reference .

Core Services Layer

Core Services Frameworks

Core Motion Framework

The Core Motion framework ( CoreMotion.framework

) provides a single set of interfaces for accessing all motion-‐based data available on a device. The framework supports accessing both raw and processed accelerometer data using a new set of block-‐based interfaces. For devices with a built-‐in gyroscope, you can retrieve the raw gyro data as well as processed data reflecting the attitude and rotation rates of the device.

You can use both the accelerometer and gyro-‐based data for games or other applications that use motion as input or as a way to enhance the overall user experience.

For more information about the classes and methods of this framework, see Core Motion Framework Reference .

Core Telephony Framework

Introduced in iOS 4.0, the Core Telephony framework ( CoreTelephony.framework

) provides interfaces for interacting with phone-‐based information on devices that have a cellular radio. Applications can use this framework to get information about a user’s cellular service provider. Applications interested in cellular call events (such as VoIP applications) can also be notified when those events occur.

For more information about using the classes and methods of this framework, see

Core Telephony Framework

Reference .

Event Kit Framework

Introduced in iOS 4.0, the Event Kit framework (

EventKit.framework

) provides an interface for accessing calendar events on a user’s device. You can use this framework to get existing events and add new events to the user’s calendar. Calendar events can include alarms that you can configure with rules for when they should be delivered.

In iOS 6, support was added for creating and accessing reminders on the user’s device. The reminders you create show up in the Reminders app along with ones created by the user. In addition, access to a calendar and reminder data requires explicit permission from the user. Apps must therefore be prepared for the user to deny that access. Apps are also encouraged to provide Info.plist

keys describing the reason for needing access.

For more information about the classes and methods of this framework, see Event Kit Framework Reference .

“Event Kit UI Framework”

(page 16).

Foundation Framework

The Foundation framework ( Foundation.framework

) provides Objective-‐C wrappers to many of the features found in the Core Foundation framework, which is described in

“Core Foundation Framework”

(page 37). The

Core Services Layer

Core Services Frameworks

●

Collection data types (arrays, sets, and so on)

Bundles

String management

Date and time management

Raw data block management

Preferences management

URL and stream manipulation

Threads and run loops

Bonjour

Communication port management

Internationalization

Regular expression matching

Cache support

For information about the classes of the Foundation framework, see Foundation Framework Reference .

Mobile Core Services Framework

Introduced in iOS 3.0, the Mobile Core Services framework ( MobileCoreServices.framework

) defines the low-‐level types used in Uniform Type Identifiers (UTIs).

For more information about the types defined by this framework, see Uniform Type Identifiers Reference .

Newsstand Kit Framework

Introduced in iOS 5, Newsstand provides a central place for users to read magazines and newspapers. Publishers who want to deliver their magazine and newspaper content through Newsstand can create their own iOS applications using the Newsstand Kit framework ( NewsstandKit.framework

), which lets you initiate background downloads of new magazine and newspaper issues. After you start a download, the system handles the download operation and notifies your application when the new content is available.

For information about the classes you use to manage Newsstand downloads, see

Newsstand Kit Framework

Reference . For information about how to use push notifications to notify your applications, see Local and Push

Notification Programming Guide .

Core Services Layer

Core Services Frameworks

Pass Kit Framework

Introduced in iOS 6, Pass Kit uses web services, a new file format, and an Objective-‐C framework

( PassKit.framework

) to implement support for downloadable passes. Companies can create passes to represent items such as coupons, boarding passes, event tickets, and discount cards for businesses. Instead of carrying a physical representation of these items, users can now store them on their iOS device and use them the same way as before.

Passes are created by your company’s web service and delivered to the user’s device via email, Safari, or your custom app. The pass itself uses a special file format and is cryptographically signed before being delivered.

The file format identifies relevant information about the service being offered so that the user knows what it is for. It might also contain a bar code or other information that you can then use to validate the card so that it can be redeemed or used.

For more information about Pass Kit and for information how to add support for it into your apps, see

Passbook

Programming Guide .

Quick Look Framework

Introduced in iOS 4.0, the Quick Look framework ( QuickLook.framework

) provides a direct interface for previewing the contents of files your application does not support directly. This framework is intended primarily for applications that download files from the network or that otherwise work with files from unknown sources.

After obtaining the file, you use the view controller provided by this framework to display the contents of that file directly in your user interface.

For more information about the classes and methods of this framework, see

Quick Look Framework Reference

for iOS .

Social Framework

Introduced in iOS 6, the Social framework (

Social.framework

) provides a simple interface for accessing the user’s social media accounts. This framework supplants the Twitter framework that was introduced in iOS 5 and adds support for other social accounts, including Facebook and Sina’s Weibo service. Apps can use this framework to post status updates and images to a user’s account. This framework works with the Accounts framework to provide a single sign-‐on model for the user and to ensure that access to the user’s account is approved.

For more information about the Social framework, see Social Framework Reference .

Core Services Layer

Core Services Frameworks

Store Kit Framework

Introduced in iOS 3, the Store Kit framework ( StoreKit.framework

) provides support for the purchasing of content and services from within your iOS applications. For example, you could use this feature to allow the user to unlock additional application features. Or if you are a game developer, you could use it to offer additional game levels. In both cases, the Store Kit framework handles the financial aspects of the transaction, processing payment requests through the user’s iTunes Store account and providing your application with information about the purchase.

The Store Kit focuses on the financial aspects of a transaction, ensuring that transactions occur securely and correctly. Your application handles the other aspects of the transaction, including the presentation of a purchasing interface and the downloading (or unlocking) of the appropriate content. This division of labor gives you control over the user experience for purchasing content. You decide what kind of purchasing interface you want to present to the user and when to do so. You also decide on the delivery mechanism that works best for your application.

For information about how to use the Store Kit framework, see In-App Purchase Programming Guide and Store

Kit Framework Reference .

System Configuration Framework

The System Configuration framework ( SystemConfiguration.framework

) provides the reachability interfaces, which you can use to determine the network configuration of a device. You can use this framework to determine whether a Wi-‐Fi or cellular connection is in use and whether a particular host server can be accessed.

For more information about the interfaces of this framework, see System Configuration Framework Reference .

For an example of how to use this framework to obtain network information, see the Reachability sample code project.

Core OS Layer

The Core OS layer contains the low-‐level features that most other technologies are built upon. Even if you do not use these technologies directly in your applications, they are most likely being used by other frameworks.

And in situations where you need to explicitly deal with security or communicating with an external hardware accessory, you do so using the frameworks in this layer.

Accelerate Framework

Introduced in iOS 4.0, the Accelerate framework (

Accelerate.framework

) contains interfaces for performing

DSP, linear algebra, and image-‐processing calculations. The advantage of using this framework over writing your own versions of these interfaces is that they are optimized for all of the hardware configurations present in iOS-‐based devices. Therefore, you can write your code once and be assured that it runs efficiently on all devices.

For more information about the functions of the Accelerate framework, see Accelerate Framework Reference .

Core Bluetooth Framework

The Core Bluetooth framework ( CoreBluetooth.framework

) allows developers to interact specifically with

Bluetooth Low-‐Energy ("LE") accessories. The Objective-‐C interfaces of this framework allow you to scan for LE accessories, connect and disconnect to ones you find, read and write attributes within a service, register for service and attribute change notifications, and much more.

For more information about the interfaces of the Core Bluetooth framework, see

Core Bluetooth Framework

Reference .

Core OS Layer

External Accessory Framework

Introduced in iOS 3.0, the External Accessory framework (

ExternalAccessory.framework

) provides support for communicating with hardware accessories attached to an iOS-‐based device. Accessories can be connected through the 30-‐pin dock connector of a device or wirelessly using Bluetooth. The External Accessory framework provides a way for you to get information about each available accessory and to initiate communications sessions. After that, you are free to manipulate the accessory directly using any commands it supports.

For more information about how to use this framework, see External Accessory Programming Topics . For information about developing accessories for iOS-‐based devices, go to

http://developer.apple.com

Generic Security Services Framework

Introduced in iOS 5, the Generic Security Services framework ( GSS.framework

) provides a standard set of security-‐related services to iOS applications. The basic interfaces of this framework are specified in IETF

RFC

2743

and

RFC 4401

. In addition to offering the standard interfaces, iOS includes some additions for managing credentials that are not specified by the standard but that are required by many applications.

For information about the interfaces of the GSS framework, see the header files.

Security Framework

In addition to its built-‐in security features, iOS also provides an explicit Security framework

( Security.framework

) that you can use to guarantee the security of the data your application manages.

This framework provides interfaces for managing certificates, public and private keys, and trust policies. It supports the generation of cryptographically secure pseudorandom numbers. It also supports the storage of certificates and cryptographic keys in the keychain, which is a secure repository for sensitive user data.

The Common Crypto library provides additional support for symmetric encryption, HMAC, and digests. The digests feature provides functions that are essentially compatible with those in the OpenSSL library, which is not available in iOS.

In iOS 3.0 and later, it is possible for you to share keychain items among multiple applications you create.

Sharing items makes it easier for applications in the same suite to interoperate more smoothly. For example, you could use this feature to share user passwords or other elements that might otherwise require you to prompt the user from each application separately. To share data between applications, you must configure the Xcode project of each application with the proper entitlements.

Core OS Layer

System

For information about the functions and features associated with the Security framework, see

Security Framework

Reference . For information about how to access the keychain, see Keychain Services Programming Guide . For information about setting up entitlements in your Xcode projects, see Tools Workflow Guide for iOS . For information about the entitlements you can configure, see the description for the SecItemAdd function in

Keychain Services Reference .

System

The system level encompasses the kernel environment, drivers, and low-‐level UNIX interfaces of the operating system. The kernel itself is based on Mach and is responsible for every aspect of the operating system. It manages the virtual memory system, threads, file system, network, and interprocess communication. The drivers at this layer also provide the interface between the available hardware and system frameworks. For security purposes, access to the kernel and drivers is restricted to a limited set of system frameworks and applications.

iOS provides a set of interfaces for accessing many low-‐level features of the operating system. Your application accesses these features through the LibSystem library. The interfaces are C-‐based and provide support for the following:

●

Threading (POSIX threads)

Networking (BSD sockets)

File-‐system access

Standard I/O

Bonjour and DNS services

Locale information

Memory allocation

Math computations

Header files for many Core OS technologies are located in the

<iOS_SDK>

/usr/include/ directory, where

<iOS_SDK> is the path to the target SDK in your Xcode installation directory. For information about the functions associated with these technologies, see iOS Manual Pages .

Migrating from Cocoa

If you are a Cocoa developer, many of the frameworks available in iOS should already seem familiar to you.

The basic technology stack in iOS is identical in many respects to the one in OS X. Despite the similarities, however, the frameworks in iOS are not exactly the same as their OS X counterparts. This chapter describes the differences you may encounter as you create iOS applications and explains how you can adjust to some of the more significant differences.

Note: This chapter is intended for developers who are already familiar with Cocoa terminology and programming techniques. If you want to learn more about the basic design patterns used for Cocoa applications (and iOS applications), see Cocoa Fundamentals Guide .

General Migration Notes

If your Cocoa application is already factored using the Model-‐View-‐Controller design pattern, it should be relatively easy to migrate key portions of your application to iOS.

Migrating Your Data Model

Cocoa applications whose data model is based on classes in the Foundation and Core Foundation frameworks can be brought over to iOS with little or no modification. Both frameworks are supported in iOS and are virtually identical to their OS X counterparts. Most of the differences that do exist are relatively minor or are related to features that would need to be removed in the iOS version of your application anyway. For example, iOS applications do not support AppleScript. For a detailed list of differences, see

“Foundation Framework

Differences”

(page 52).

If your Cocoa application is built on top of Core Data, you can migrate that data model to an iOS application in iOS 3.0 and later; Core Data is not supported in earlier versions of iOS. The Core Data framework in iOS supports binary and SQLite data stores (not XML data stores) and supports migration from existing Cocoa applications. For the supported data stores, you can copy your Core Data resource files to your iOS application project and use them as is. For information on how to use Core Data in your Xcode projects, see

Core Data

Programming Guide .

Migrating from Cocoa

General Migration Notes

If your Cocoa application displays lots of data on the screen, you might want to simplify your data model when migrating it to iOS. Although you can create rich applications with lots of data in iOS, keep in mind that doing so may not serve your users’ needs. Mobile users typically want only the most important information, in the least amount of time. Providing the user with too much data all at once can be impractical because of the more limited screen space, and it could also slow down your application because of the extra work required to load that data. Refactoring your Cocoa application’s data structures might be worthwhile if it provides better performance and a better user experience in iOS.

Migrating Your User Interface

The structure and implementation of the user interface in iOS is very different from that of Cocoa applications.

Take, for example, the objects that represent views and windows in Cocoa. Although iOS and Cocoa both have objects representing views and windows, the way those objects work differs slightly on each platform. In addition, you must be more selective about what you display in your views because screen size is limited and views that handle touch events must be large enough to provide an adequate target for a user’s finger.

In addition to differences in the view objects themselves, there are also significant differences in how you display those views at runtime. For example, if you want to display a lot of data in a Cocoa application, you might increase the window size, use multiple windows, or use tab views to manage that data. In iOS applications, there is only one window whose size is fixed, so applications must break information into reasonably sized chunks and present those chunks on different sets of views. When you want to present a new chunk of information, you push a new set of views onto the screen, replacing the previous set. This makes your interface design somewhat more complex, but because it is such a crucial way of displaying information, iOS provides considerable support for this type of organization.

View controllers in iOS are a critical part of managing your user interface. You use view controllers to structure your visual content, to present that content onto the screen, and to handle device-‐specific behaviors such as orientation changes. View controllers also manage views and work with the system to load and unload those views at appropriate times. Understanding the role of view controllers and how you use them in your application is therefore critical to the design of your user interface.

For information about view controllers and how you use them to organize and manage your user interface, see View Controller Programming Guide for iOS . For general information about the user interface design principles of iOS, see iOS Human Interface Guidelines . For additional information about the windows and views you use to build your interface, and the underlying architecture on which they are built, see

View Programming

Guide for iOS .

Migrating from Cocoa

Framework Differences

Memory Management

In iOS, the preferred way to manage memory is automatic reference counting (ARC). With this model, the compiler does the memory management for you by automatically deallocating objects that are not being used by your code. All you have to do is maintain strong references to the objects you want to keep and set those references to nil when you no longer need the objects. You can also use the managed object model whereby you retain and release objects explicitly.

For more information on how to use ARC, see Transitioning to ARC Release Notes .

Framework Differences

Although most of the iOS frameworks are also present in OS X, there are platform differences in how those frameworks are implemented and used. The following sections call out some of the key differences that existing

Cocoa developers might notice as they develop iOS applications.

UIKit Versus AppKit

In iOS, the UIKit framework provides the infrastructure for building graphical applications, managing the event loop, and performing other interface-‐related tasks. The UIKit framework is completely distinct from the AppKit framework, however, and should be treated as such when designing your iOS applications. Therefore, when migrating a Cocoa application to iOS, you must replace a significant number of interface-‐related classes and logic. Table 5-‐1 lists some of the specific differences between the frameworks to help you understand what is required of your application in iOS.

Table 5-1

Differences in interface technologies

Difference Discussion

View classes UIKit provides a very focused set of custom views and controls for you to use. Many of the views and controls found in AppKit would simply not work well on iOS-‐based devices. Other views have more iOS-‐specific alternatives. For example, instead of the

NSBrowser class, iOS uses an entirely different paradigm (navigation controllers) to manage the display of hierarchical information.

For a description of the views and controls available in iOS, along with information on how to use them, see iOS Human Interface Guidelines .

Migrating from Cocoa

Framework Differences

Difference

View coordinate systems

Windows as views

Event handling

Discussion

The drawing model for UIKit views is nearly identical to the model in AppKit, with one exception. AppKit views use a coordinate system where the origin for windows and views is in the lower-‐left corner by default, with axes extending up and to the right. In

UIKit, the default origin point is in the top-‐left corner and the axes extend down and to the right. In AppKit, this coordinate system is known as a modified coordinate system , but for UIKit views it is the default coordinate system.

For more information about view coordinate systems, see

View Programming Guide for

iOS .

Conceptually, windows and views represent the same constructs in UIKit as they do in

AppKit. In implementation terms, however, the two platforms implement windows and views quite differently. In AppKit, the NSWindow class is a subclass of NSResponder , but in UIKit, the

UIWindow class is actually a subclass of

UIView instead. This change in inheritance means that windows in UIKit are backed by Core Animation layers and can perform most of the same tasks that views do.

The main reason for having window objects at all in UIKit is to support the layering of windows within the operating system. For example, the system displays the status bar in a separate window that floats above your application’s window.

Another difference between iOS and OS X relates to the use of windows. Whereas a

OS X application can have any number of windows, most iOS applications have only one. When you want to change the content displayed by your application, you swap out the views of your window rather than create a new window.

The UIKit event-‐handling model is significantly different from the one found in AppKit.

Instead of delivering mouse and keyboard events, UIKit delivers touch and motion events to your views. These events require you to implement a different set of methods but also require you to make some changes to your overall event-‐handling code. For example, you would never track a touch event by extracting queued events from a local tracking loop.

In iOS 3.2 and later, gesture recognizers provide a target-‐action model for responding to standard touch-‐based gestures such as taps, swipes, pinches, and rotations. You can also define your own gesture recognizers for custom gestures.

For more information about handling events in iOS applications, see

Event Handling

Guide for iOS .

Migrating from Cocoa

Framework Differences

Difference

Target-‐action model

Drawing and printing support

Text support

The use of accessor methods versus properties

Discussion

UIKit supports three variant forms for action methods, as opposed to just one for AppKit.

Controls in UIKit can invoke actions for different phases of the interaction and they have more than one target assigned to the same interaction. Thus, in UIKit a control can deliver multiple distinct actions to multiple targets over the course of a single interaction cycle.

For more information about the target-‐action model in iOS applications, see

Event

Handling Guide for iOS .

The drawing capabilities of UIKit are scaled to support the rendering needs of the UIKit classes. This support includes image loading and display, string display, color management, font management, and a handful of functions for rendering rectangles and getting the graphics context. UIKit does not include a general-‐purpose set of drawing classes because several other alternatives (namely, Quartz and OpenGL ES) are already present in iOS.

In iOS 4.2 and later, applications can use the UIKit printing support to deliver data wirelessly to a nearby printer.

For more information about graphics and drawing, see

Drawing and Printing Guide for

iOS .

The primary text support in iOS is geared toward composing email and notes. The UIKit classes let applications display and edit simple strings and somewhat more complex

HTML content.

In iOS 3.2 and later, more sophisticated text handling capabilities are provided through the Core Text and UIKit frameworks. You can use these frameworks to implement sophisticated text editing and presentation views and to support custom input methods for those views.

In iOS 6, and later, UIKit includes support for styled text rendering using the

NSAttributedString class. Several text-‐based views also allow you to specify attributed strings in addition to plain strings.

For more information about text support, see

Text, Web, and Editing Programming

Guide for iOS .

UIKit makes extensive use of properties throughout its class declarations. Properties were introduced to OS X in version 10.5 and thus came along after the creation of many classes in the AppKit framework. Rather than simply mimic the same getter and setter methods in AppKit, properties are used in UIKit as a way to simplify the class interfaces.

For information about how to use properties, see

“Declared Properties” in

The Objective-C

Programming Language .

Migrating from Cocoa

Framework Differences

Difference

Controls and cells

Table views

Menus

Core

Animation layers

Discussion

Controls in UIKit do not use cells. Cells are used in AppKit as a lightweight alternative to views. Because views in UIKit are themselves very lightweight objects, cells are not needed. Despite the naming conventions, the cells designed for use with the

UITableView class are actually based on the

UIView class.

The UITableView class in UIKit can be thought of as a cross between the NSTableView and NSOutlineView classes in the AppKit framework. It uses features from both of those AppKit classes to create a more appropriate tool for displaying data on a smaller screen. The UITableView class displays a single column at a time and allows you to group related rows together into sections. It is also a means for displaying and editing hierarchical lists of information.

In iOS 6, you can use the

UICollectionView class to implement multicolumn and custom layouts.

For more information about creating and using table views, see

Table View Programming

Guide for iOS .

Nearly all applications written for iOS have a much smaller command set than do comparable OS X applications. For this reason, menu bars are not supported in iOS and are generally unnecessary anyway. For those few commands that are needed, a toolbar or set of buttons is usually more appropriate. For data-‐based menus, a picker or navigation controller interface is often more appropriate. For context-‐sensitive commands in iOS, you can display those on the edit menu in addition to (or in lieu of) commands such as Cut, Copy, and Paste.

In iOS, every drawing surface is backed by a Core Animation layer and implicit animation support is provided for many view-‐related properties. Because of the built-‐in animation support, you usually do not need to use Core Animation layers explicitly in your code.

Most animations can be performed simply (and more directly) by changing a property of the affected view. The only time you might need to use layers directly is when you need precise control over the layer tree or when you need features not exposed at the view level.

For information about how Core Animation layers are integrated into the drawing model of iOS, see View Programming Guide for iOS .

For information about the classes of UIKit, see UIKit Framework Reference .

Migrating from Cocoa

Framework Differences

Foundation Framework Differences

A version of the Foundation framework is available in both OS X and iOS, and most of the classes you would expect to be present are available in both. Both frameworks provide support for managing values, strings, collections, threads, and many other common types of data. There are, however, some technologies that are not included in iOS. These technologies are listed in Table 5-‐2, along with the reasons the related classes are not available. Wherever possible, the table lists alternative technologies that you can use instead.

Table 5-2

Foundation technologies unavailable in iOS

Technology Notes

Metadata and predicate management

In iOS 5 and later, the use of metadata queries is supported only for locating files in the user’s iCloud storage. Prior to iOS 5, metadata queries are not supported at all.

Distributed objects and port name server management

The Distributed Objects technology is not available, but you can still use the NSPort family of classes to interact with ports and sockets.

You can also use the Core Foundation and CFNetwork frameworks to handle your networking needs.

Cocoa bindings

AppleScript support

Cocoa bindings are not supported in iOS. Instead, iOS uses a slightly modified version of the target-‐action model that adds flexibility in how you handle actions in your code.

AppleScript is not supported in iOS.

The Foundation framework provides support for XML parsing through the NSXMLParser class. However, other

XML parsing classes (including NSXMLDocument , NSXMLNode , and NSXMLElement ) are not available in iOS.

In addition to the

NSXMLParser class, you can also use the libXML2 library, which provides a C-‐based XML parsing interface.

For a list of the specific classes that are available in OS X but not in iOS, see the class hierarchy diagram in

“The

Foundation Framework” in Foundation Framework Reference .

Changes to Other Frameworks

Table 5-‐3 lists the key differences in other frameworks found in iOS.

Migrating from Cocoa

Framework Differences

Table 5-3

Differences in frameworks common to iOS and OS X

Framework Differences

AddressBook.framework

This framework contains the interfaces for accessing user contacts.

Although it shares the same name, the iOS version of this framework is very different from its OS X counterpart.

In addition to the C-‐level interfaces for accessing contact data, in iOS, you can also use the classes of the Address Book UI framework to present standard picker and editing interfaces for contacts.

For more information, see

Address Book Framework Reference for

iOS .

AudioToolbox.framework

AudioUnit.framework

CoreAudio.framework

The iOS versions of these frameworks provide support primarily for recording, playing, and mixing of single and multichannel audio content. More advanced audio processing features and custom audio unit plug-‐ins are not supported. One addition for iOS, however, is the ability to trigger the vibrate option for iOS-‐based devices with the appropriate hardware.

For information on how to use the audio support, see

Multimedia

Programming Guide .

CFNetwork.framework

CoreGraphics.framework

This framework contains the Core Foundation Network interfaces.

In iOS, the CFNetwork framework is a top-‐level framework and not a subframework. Most of the actual interfaces remain unchanged, however.

For more information, see CFNetwork Framework Reference .

This framework contains the Quartz interfaces. In iOS, the Core

Graphics framework is a top-‐level framework and not a subframework. You can use Quartz to create paths, gradients, shadings, patterns, colors, images, and bitmaps in exactly the same way you do in OS X. There are a few Quartz features that are not present in iOS, however, including PostScript support, image sources and destinations, Quartz Display Services support, and Quartz Event

Services support.

For more information, see Core Graphics Framework Reference .

Migrating from Cocoa

Framework Differences

Framework

OpenGLES.framework

QuartzCore.framework

Security.framework

System-

Configuration.framework

Differences

OpenGL ES is a version of OpenGL designed specifically for embedded systems. If you are an existing OpenGL developer, the

OpenGL ES interface should be familiar to you. However, the OpenGL

ES interface still differs in several significant ways. First, it is a much more compact interface, supporting only those features that can be performed efficiently using the available graphics hardware. Second, many of the extensions you might normally use in desktop OpenGL might not be available to you in OpenGL ES. Despite these differences, you can perform most of the same operations you would normally perform on the desktop. If you are migrating existing

OpenGL code, however, you may have to rewrite some parts of your code to use different rendering techniques in iOS.

For information about the OpenGL ES support in iOS, see

OpenGL

ES Programming Guide for iOS .

This framework contains the Core Animation interfaces. Most of the

Core Animation interfaces are the same for iOS and OS X. However, in iOS, the classes for managing layout constraints and support for using Core Image filters are not available. In addition, the interfaces for Core Image and Core Video (which are also part of the OS X version of the framework) are not available.

For more information, see Quartz Core Framework Reference .

This framework contains the security interfaces. In iOS, it focuses on securing your application data by providing support for encryption and decryption, pseudorandom number generation, and the keychain. The framework does not contain authentication or authorization interfaces and has no support for displaying the contents of certificates. In addition, the keychain interfaces are a simplified version of the ones used in OS X.

For information about the security support, see

iOS App Programming

Guide .

This framework contains networking-‐related interfaces. In iOS, it contains only the reachability interfaces. You use these interfaces to determine how a device is connected to the network, such as whether it’s connected using EDGE, GPRS, or Wi-‐Fi.

iOS Developer Tools

To develop applications for iOS, you need an Intel-‐based Macintosh computer and the Xcode tools. Xcode is

Apple’s suite of development tools that provide support for project management, code editing, building executables, source-‐level debugging, source-‐code repository management, performance tuning, and much more. At the center of this suite is the Xcode application itself, which provides the basic source-‐code development environment. Xcode is not the only tool, though, and the following sections provide an introduction to the key applications you use to develop software for iOS.

Xcode

The focus of your development experiences is the Xcode application. Xcode is an integrated development environment (IDE) that provides all of the tools you need to create and manage your iOS projects and source files, assemble your user interface, build your code into an executable, and run and debug your code either in iOS Simulator or on a device. Xcode incorporates a number of features to make developing iOS applications easier, including the following:

●

A project management system for defining software products

A code-‐editing environment that includes features such as syntax coloring, code completion, and symbol indexing

An integrated editor for creating storyboard and nib files

An advanced documentation viewer for viewing and searching Apple documentation

A context-‐sensitive inspector for viewing information about selected code symbols

An advanced build system with dependency checking and build rule evaluation

LLVM and Clang support for C, C++, and Objective-‐C

GCC compilers supporting C, C++, Objective-‐C, Objective-‐C++, and other languages

A static analyzer for validating the behavior of your app and identifying potential problems.

Integrated source-‐level debugging using GDB

Support for integrated source-‐code management

Support for DWARF and Stabs debugging information (DWARF debugging information is generated by default for all new projects)

Support for managing iOS development devices.

iOS Developer Tools

Xcode

To create a new iOS application, you start by creating a new project in Xcode. A project manages all of the information associated with your application, including the source files, build settings, and rules needed to put all of the pieces together. The heart of every Xcode project is the project window, shown in Figure A-‐1.

This window provides quick access to all of the key elements of your application. In the Groups & Files list, you manage the files in your project, including the source files and build targets that are created from those source files. In the toolbar, you access commonly used tools and commands. You can then configure the workspace to display the panes you need for editing, navigating your project content, debugging, and obtaining additional information about items.

Figure A-1

An Xcode project window

When you build your application in Xcode, you have a choice of building it for iOS Simulator or for a device.

Simulator provides a local environment for testing your applications to make sure they behave essentially the way you want. After you are satisfied with your application’s basic behavior, you can tell Xcode to build your iOS 6.0 | © 2012 Apple Inc. All Rights Reserved.

iOS Developer Tools

Instruments application and run it on an iOS-‐based device connected to your computer. Running your application on a device provides the ultimate test environment, and Xcode lets you attach the built-‐in debugger to the code running there.

Figure A-2

Running a project from Xcode

For details on how to build and run your project on iOS, see Tools Workflow Guide for iOS . For more information about the Xcode environment, see Xcode 4 User Guide .

Instruments

To ensure that you deliver the best user experience for your software, the Instruments environment lets you analyze the performance of your iOS applications while running in Simulator or on a device. Instruments gathers data from your running application and presents that data in a graphical display called the timeline view . You can gather data about your application’s memory usage, disk activity, network activity, and graphics performance.

iOS Developer Tools

The Developer Library

The timeline view can display all the types of information side by side, letting you correlate the overall behavior of your application, not just the behavior in one specific area. To get even more detailed information, you can also view the detailed samples that Instruments gathers.

Figure A-3

Using Instruments to tune your application

In addition to providing the timeline view, Instruments provides tools to help you analyze your application’s behavior over time. For example, the Instruments window lets you store data from multiple runs so that you can see whether your application’s behavior is actually improving or whether it still needs work. You can save the data from these runs in an Instruments document and open them at any time.

For details on how to use Instruments with iOS applications, see Tools Workflow Guide for iOS . For general information on how to use Instruments, see Instruments User Guide .

The Developer Library

The iOS Developer Library contains the documentation, sample code, tutorials, and other information you need to write iOS applications. Because the developer library contains thousands of pages of documentation, ranging from high-‐level getting started documents to low-‐level API reference documents, understanding how to find the information is an important step in the development process. The developer library uses a few techniques for organizing content that should make it easier to browse.

iOS Developer Tools

The Developer Library

You can access the iOS Developer Library from the

Apple Developer website

or from Xcode. In Xcode, choosing

When you install the iOS SDK, Xcode automatically makes the iOS Developer Library available for you to use.

(Xcode also downloads updates for you automatically, although you can change that setting in preferences.)

The iOS Developer Library contains a lot of information so it is worth becoming at least somewhat familiar with its layout. Figure A-‐4 shows the main page of the developer library in the Xcode documentation window.

The toolbar at the top of the page includes a search field and buttons for navigating around the documentation.

You can browse the library by topic, by framework, or by the type of resource you are looking for. You can also use the filter field above the list of documents to narrow the set of displayed documents.

Figure A-4

iOS Developer Tools

The Developer Library

Important: The content of the iOS Developer Library is updated regularly, but you can also access the latest documentation, release notes, Tech Notes, Technical Q&As, and sample code from the

iOS Dev Center

All documents are available in HTML and most are also available in PDF format.

Because the developer library provides a tremendous amount of information, sorting through all that information while you are trying to write code can be cumbersome. To help you find specific information quickly, Xcode also provides a Quick Help pane in the Utilities section of the main project window. This pane shows you information about the designated symbol, including its syntax, description, and availability. It also shows you any related documentation and sample code resources. Clicking the links in this pane takes you to the corresponding resource in the developer library.

For more information about using the Documentation and Quick Help windows, see

Xcode 4 User Guide .

iOS Frameworks

This appendix contains information about the frameworks of iOS. These frameworks provide the interfaces you need to write software for the platform. Where applicable, the tables in this appendix list any key prefixes used by the classes, methods, functions, types, or constants of the framework. Avoid using any of the specified prefixes in your own symbol names.

Device Frameworks

Table B-‐1 describes the frameworks available in iOS-‐based devices. You can find these frameworks in the

<Xcode.app>

Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/

<iOS_SDK>

/System/Library/Frameworks directory, where <Xcode.app> is the path to your Xcode app and <iOS_SDK> is the specific SDK version you are targeting. The "First available” column lists the iOS version in which the framework first appeared.

Table B-1

Device frameworks

Name Prefixes Description

Accelerate.framework

First available

4.0

cblas

, vDSP

Accounts.framework

AddressBook.framework

AddressBookUI.framework

AdSupport.framework

5.0

2.0

6.0

Contains accelerated math and DSP functions. See

“Accelerate

Framework”

(page 43).

Contains interfaces for managing access to a user’s system accounts. See

“Accounts Framework”

(page 35).

Contains functions for accessing the user’s contacts database directly. See

“Address Book Framework”

(page 36).

Contains classes for displaying the system-‐defined people picker and editor interfaces. See

“Address Book UI

Framework”

(page 16).

Contains a class for gathering analytics.

See

“Ad Support Framework”

(page 36).

iOS Frameworks

Device Frameworks

Name

AssetsLibrary.framework

First available

4.0

AudioToolbox.framework

AudioUnit.framework

AVFoundation.framework

CFNetwork.framework

CoreAudio.framework

CoreBluetooth.framework

CoreData.framework

CoreFoundation.framework

CoreGraphics.framework

2.0

2.2

2.0

5.0

3.0

2.0

Prefixes

Audio

AU ,

Audio

Description

Contains classes for accessing the user’s photos and videos. See

“Assets Library

Framework”

(page 24).

Contains the interfaces for handling audio stream data and for playing and recording audio. See

“Core Audio”

(page

25).

Contains the interfaces for loading and using audio units. See

“Core

Audio”

Contains Objective-‐C interfaces for playing and recording audio and video.

See

“AV Foundation Framework”

25).

Contains interfaces for accessing the network via Wi-‐Fi and cellular radios.

See

“CFNetwork Framework”

(page 36).

Provides the data types used throughout Core Audio. See

“Core

Audio”

Provides access to low-‐power Bluetooth hardware. See

“Core Bluetooth

Framework”

(page 43)

Contains interfaces for managing your application’s data model. See

“Core

Data Framework”

(page 37).

Provides fundamental software services, including abstractions for common data types, string utilities, collection utilities, resource management, and preferences.

See

“Core Foundation

Framework”

(page 37).

Contains the interfaces for Quartz 2D.

See

“Core Graphics Framework”

(page

26).

iOS Frameworks

Device Frameworks

Name

CoreImage.framework

CoreLocation.framework

CoreMedia.framework

CoreMIDI.framework

CoreMotion.framework

CoreTelephony.framework

CoreText.framework

CoreVideo.framework

EventKit.framework

EventKitUI.framework

External-

Accessory.framework

First available

5.0

Prefixes

2.0

4.0

4.2

4.0

3.2

4.0

3.0

MIDI

Description

Contains interfaces for manipulating video and still images. See

“Core Image

Framework”

(page 26).

Contains the interfaces for determining the user’s location. See

“Core Location

Framework”

(page 38).

Contains low-‐level routines for manipulating audio and video. See

“Core Media Framework”

(page 38).

Contains low-‐level routines for handling

MIDI data. See

“Core Audio”

Contains interfaces for accessing accelerometer and gyro data. See

“Core

Motion Framework”

(page 39).

Contains routines for accessing telephony-‐related information. See

“Core Telephony Framework”

(page 39).

Contains a text layout and rendering engine. See

“Core Text

Framework”

(page 27).

Contains low-‐level routines for manipulating audio and video. Do not use this framework directly.

Contains interfaces for accessing a user’s calendar event data. See

“Event Kit

Framework”

(page 39).

Contains classes for displaying the standard system calendar interfaces.

See

“Event Kit UI Framework”

(page 16).

Contains interfaces for communicating with attached hardware accessories. See

“External Accessory Framework”

44).

iOS Frameworks

Device Frameworks

Name

Foundation.framework

GameKit.framework

GLKit.framework

GSS.framework

iAd.framework

ImageIO.framework

IOKit.framework

MapKit.framework

MediaPlayer.framework

MediaToolbox.framework

MessageUI.framework

First available

2.0

Prefixes

3.0

5.0

4.0

2.0

3.0

2.0

6.0

3.0

GLK gss

N/A

Description

Contains interfaces for managing strings, collections, and other low-‐level data types. See

“Foundation

Framework”

(page 39).

Contains the interfaces for managing peer-‐to-‐peer connectivity. See

“Game

Kit Framework”

(page 17).

Contains Objective-‐C utility classes for building complex OpenGL ES applications. See

“GLKit

Framework”

(page 28).

Provides a standard set of security-‐related services.

Contains classes for displaying advertisements in your application. See

“iAd Framework”

(page 17).

Contains classes for reading and writing image data. See

“Image I/O

Framework”

(page 27).

Contains interfaces used by the device.

Do not include this framework directly.

Contains classes for embedding a map interface into your application and for reverse-‐geocoding coordinates. See

“Map Kit Framework”

(page 18).

Contains interfaces for playing full-‐screen video. See

“Media Player

Framework”

(page 28).

Contains interfaces for playing audio content.

Contains interfaces for composing and queuing email messages. See

“Message

UI Framework”

(page 18).

iOS Frameworks

Device Frameworks

Name

MobileCore-

Services.framework

NewsstandKit.framework

OpenAL.framework

OpenGLES.framework

PassKit.framework

QuartzCore.framework

QuickLook.framework

Security.framework

Social.framework

First available

3.0

Prefixes

5.0

2.0

6.0

2.0

4.0

2.0

6.0

EAGL

CSSM

Sec

Description

Defines the uniform type identifiers

(UTIs) supported by the system. See

“Mobile Core Services

Framework”

(page 40).

Provides interfaces for downloading magazine and newspaper content in the background. See

“Newsstand Kit

Framework”

(page 40).

Contains the interfaces for OpenAL, a cross-‐platform positional audio library.

See

“OpenAL Framework”

Contains the interfaces for OpenGL ES, which is an embedded version of the

OpenGL cross-‐platform 2D and 3D graphics rendering library. See

“OpenGL

ES Framework”

Contains interfaces for creating digital passes to replace things like tickets, boarding passes, member cards, and more. See

“Pass Kit Framework”

41).

Contains the Core Animation interfaces.

See

“Quartz Core Framework”