Differences between iOS and Mac Development

IOS is an operating system derived from MACOs that is not released for mobile devices (iPhones.

The UI concepts of iOS and Mac OS are quite different. iOS mainly supports gesture operations, including multi-contact technology.

From the developer's point of view, compared with MacOS, IOS imposes a lot of restrictions on common developers.


There are some differences between the two frameworks:

Framework differences

Although most IOS frameworks also exist in Mac OS X systems, different platform frameworks have different implementation methods and usage methods. The following are some important differences that need to be paid attention to when developing IOS applications for Mac OS X developers:

Comparison between uikit and appkit

In IOS systems, creating graphical applications, managing event loops, and executing tasks related to other interfaces are inseparable from the infrastructure provided by uikit. Uikit and appkit have significant differences. Pay special attention to this when designing IOS applications. For this reason, when migrating a cocoa application to the IOS system, you must provide the interface-related classes and logic. Table 6-1 lists the specific differences between frameworks. It helps you understand the characteristics of IOS applications:


Table 6-1 Differences in interface technologies

Difference

Discussion

Documentation Support

In IOS systems, document roles are less important, while simple content models become more and more important. Because IOS applications usually have only one window (without external display), the main window is the only environment for creating and editing all application content. More importantly, all document-related operations, including file creation and management, are now completed by the application behind the scenes, and no user preparation is required.

View class

Uikit provides you with a set of highly targeted views and controls. Many views and controls in the appkit framework cannot work on iOS devices. Other views are replaced by views with more IOs features. For example, when displaying layered information, IOS does not use the nsbrowser class, but uses a completely different style (navigation Controller ). For more information about views and controls in iOS and how they are used, see iPhone Man-Machine Interface Guidelines.

View Coordinate System

The painting models of IOS system quartz and uikit are basically the same as those of Mac OS X, with only one exception. In the Mac OS X painting model coordinate system, the origin of the window and view is located in the lower left corner by default, and the coordinate axis is stretched up to the right. However, in iOS, the default position of the origin is the upper left corner, and the coordinate axis is stretched down to the right. The Mac OS X coordinate system is called the "flipped" coordinate system, and IOS is the default coordinate system. For more information about graphics and coordinate systems, see the IOS view programming guide.

Window as view

In terms of concept, windows in iOS and Mac OS X in views share the same meaning. But from the implementation point of view, there is a big difference. In Mac OS X systems, the nswindow class is a subclass of the nsresponder class, but in IOS systems, the uiwindow class is actually a subclass of the uiview class. The change in the inheritance relationship indicates that the window interface 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 an independent window and let the window move above the application window.

Another difference between iOS and Mac OS X systems is related to the use of windows. Mac OS X applications can be used in any number of windows, but most IOS applications can have only one window. Data displayed on different screens in IOS apps is not implemented by changing the window, but by switching the custom view in the application window.

Event Processing

The event processing model of uikit differs greatly from that of Mac OS X. The uikit framework sends touch and movement events instead of mouse and keyboard events to the view. These events not only require you to implement a set of different methods, but also require you to modify the entire event processing code. For example, a queuing event with a local trace loop cannot contain a touch event, and your code is adjusted accordingly. For more information about event handling of IOS applications, see the IOS event handling guide.

Target-action model

Uikit supports three types of actions. appkit only supports one action. The control of uikit can call different actions in different interaction stages, and multiple targets can be specified in an interaction process. Therefore, in uikit, a control can send multiple different actions to multiple targets during an interaction. For more information about the target-action model of IOS apps, see the IOS event handling guide.

Painting and printing support

To support uikit rendering, the painting capability of uikit has been properly adjusted. It supports image loading and display, string display, color management, font management, and multiple functions for rendering matrices and obtaining graph context. Uikit does not contain plotting classes for general purposes, because the IOS system uses other methods to perform such functions (namely, quartz and OpenGL ES ).

The IOS system supports printing. iOS devices cannot connect to printers or other related printing hardware.

For more information about graphics and plotting, see the IOS view programming guide.

Text support

Email writing and notepad are the main text support provided by IOS. The uikit class allows the application to display and edit simple strings and hmtl content with a little complexity.

In IOS 3.2 and later systems, the core text framework and uikit framework provide more sophisticated text processing capabilities, allowing you to implement more precise text editing and display views, you can also use them to customize the input methods provided by the view. For more information about text support, see Ios text and web programming guide.

Usage and attribute comparison of access methods

Uikit uses attributes extensively in its class declaration. The attributes are introduced by Mac OS X in version 10.5 and are generated after a large number of classes in the appkit framework are created. The property is not a simple imitation of the getter and setter methods in the appkit framework, but is used by uikit to simplify class interfaces. To learn how to use attributes, see "attribute Declaration" in objective-C programming language ".

Controls and units

The uikit control does not use units. Mac OS X serves as a lightweight alternative to a view. However, the uikit view itself is a very lightweight object, so the unit is useless. Although in terms of naming conventions, the uitableview class also uses the word unit, the unit here is actually a subclass of uitableview.

Table View

The uitableview class of the IOS system can be considered as a compromise between nstableview and nsoutlineview in the appkit framework. It combines the features of two classes in the appkit framework, and is more suitable for small screen display. Uitableview displays a column of data at a time, and you combine the relevant rows into a partition. Uitableview can also be used to display and edit hierarchical list data. For more information about the uitableview class, see the uitableview class reference.

Menu

Almost all IOS applications have a much smaller command set than similar Mac OS X applications. Therefore, IOS does not support menus and generally does not use menus. When a few commands are required, it is more appropriate to use the toolbar or a set of buttons. For scenarios where data menus are needed, it is generally more appropriate to use the picker or navigation Controller Interface. for context-sensitive menus, the menu items can be displayed in the edit menu, use them to replace or supplement commands such as cut, copy, or paste.

Core animation Layer

In IOS systems, the rendering of all appearances is implemented by the core animation layer. This framework also implicitly provides animation support for many view-related attributes. Because of this built-in animation support, you do not need to use the core animation layer for display in the code. You only need to change some attributes of the view to implement most animations. Core animation is required only when you need to precisely control the hierarchy or do not want to expose some 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 more information about the class of uikit, see the reference of the uikit framework.


Table 6-2 unsupported IOS Foundation Technologies

Technology

Notes

Metadata and prediction Management

IOS does not support spotlight metadata and search prediction, 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 to interact with the port (and socket. You can also use the core foundation and cfnetwork frameworks to handle network requirements.

Cocoa binding

IOS does not support cocoa binding, but uses a small number of modified target-action models. This method gives the code more flexibility in handling actions.

Objective-C garbage collection

IOS does not support garbage collection. You must use the memory management model. You need to maintain the object to declare the ownership of the object, and release the object when the object is not needed.

Applescript support

IOS does not support applescript.

The foundation framework of IOS provides XML support. You can use the nsxmlparser class to parse XML files. Other parsing classes (including nsxmldocument and nsxmlnode) are not supported. In addition to nsxmlparser, you can also use the libxml2 library, which is an XML parsing interface in C language.


If you need to know which classes exist in Mac OS X and do not exist in iOS, view the class hierarchy chart in the foundation framework reference.


Changes to other frameworks

Table 6-3 lists key differences between other IOs frameworks.


Table 6-3 Differences Between iOS and Mac OS X frameworks

Framework

Difference

Addressbook. Framework

This framework interface can be used to access the user's contact information. Although the name is the same, the iOS and Mac OS X versions of this framework are quite different.

In iOS, in addition to the C interface for accessing contact data, you can also use the class provided by the address book UI framework to display the interface for selecting and editing standard contacts.

For more information, see the address book framework reference.

Audiotoolbox. Framework

Audiounit. Framework

Coreaudio. Framework

In IOS systems, these frameworks support audio recording, playback, and mixing of single-channel and multi-channel audio content, but do not support more advanced audio processing features and custom audio unit plug-ins. However, the IOS system adds a function to trigger the vibration of iOS devices (with corresponding hardware. To learn how to use audio support, see multimedia support in the IOS application programming guide.

Cfnetwork. Framework

This framework contains the core foundation network interface. In IOS systems, the cfnetwork framework is a top-level framework without sub-frameworks. Most interfaces of the framework remain unchanged. For more information, see cfnetwork framework reference.

CoreGraphics. Framework

The Framework contains the quartz interface. In iOS, the core graphics framework is a top-level framework without sub-frameworks. The path, gradient, shadow, pattern, image, and bitmap created using quartz are identical to those created in Mac OS X. However, some quartz functions (including postscript support, image source and direction, quartz display service support, and quartz Event Service Support) do not exist in IOS systems. For more information, see the core graphics framework 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 several major differences between OpenGL ES interfaces. First, it is a set of smaller interfaces that only support functions that can be effectively executed on existing graphics hardware. Second, many extensions that can be used by desktop OpenGL are not stored in OpenGL ES. Even so, you should still be able to perform most of the same operations as the desktop OpenGL. However, if you are migrating existing OpenGL code, you may need to rewrite some of the code. You need to use the rendering technology of the IOS system (unlike Mac OS X ). For details about OpenGL
For elasticsearch support, see the IOS OpenGL elasticsearch programming guide.

Quartzcore. Framework

This framework contains the core animation interface. Most IOS core animation interfaces are the same as Mac OS X. However, the IOS system does not have a class for managing layout constraints, and does not support using the core image filter. In addition, IOS does not have core image and core video interfaces (both of which are included in the Mac zcore framework of Mac OS X ). For more information, see the quartz core framework reference.

Security. Framework

This framework includes security interfaces. In iOS, the framework protects Application Data Security through encryption and decryption, pseudo-random number generation, and keychain. This framework does not contain authentication or authentication interfaces, and does not support displaying certificate content. The keychain interface is also simplified for Mac OS X. For more information about IOS security, see the IOS application programming guide.

Systemconfiguration. Framework

The Framework contains Network-related interfaces. In iOS, you can use these interfaces to determine how a device connects to the network through edge, GPRS, or Wi-Fi.


Memory Management

IOS does not support garbage collection. You need to use the memory management model to maintain, release, or automatically release objects.


Compared with Macintosh computers, iOS devices have very limited memory. Therefore, you need to adjust the use of the automatic release pool to avoid creating multiple automatic release pool objects. In addition, release objects as directly as possible instead of automatically releasing objects. If you allocate many objects in a compact loop, you can either release those objects directly or create an automatic release pool at the right position in the loop code, release the automatically released object within the interval of the rule. When the loop ends, releasing it may cause a warning of insufficient memory or cause the application to be killed by the system.