If you are an existing Cocoa developer, many of the frameworks available in iOS should seem familiar to you. The basic technology stack in iOS is identical in many respects to the one found in Mac OS X. Despite the similarities, however, the frameworks in iOS are not exactly the same as their Mac 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.
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. For information about designing applications for iOS, see iOS Application Programming Guide.
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 Mac OS X counterparts, although there are some differences. However, most of the differences 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.”
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.
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 limited screen space, and may 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.
The user interface in iOS is structured and implemented very differently from the one in Mac OS X. 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 is slightly different on each platform. In addition, you must be more selective about what you display in your views because screen size is limited and your views 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. The goal of chunking information is to create one or more “screens’ worth of content,” which you can use as the basis for defining your views. For example, to display a hierarchical list of data in Cocoa, you could use a single NSBrowser object, but in iOS you would need to create distinct sets of views to display the information at each level of the hierarchy. This makes your interface design somewhat more complex, but because it is such a crucial way of displaying information, iOS provides a considerable amount of support for this type of organization.
View controllers were introduced to Cocoa in Mac OS X v10.5 and may not be in common use yet. In iOS applications, view controllers provide a critical part of the infrastructure for managing your user interface. View controllers manage the presentation of your user interface. They also work with the system to make sure your application’s resources do not tie up too much memory and degrade performance. 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 general information about the user interface design principles of iOS, see iPhone 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 iOS Application Programming Guide. For information about view controllers and how you use them to construct the flow of your user interface, see View Controller Programming Guide for iOS.
In iOS, you always use the memory-managed model to retain, release, and autorelease objects. Garbage collection is not supported in iOS.
Because memory is more tightly constrained for iOS–based devices than for Macintosh computers, you also need to adjust your use of autorelease pools to prevent the buildup of autoreleased objects. Whenever possible, you should release objects directly rather than autorelease them. When you allocate many objects in a tight loop, you either need to release those objects directly or create autorelease pools at appropriate places in your loop code to free up autoreleased objects at regular intervals. Waiting until the end of your loop could result in a low-memory warning or the termination of your application.
Although most of the iOS frameworks are also present in Mac 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 Mac OS X developers might notice as they develop iOS applications.
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. For this reason, when migrating a Cocoa application to iOS, you must replace a significant number of interface-related classes and logic. Table 6-1 lists some of the specific differences between the frameworks to help you understand what is required of your application in iOS.
Difference | Discussion |
|---|---|
Document support | In iOS, the role of documents is deemphasized in favor of a simpler content model. Because applications typically have only one window (unless an external display is connected), the main window acts as the sole environment for creating and editing all application content. More importantly, the creation and management of any actual document-related files is handled behind the scenes by the application and not exposed to the user. |
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 |
View coordinate systems | In iOS, the drawing model for Quartz and UIKit content is nearly identical to the model in Mac OS X, with one exception. The Mac OS X drawing model uses 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 iOS, the default origin point is in the top-left corner and the axes extend down and to the right. In Mac OS X, this coordinate system is known as a “flipped” coordinate system, but in iOS it is the default coordinate system. For more information about graphics and coordinate systems, see View Programming Guide for iOS |
Windows as views | Conceptually, windows and views represent the same constructs in iOS as they do in Mac OS X. In implementation terms, however, the two platforms implement windows and views quite differently. In Mac OS X, the Another difference between iOS and Mac OS X relates to the use of windows. Whereas a Mac OS X application can have any number of windows, most iOS applications have only one. Displaying different screens of information in an iOS application is done by swapping out custom views from the application window rather than by changing the window. |
Event handling | The UIKit event-handling model is significantly different from the one found in Mac OS X. Instead of 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. For more information about handling events in iOS applications, see Event Handling Guide for iOS. |
Target-action model | 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. |
Drawing and printing support | 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. Printing is not supported because there is no support for connecting to printers or other print-related hardware from an iOS-based device. For more information about graphics and drawing, see View Programming Guide for iOS |
Text support | 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. For more information about text support, see Text and Web Programming Guide for iOS. |
The use of accessor methods versus properties | UIKit makes extensive use of properties throughout its class declarations. Properties were introduced to Mac 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. |
Controls and cells | Controls in UIKit do not use cells. Cells are used in Mac OS X 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 |
Table views | The |
Menus | Nearly all applications written for iOS have a much smaller command set than does a comparable Mac OS X application, and so menubars 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, you can display those on the Edit menu in addition to (or in lieu of) commands such as Cut, Copy, and Paste. |
Core Animation layers | 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 by changing the desired 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.
A version of the Foundation framework is available in both Mac 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. Table 6-2 lists some of the major areas of functionality that are not included in iOS, however, along with the reasons why the related classes are not available. Wherever possible, this table lists alternative technologies that you can use instead.
Technology | Notes |
|---|---|
Metadata and predicate management | Spotlight metadata and search predicates are not supported in iOS because Spotlight itself is not supported. |
Distributed objects and port name server management | The Distributed Objects technology is not available, but you can still use the |
Cocoa bindings | 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. |
Objective-C garbage collection | Garbage collection is not supported in iOS. Instead, you must use the memory-managed model, whereby you retain objects to claim ownership and release objects when you no longer need them. |
AppleScript support | 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 Mac OS X but not in iOS, see the class hierarchy diagram located in ““The Foundation Framework”” in Foundation Framework Reference.
Table 6-3 lists the key differences in other frameworks found in iOS.
Framework | Differences |
|---|---|
| This framework contains the interfaces for accessing user contacts. Although it shares a same name, the iOS version of this framework is very different from its Mac 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. |
| 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 Support in iOS Application Programming Guide |
| 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 Mac 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. |
| 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 should still be able to perform most of the same operations you would normally 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 both iOS and Mac 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 Mac 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, this framework focuses on securing your application data by providing support for encryption and decryption, pseudo-random 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 Mac OS X. For information about the security support, see iOS Application Programming Guide. |
| This framework contains networking-related interfaces. In iOS, this framework 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. |
Last updated: 2010-07-08