Because every iPhone application is created using the UIKit framework, they essentially all have the same core architecture.  UIKit is a comprehensive framework that not only provides the key objects to run the application but also those needed to coordinate user input as well as controlling the display of information on the screen.  Therefore, applications show their individuality not through their core architecture but in the way these objects are configured.  Moreover, diversity in iPhone applications can be seen where custom objects are used to adjust the application’s user interface and subsequent behaviour.

Some customizations of your application are found in your custom code, many customizations actually occur at the highest levels of the application.  Whether you want to rely on the default application behaviour or you prefer application level customizations will ultimately affect how your application interacts with the system and other applications stored on the device.  Developers then need a basic understanding of the core application architecture.

iPhone Core Architecture

The vast majority of your application’s key infrastructure, from start up to shut down, is controlled by the UIKit framework.  iPhone applications are continuously receiving events and responding to events from the system.  The UI Application object manages the receiving aspect of this process while responding to these events is the job of your custom code.  Understanding the overall life cycle and events cycle of an iPhone application helps you to know where you need to respond to events.

The Life Cycle

The life cycle of an application is the series of events that occur between the launch and exit of your application.   Simply put, iPhone applications are launched when a user touches the corresponding icon on the Home screen.  A few transitional graphics are displayed before your application is launched by calling upon its main function.  However, after this point, the majority of the initialization process is managed by UIKit which loads the application’s user interface and prepares the event loop.  Then, UIKit coordinates the transfer of events to your custom objects and responds to commands from the application.  Finally, the user will choose to quit your application so UIKit communicates this information and begins the termination process.  During launch and termination, UIKit communicates with the application delegate to inform it about what is going on.  In the event loop, UIKit dispatches information to your customized application event handlers.

The Main Function

While other applications rely heavily on the main function, iPhone applications do not.  Rather, most of the work needed to run an application is the responsibility of the UI Application Main function.  Indeed, the main function serves three purposes: it creates an auto-release pool, communicates with the UI Application Main, and then frees the auto-release pool.  Changing the implementation of this function is not advisable.  The UI Application Main uses four parameters to start an application and you should never have to change these default values.

The Application Delegate

The delegate object allows you to monitor the high-level behaviour of your application.  This custom object is a mechanism that prevents the sub-classing of complex UIKit objects.  So, rather using sub-classing or over-riding methods, the complex object is unmodified and you put your custom code in the delegate object.  As events unfold, the complex object communicates information with your delegate object and hooks are used to execute custom code.

Because the application delegate handles critical system messages, it must be included in every iPhone application.  Moreover, as long as the object uses the UI Application Delegate protocol, it can be an instance of any class.

The Main Nib File

At initialization, your application’s main nib file is loaded.  Although the main nib file is the only file that is loaded automatically, additional nib files can be added later.  Essentially, nib files are resource files that are based on the disk and they store a snapshot of one or several objects.   Inside a main nib file for iPhone applications, you’ll usually find a window object, the application delegate object, and other key objects that manage the window.  When you load a nib file, objects are reconstituted and converted from the on-disk representation to an in-memory edition that is manipulated by your application.  Objects loaded via nib files are the same as objects that have been created programmatically.

Event-Handling

After initialization, the UI Application Main loads the building blocks required to manage the application’s event and drawing cycles.  The iPhone OS recognizes touch events and organizes them in the application’s event queue as users interact with the device.  Event-handling is organized such that the UI Application object selects events at the front of this queue and delivers it to the most appropriate object.  Likewise, events are delivered to controller objects that are responsible for other touch events.  For multi-touch events, data is contained in a single event object known as the UI Event.

As you can see, iPhone applications behave somewhat differently from traditional mobile web applications.  Because of the touch functionality of the device, developers will have a greater degree of control and variability in their applications but having a basic understanding of the core architecture of iPhone applications helps you to quickly adapt your applications to the iPhone OS.  Keep in mind that this article presents only a very cursory description of the architecture of iPhone applications but should give you a good idea about the underlying processes associated with iPhone applications.

Find More Iphone Applications Articles