Mac iOS differences

iOS is an operating system derived from MacOS that is not launched specifically for mobile devices (iphones).
iOS and Mac OS have very different UI concepts, and iOS supports gesture manipulation, including multi-touch technology, and more.
From a developer's point of view, iOS and MacOS Add a lot of restrictions to the average developer.

There are some differences between the two frameworks:
Frame differences
Although most of iOS's frameworks also exist in MAC OS x systems, different platform frameworks have different implementations and how to use them. Here are some important differences to note about how Mac OS X developers develop iOS apps:
Comparison of UIKit and AppKit
In iOS systems, creating graphical applications, managing event loops, and performing other interface-related tasks are inseparable from the infrastructure provided by Uikit. Uikit and AppKit have a very significant difference, and you should pay particular attention to this when designing iOS applications. It is for this reason that you must provide classes and logic related to the interface when migrating the cocoa application to an iOS system. Table 6-1 lists the specific differences between frameworks that can help you understand what the application in iOS should look for:

Table 6-1 Differences in interface technology
Difference
Discuss
Document support
In iOS systems, the importance of document roles is reduced, and simple content models become increasingly important. Because an iOS system application typically has only one window (in the case of no external display), the main window is the only environment for creating and editing all application content. More importantly, all document-related operations, including the creation and management of files, are now done behind the scenes by the application and no longer require user intervention.
View class
Uikit provides you with a very specific set of views and controls. The AppKit framework has many views and controls that cannot work on iOS devices, while others are replaced with more iOS-featured views. For example, when displaying hierarchical information, iOS does not use the Nsbrowser class, but instead uses a completely different style (navigation controller). To learn about the views and controls in iOS and how to use them, check out the iphone man-machine interface guidelines.
View coordinate system
The drawing model for iOS system quartz and uikit content is essentially the same as Mac OS X, with only one exception. In the MAC OS x painting model coordinate system, the origin of the window and view is in the lower-left corner by default, and the axis extends up to the right. On iOS, however, the default Origin location is the upper-left corner and the axis extends downward to the right. MAC OS x's coordinate system is called a "flipped" coordinate system, and iOS is the default coordinate system. For more information on graphics and coordinate systems, see the iOS View Programming Guide.
Window is a view
Conceptually, the windows of the iOS system and the view Mac OS X have the same meaning. But from the point of view of implementation, the difference is very big. In Mac OS x systems, the Nswindow class is a subclass of the Nsresponder class, but in an iOS system, UIWindow is actually a subclass of UIView. Changes in the inheritance relationship indicate that the window will use the core animation layer to draw the appearance. The main reason for this change is to support window layering at the operating system level. For example, the system can display the status bar in a separate window and let the window float on top of the application window.
Another difference between the iOS system and Mac OS X system is related to how windows are used. MAC OS x applications can be used with any number of Windows, but most iOS apps can have only one window. The data that displays different screens in an iOS application is not done by changing the window, but by switching the custom view in the application window.
Event handling
Uikit's event-handling model differs greatly from Mac OS X's event-handling model. The Uikit framework does not send mouse and keyboard events to the view, but rather sends touch and move events. These events not only require you to implement a different set of methods, but also require you to modify the entire event-handling code. For example, a queued event that tracks loops locally cannot contain touch events, and your code adjusts accordingly. For more information about event handling for iOS apps, refer to the iOS Event handling guide.
Target-action model
Uikit supports three forms of action, and AppKit only supports one. Uikit controls can invoke different actions at different stages of the interaction, and an interaction can specify multiple targets. Therefore, in Uikit, a control can send multiple different actions to multiple targets in one interaction. To learn more about the target-action model for iOS apps, see the iOS Event handling guide.
Painting and printing support
In order to support uikit rendering needs, Uikit's painting ability is adjusted appropriately. It supports image loading and display, string display, color management, font management, and several functions for rendering matrices and getting the graphics context. Uikit does not contain general purpose drawing classes because iOS systems use other methods to accomplish such functions (i.e., quartz and OpenGL ES).
The iOS system supports print functionality, and iOS devices cannot connect to printers or other related print hardware.
For more information on graphics and drawing, see the iOS View Programming Guide.
Text support
Composing e-mail and Notepad is the primary text support provided by the iOS system. The Uikit class allows applications to display and edit simple strings and slightly more complex HMTL content.
In iOS 3.2 and subsequent systems, the Core text framework and the UIKIT framework provide more sophisticated text processing capabilities that enable you to achieve more sophisticated text editing and presentation views, or customize the input methods provided by the view. For more information about text support, see the iOS Text and Web Programming Guide.
Usage and attribute comparison of access methods
Uikit uses attributes extensively in its class declarations. The AppKit property was introduced by Mac OS X in version 10.5 and was created after a large number of classes in the framework were built. Attributes are not a simple imitation of the AppKit framework getter and setter methods, but are used by Uikit to simplify the class interface. For information about how properties are used, see "property declarations" in the OBJECTIVE-C programming language.
Controls and cells
The Uikit control does not use cells. Unit is a lightweight alternative to Mac OS X as a view. But the Uikit view itself is a very lightweight object, so the unit is not useful. Although the UITableView class also uses the term "cell" on the naming convention, the unit here is actually a subclass of UITableView.
Table View
The UITableView class of the iOS system can be seen as a compromise between Nstableview and Nsoutlineview in the AppKit framework. It combines the characteristics of the two classes in the AppKit framework, and is more suitable for display on small screens. UITableView displays one column of data at a time, and you combine the related rows into a single section. UITableView can also be used to display and edit hierarchical list data. To learn more about the UITableView class, see the UITableView class reference.
Menu
Almost all iOS applications have a much smaller set of commands than similar Mac OS x applications, so iOS does not support menus and often does not use menus. For situations where a small number of commands are required, it is more appropriate to use toolbars or a set of buttons. For situations where a data menu is required, it is generally more appropriate to use the picker or navigation controller interface, and for context-sensitive menus, menu items can be displayed in the Edit menu, replacing or supplementing commands such as cut, copy, or paste.
Core Animation Layer
In an iOS system, all appearances are drawn by the core animation layer. The framework also implicitly provides animation support for many view-related properties. Because of this built-in animation support, you don't need to display the core animation layer in your code, just change some of the view's properties to achieve most animations. You need to use the Core Animation directly only if you need precise control of the hierarchy or if you do not want to expose certain features to the view layer. To learn how to integrate the core animation layer into the iOS drawing model, see the iOS View Programming Guide.
For information about Uikit's classes, see the Uikit Framework reference.

Table 6-2 iOS Foundation does not have the technology
Technology
Precautions
Meta-data and predictive management
iOS does not support spotlight metadata and search predictions because iOS does not support spotlight.
Distributed object and port Name service management
There is no distributed object technology in iOS, but you can use the Nsport family class and the port (and socket) to interact interactively. You can also use the core Foundation and the Cfnetwork framework to handle network requirements.
Cocoa binding
iOS does not support cocoa bindings, but instead uses a small modified target-action model. Because this approach allows the code to have more flexibility in how the action is handled.
Objective-c Garbage Collection
iOS does not support garbage collection, you must use the memory management model. You need to declare the ownership of the object by holding the object, and release the object when the object is not needed.
AppleScript support
iOS does not support AppleScript.
The foundation framework of the IOS system provides support for XML, which you can parse through the Nsxmlparser class, and other parsing classes (including Nsxmldocument, nsxmlnode) are not supported. In addition to Nsxmlparser, you can also use the LibXML2 library, which is the XML parsing interface of the C language.

If you need to know which classes exist in Mac OS X and don't exist on iOS, see the class hierarchy of the foundation framework in the Foundation framework reference.

Changes to other frameworks
Table 6-3 lists the key differences for other iOS frameworks.

Table 6-3 Differences between iOS and Mac OS x frameworks
Framework
Difference
Addressbook.framework
The framework interface can be used to access the user's contact information. Although the name is the same, the iOS version of this framework differs greatly from the version of Mac OS X.
In addition to the C interface for accessing contact data on iOS systems, you can use the classes provided by the Address Book UI framework to present standard contact selection and editing interfaces.
For further information, please see the Address Book frame reference.
Audiotoolbox.framework
Audiounit.framework
Coreaudio.framework
In iOS systems, these frameworks support audio recording, playback, and mixing of audio content in mono and multichannel, but do not support more advanced audio processing features and custom audio Unit plugins. However, the iOS system adds a feature that triggers the vibration of the iOS device (with the appropriate hardware). If you need to know how to use audio support, see Multimedia support in the iOS application Programming Guide.
Cfnetwork.framework
The framework contains the core Foundation network interface. In an iOS system, the Cfnetwork framework is the top-level frame, and it has no child frames. Most of the interface of the framework remains the same. For further information, please see the cfnetwork Framework reference.
Coregraphics.framework
The framework contains the Quartz interface. In an iOS system, the Core graphics framework is the top-level frame, and it has no child frames. You use quartz to create paths, gradients, shadows, patterns, images, and bitmaps in exactly the same way as Mac OS x systems. However, there are some quartz features (including PostScript support, image source and whereabouts, quartz display service support, Quartz Event Service support) that do not exist on the iOS system. For further information, see the core graphics frame reference.
Opengles.framework
OpenGL ES is an OpenGL version designed for embedded systems. If you are an OpenGL developer, you should be familiar with the OpenGL ES interface. However, there are a few big differences between OpenGL ES interfaces. First, it is a more compact set of interfaces that only support functions that can be effectively performed on existing graphics hardware. Second, many of the extensions that desktop OpenGL can use do not exist in OpenGL ES. Even so, you should still be able to do most of the same things as desktop OpenGL. But if you are migrating existing OpenGL code, you may need to rewrite some of the code and use the rendering techniques of the iOS system (unlike Mac OS X). To learn about iOS support for OpenGL ES, see the iOS OpenGL ES Programming Guide.
Quartzcore.framework
The framework contains the core animation interface. iOS is the same for most Core animation interfaces and Mac OS X. However, the iOS system does not have classes for managing layout constraints, nor does it support the use of the core image filter. Also, iOS does not have a core image and Core Video interface (both are included in the Mac OS x version of the Quartzcore framework). For further information, please see the quartz Core Framework reference.
Security.framework
The framework contains a secure interface. In an iOS system, the framework protects application data with encryption, pseudo-random number generation, and keychain. The framework does not contain authentication or authentication interfaces, nor does it support the display of certificate content. The keychain interface is also a simplification of the Mac OS x version. For iOS security support, check out the iOS application Programming Guide.
Systemconfiguration.framework
The framework contains network-related interfaces. In an iOS system, you can use these interfaces to determine how devices are connected to the network, via Edge, GPRS, or via Wi-Fi.

Memory management
The iOS system does not support garbage collection, and you need to use the memory management model to persist, release, or automatically dispose of objects.

iOS devices have very limited memory compared to Macintosh computers. Therefore, you need to adjust the use of the auto-free pool to avoid creating multiple auto-free pool objects. Also, dispose of the object as directly as possible and do not release it automatically. If you assign many objects in a compact loop, either release those objects directly or create an auto-free pool in the appropriate place in the Loop code and release the auto-release object within the interval of the rule. Waiting until the end of the loop can cause an out-of-memory warning or cause the application to be killed by the system.

Mac iOS differences