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.
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.”
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 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.
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.
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 For a description of the views and controls available in iOS, along with information on how to use them, see iOS Human Interface Guidelines. |
View coordinate systems | 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. |
Windows as views | 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 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. |
Event handling | 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. |
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. 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. |
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. In iOS 6, and later, UIKit includes support for styled text rendering using the For more information about text support, see Text, Web, and Editing 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 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 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 |
Table views | The In iOS 6, you can use the For more information about creating and using table views, see Table View Programming Guide for iOS. |
Menus | 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. |
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 (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.
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.
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 |
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. |
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 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.
Framework | Differences |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
© 2012 Apple Inc. All Rights Reserved. (Last updated: 2012-09-19)