Technology Comparison


This section provides a high-level comparison of the architecture of mobile applications developed for iOS with applications created with Qt for Nokia platforms. The goal of this section is to help developers who are familiar with iOS application development gain a clear understanding of the architecture of Qt applications. For exact information on how individual iOS APIs map to Qt APIs, refer to the Qt API mapping tool.

The following is covered:

  • Objective-C Properties vs. Qt properties
  • View Controllers
  • Outlets and Actions
  • Delegation
  • Memory management

After reading this section iOS developers should find it easy to map any iOS application's architecture to the corresponding Qt application architecture.

In the context of this section, the term "iOS programming" refers to Objective-C programming using the Cocoa Touch framework for iOS devices.

Overall it is important to understand signals and slots, Qt's dynamic inter-object messaging mechanism. Many iOS development fundamentals like actions and delegation can be implemented in Qt using signals and slots.


Objective-C permits instance variables to be declared as properties with the @property keyword, after which accessor methods can be automatically synthesized. Qt has a property system that resembles the Objective-C properties, but there are some fundamental differences:

  • Properties are not concrete class members but actually metadata, such as the names of getters and setters and change notification signals.
  • The property value is totally encapsulated within the getter and the optional setter.
  • Accessor methods or notification signals are not automatically generated.

Properties in Qt are discoverable through the Qt Meta-Object system at runtime. It also enables the QML runtime to export the properties automatically, so that they can be used from QML.

View Controllers

The view controller is one of the core concepts in iOS programming. A view controller is a specific controller object that is responsible for managing views. Usually, the view controller is a subclass of UIViewController. The actual view object is typically defined in a .nib file and created with the Interface Builder.

Developers are encouraged to use QML to create UIs in Qt. Qt doesn't have a view controller concept as such, but the developer is free to create Qt C++ controller classes for the management of QML views.

Although there are no view controllers in Qt, there is support for a Model-View-Controller design pattern in QML, see QML Data Models and Presenting Data with QML.

Outlets and Actions


Outlets are instance variables that enables code to refer to objects in the .nib file. The definition of an outlet requires an instance variable declaration in the controller class. The keyword IBOutlet has to be used, for example @property (nonatomic, retain) IBOutlet UIButton *button;. Typically, the Interface Builder is used to connect that variable to the object in the .nib file.

Qt uses a more straightforward approach and there is no need to make a connection to QML code specifically. Instead, any properties declared in QML are automatically accessible from C++. See Modifying Properties.


Actions are special methods in the controller class that can be triggered by an object in .nib file. The definition of an action requires a method in controller class. The keyword IBAction has to be used, for example (IBAction)buttonPressed: (id)sender;. Typically, the Interface Builder is used to connect that method to an event that belongs to an object in the .nib file.

In Qt there is no need for a special construct. Instead, Signals & Slots can be used. Qt C++ code can connect to any QML signals. For a simple example, refer to Receiving Signals.


Delegation is a fundamental design pattern for handling communication between objects. It is used extensively in iOS programming. Essentially, a delegate object registers to a delegating object and the delegating object sends messages to the delegate object to inform it of events.

Qt's signals and slots perform a similar function, but they are fundamentally unidirectional in that they don't have return values. Many other methods such as callbacks can be used to achieve a similar effect, but often it is best to rethink the architecture to better match the Qt fundamentals.

Memory management

iOS Memory management is based on reference counting. When a new object is created, its retain count is set to 1. Other objects may express an ownership interest with the "retain" method call and each call will increase the retain count by 1. The owner's responsibility is always to call the "release" method when the owned object is no longer needed. This will decrease the retain count by 1. Alternatively, the "autorelease" method could be used to insert the owned object to the autorelease pool. The object is deallocated when its retain count drops to 0.

Qt uses a similar approach to object ownership. QObject is the base class for nearly all Qt objects. It provides support for object ownership management. QObject has a constructor that takes another QObject, known as the "parent". The parent takes ownership of another object (known as the "child" object). The parent's destructor will automatically delete all its children. However, reference counting is not used in Qt. An object can only have one parent at a time, but it is possible to transfer the ownership (that is, parent status) to another object.

Alternatively, if the lifetime of an object is restricted to function scope, the use of a smart pointer is recommended such as QSharedPointer. Qt also provides a number of other smart pointer classes. For more information, see the comprehensive comparison of Qt's smart pointer classes on the Qt Labs blog.

Last updated 17 November 2011

Back to top

Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.