iPhone Applications Tune-Up: Design for Performance

Exclusive offer: get 50% off this eBook here
iPhone Applications Tune-Up

iPhone Applications Tune-Up — Save 50%

High performance tuning guide for real-world iOS projects

$26.99    $13.50
by Loyal Moses | October 2011 | Networking & Telephony

Designing an application is much more than selecting user interface components and choosing color schemes. Although these decisions may be rather important for the overall success of an application, we will be specifically focusing on the performance aspect of design and how the creation of a stable foundation and making solid decisions early, will pay off in the end.

With performance in mind, this article by Loyal Moses, author of iPhone Applications Tune-Up, will focus on the primitive concepts of designing your project from the ground up for maximum performance. Specific areas in which our concepts will focus are as follows:

  • Preparing the project
  • Project organization
  • Project structure
  • Groups and files
  • Groups and files

(For more resources on iPhone, see here.)

The design phase of development is typically where we take into account any element of an application that may have a significant impact on the overall architecture of the final product. Project structuring, required functions, preferred features, hardware specifications, interoperability, and logical limitations are all factors that should be considered within this phase.

Elements not regularly included during the design phase may include visuals, color schemes, intricate feature details, and other interchangeable aspects of the final product. When designing with performance in mind, you must take into account the desired characteristics and levels of performance you are looking to achieve in your application. Knowing precisely where your application's performance needs are and focusing greater attention in those areas is the basic premise of the performance-tuning concept.

Identifying areas where performance tuning is necessary in many circumstances may be the most difficult part. Obvious areas like memory, database, and network communications may stand out and be somewhat simple to diagnose, however, less common user interface or architectural issues may require profiling and even user feedback for identification. For instance, a database-laden application would be expected to be as optimized as possible for efficient querying, while an application tailored towards video recording and playback may not necessarily require a focus on database efficiency. Similarly a project, which may end up with as little as a few thousand lines of source code may not require a great deal of project structuring and framework planning, while a much larger project will need more time dedicated to these areas.

Overloading your application and testing for weaknesses by pushing it beyond its capabilities can prove to be extremely valuable. As an example, databases and table views can be loaded with overly large datasets to identify missing keys or object misuse. The design phase may help you identify potential bottlenecks giving you an opportunity to alter the layout and design of your project before any development has taken place and it becomes too cumbersome to resolve in the midst of coding. Bottlenecks that are unavoidable can be highlighted as areas in your application, which you may want to spend more time squeezing efficiency from. Bottlenecks, which are identified early, stand a good chance of being resolved much easier than waiting until after an applications project is secured and in motion.

Preparing the project

To take full advantage of Xcode means to understand in depth the philosophy behind the Xcode user interface. Becoming proficient with Xcode will have a great impact on your effectiveness as a developer. Like any tool, knowing its capabilities as well as its limitations allows you to make smarter decisions, quicker.

A car is not designed from the interior to the exterior or from the roof to the tires; it is designed from the core outward. Any good vehicle gets its start from a well engineered, tested, and proven frame. The frame is the single key component to which all other components will be bolted and attached. A poor frame design will lead to various structural issues, which in turn lead to more granular problems as these components get further away from the frame.

An application project is quite similar, without a solid frame to build an application upon; the quality of the final product will surely be affected. Source code, files, and other resources become cluttered, which has the potential to create similarly damaging granular issues later on in the development lifecycle.

Just like one single automotive frame is not the answer for every vehicle on the road, developers are free to organize a project in the way that is most beneficial for the application as well as the workflow and preference of the developer.

Although refactoring has come a long way and making organizational project changes during the development phase can be done, it is highly recommended that project decisions be made early on to limit problems and keep productivity as high as possible. A large portion of project management as far as iOS applications are concerned are handled by and through Xcode, Apple's standard integrated development environment.

Xcode is an extremely powerful and feature rich integrated development environment with dozens of configuration options that directly affect an individual project. Xcode is not limited to iOS development and is quite capable of creating virtually any type of application including applications for OS X, command-line utilities, libraries, frameworks, plugins, kernel extensions, and more. Xcode is regularly used as a development environment for varying compiled languages as well as nearly all mainstream scripting languages.

For those of you who keep regular tabs on Apple and Xcode, you are more than likely well aware of the release of Xcode 4 and may have actually followed it throughout the beta process as well. Xcode 4 is an entire rewrite of the popular development environment, making needed changes to a tool that was begging for upgrades. Xcode 4 follows the paradigm of single window applications, in which all development and testing is performed within the single Xcode 4 interface. Most notable is the integration of interface builder into the core Xcode 4 interface, which brings all of the functionality of these previously separate tools together, integrating them completely.

Xcode's abilities far surpass the needs that developing an iOS application requires and it is again very important to understand the development environment in great detail in order to maximize its benefits. One particularly useful project configuration option is the ability to treat compiler warnings as errors. Warnings are the compilers way of telling the developer that something is happening that it may not understand or that it's just not bad enough to prevent an application from running, but still noteworthy to inform the developer.

Good programming practice suggests, every developer strive to produce warning free code. Warning free code is simply healthy code and the practice of resolving warnings as early as possible is a habit that will ultimately help in producing code that performs well.

Within the Build Settings for a specific target, we can enable the Treat Warnings as Errors option to nudge us in the proper direction for maintaining healthy code. Although this feature can have a slight impact on development and testing time, it comes highly recommended and should be considered for developers interested in high quality and well performing code.

In addition to helping create higher quality code, it's a forced education that may be priceless for career programmers and weekend code warriors alike. It is shown in the following screenshot:

Project organization

Every feature, function, and activity that is performed within Xcode revolves around the project. Much like any other project concept we have been exposed to, Xcode uses projects to organize files, resources, and properties for the ultimate purpose of creating applications and products.

For most intents and purposes, the default project settings of Xcode will be sufficient enough for the average developer to create a multitude of applications with relatively little issue. However, we are interested not in achieving averages but in tuning, optimizing, and grabbing every bit of performance possible. We're also interested in streamlining the development process as much as we can. This is precisely why a better than average understanding of the development environment we will be working in is critical.

Obviously, the majority of an application project is going to be made up of its classes, libraries, and other source code specific components. Organization of source code is a core principle for any project that is more than a handful of classes and libraries. Once a project begins to mature into dozens or hundreds of files, the importance of well-organized code becomes more apparent. Inevitably, without some type of organizational form, source code, and general project resources become unruly and difficult to find. We've all experienced giant monolithic source code and project structures with resources wildly strewn about without order. Personally, I find this level of chaos revolting and believe order and organization to be a few of the many characteristics of quality.

Project structure

Xcode's project source code structure is an open canvas, one that doesn't force a developer to use any particular method for organizing code. Unlike various programming environments, Xcode provides the freedom for a developer to build in virtually any way they like.

While this level of freedom allows a developer to use the project structure that best fits their style and experience, it leaves plenty of room for mess and confusion if not entirely setting them up for failure. The solution to this problem is to have a well organized and thought out plan of action for how a project and its resources will be laid out.

Remember that not a single project structure will work, nor should it work for every proposed project, however, knowing what options are available and the positive and negative effects they might have is quite important. To understand the basic principles of how to organize an Xcode project, we must first understand how a default Xcode project is structured.

Remember that not a single project structure will work, nor should it work for every proposed project, however, knowing what options are available and the positive and negative effects they might have is quite important. To understand the basic principles of how to organize an Xcode project, we must first understand how a default Xcode project is structured.

Following is a screenshot of a new default Xcode project in which the structure in the left-panel appears to be well organized:

Contrast the logical organization of the Xcode interface with the project's underlying file structure and the grouping principle becomes clearer. Xcode stores the logical reference of the project's underlying file structure and uses groups to help developers visualize order within the development environment. In other words, what you see within Xcode is not what is actually happening on disk. The structure within Xcode is comprised of references to the disks, files, and directories. This additional layer of abstraction allows developers to group or relocate project's resources within Xcode for easier management, but not effect the actual disk structure of the project as shown in the following screenshot:

At first glance, the underlying structure looks rather clean and simplistic, but imagine this directory in a few days, weeks, or even months time with dozens of more classes and resources.

Now, one might argue that as long as the logical representation of the project is clear and concise that the underlying file architecture is unimportant. While this might be true for smaller and less complicated application projects, as a project grows in size there are many factors to consider other than how data is represented within a development environment.

Consider the impact that a flat storage architecture might have throughout the life of an Xcode project. The free naming of classes and other resources may be significantly limited as all files are stored within the same base folder.

Additionally, browsing source code within a source code repository like GitHub and Google Code may become difficult and tedious.

Choosing exactly how a project is laid out and how its components will be organized is akin to selecting the right vehicle frame for which our project will be based from.

iPhone Applications Tune-Up High performance tuning guide for real-world iOS projects
Published: October 2011
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

(For more resources on iPhone, see here.)

Groups and files

One particular strategy of creating a well-organized source code structure is to create the underlying file structure according to your project needs and then import these changes into your Xcode project.

We do this by opening the underlying file structure of our project, which can be done by right-clicking the main project file in the left-side Groups & Files panel of Xcode and selecting Show in Finder , shown as follows:

As you might have guessed or experienced, this opens the underlying disk structure of our Xcode project. With the underlying project file structure in view, we are free to create the structure that best fits our needs and then simply import this structure into Xcode.

The following is a sample project file structure that I use very regularly for nearly every iOS project I develop. This structure includes modifications to the default project directory as well as the addition of a Resources directory.

Under the default project directory, the following directories are created:

  • App
  • Controllers
  • Helpers
  • Models
  • Resources

Under the newly created Resources directory, create directories for all the types of resources that you might expect to use throughout the life of the project.

These directories might include the following as well as anything else specific to the project:

  • Audio
  • Animations
  • Images
  • NIBs
  • Databases

This is shown in the following screenshot:

We can then create the necessary directories and move source code and resources as we like. There are many benefits to organizing source code and resources in this particular manner.

An example would be that if you had a series of images that were named similar yet dependent upon a particular application variable, you could easily separate these resources into individual directory structures and utilize the same file naming convention for simplicity and maintainability.

Another benefit using the same principle is localization, in which you could store all necessary translation resources in their individual respective directories and achieve a much greater level of structure. Something similar to the following directory structure: /root of project/Resources/language/

The languages stored in the previous directory are English, Dutch, German, French, and Spanish. Because Xcode stores the logical structure of the project separate from the underlying directory structure, it is important for us to inform Xcode of the changes we have made.

At this point, unless of course this is a newly created project, I highly recommend having a current backup of your project and any related resources prior to making any of the following changes.

To do this, select all of the child items and groups of your project within Xcode, press the Delete key and select Remove References Only to ensure that only the group references are deleted from the project and the actual files themselves remain in their original locations, shown as follows:

Remember to only remove references or risk losing your project data.

Now that we have removed the default group references from Xcode, we can now add the changes to the underlying directory structure by dragging and dropping the underlying disk structure that has been altered into the root of our Xcode project.

When prompted, we will ensure that Copy items into the destinations group's folder (if needed) checkbox is NOT selected and the radio button for Create groups for any added folders is selected and click Finish , shown as follows:

Xcode will now recursively create the appropriate groups for each of our underlying folders. This will give us group references to the underlying and newly created directory structures to achieve our desired organizational effect.

The changes we've made are now reflected within Xcode. The App, Controllers, Helpers, Models, and Resources directories effectively give us a cleaner and more organized project both within Xcode and on disk.

Once completed, your Xcode project's new group structure should look similar to the following screenshot:

With a place for everything and everything in its place we can already see the overall effect a solid file and group structure will have on the overall performance and future of the project.

Keep in mind, any future modifications to the underlying directory structure will not be immediately recognized within Xcode. Should changes be required, simply follow the same previous steps of removing the groups by reference only within Xcode and then dragging and dropping the newly changed folders into the base Xcode project.

This may seem a bit of a hassle, but is well worth the few extra moments it takes once a project becomes large enough for a lack of organization to begin impacting development.

Code structure

The importance of a consistent code structure is rather important for the overall health of any application. The order in which declarations and methods are placed has a direct impact on maintainability as a project grows in size and scales beyond a few thousand lines of code.

Each of us has experienced the time-wasting frustration of not being able to quickly locate methods and properties. Scrolling and searching our way through classes with thousands of lines of code is not a particularly great use of our time. Having a consistent class structure will keep source code neat and tidy and aid in shortening the transit time we spend jumping between class methods.

One particular strategy that I find helpful for organizing @implementation source code is to use a simple and consistent class structure recipe. Regardless of project, using this same class recipe allows me to more easily locate and manage class contents and ultimately increases my own development performance. The class structure recipe is shown as follows:

@implementation class structure
imports
init
public methods
delegate methods
dealloc

The key to a successful class structure recipe is development obedience to the rules and guidelines you apply to yourself. A good recipe will have no effect if it is not adhered to 100 percent of the time. Take the time to implement a class according to your preferred recipe. Adopt the recipe into your development habit and stick with it.

A look at the following basic class example demonstrates how simple a consistent recipe for class structure can be:

#import "MyClass.h"
@implementation MyClass

#pragma mark -
#pragma mark init

- (id) init
{
self = [super init];
if(self != nil)
{
}
return self;
}


#pragma mark -
#pragma mark Public Methods

- (void)myPublicMethod
{
}

- (void)myOtherPublicMethod
{
}

#pragma mark -
#pragma mark Delegate Methods

- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];

}

#pragma mark -
#pragma mark dealloc

- (void)dealloc
{
[super dealloc];
}

@end

Of course, this strategy may work best for my particular development style, however, any mutation of the previous code will surely help increase overall source maintainability if you are not currently using any type of class recipe or guide.

Regardless of how organized your class recipe may be, a several thousand line class can be an absolute nightmare to navigate without a little assistance.

To remedy this problem, we can take advantage of one of the more underused elements of the Xcode interface, which is the source code selection menu, also known as the symbol pop-up menu.

This menu is available within all source editing windows of Xcode and provides a handy interface to quickly jump between methods and sections of code, shown as follows:

(Move the mouse over the image to enlarge.)

We can extend the basic functionality of this selection menu by taking advantage of an additional source code organization technique, known as the pragma mark statement.

Within Xcode, the pragma mark statement can be used to provide details to Xcode on how source code is organized. Originally, the pragma directive was solely a compiler specific feature that various compilers used for additional instructions. However, integrated development environments now commonly take advantage of these directives for things like source code access, formatting, and delineation.

Most compilers ignore unrecognized pragma statements like #pragma mark leaving Xcode free to interpret it at will.

Within Xcode the syntax for a #pragma mark is as follows:

#pragma mark label_name

 

The following example code helps Xcode format the direct access source code selection menu such as the following screenshot:

#import "MyClass.h"
@implementation MyClass

- (id) init
{
self = [super init];
if (self != nil)
{
}
return self;
}

#pragma mark -
#pragma mark Examples

- (void)exampleMethod1
{
}

- (void)exampleMethod2
{
}

#pragma mark More Examples

- (void)exampleMethod3
{
}

- (void)exampleMethod4
{
}

#pragma mark -
#pragma mark dealloc

- (void)dealloc
{
[super dealloc];
}

@end

Looking at the previous code , we can see the #pragma mark is in action. The following are the details on exactly how they are interpreted by Xcode:

  • #pragma mark -: Draws a horizontal separator line within the direct access source code selection menu.
  • #pragma mark Examples: Creates a new bolded section heading called Examples within the direct access source code selection menu.

In smaller and more manageable projects, pragma statements may make little to no sense, however, in larger projects with dozens or hundreds of class methods they become essential in maintaining a healthy code base.

Summary

In this article, we introduced the importance of creating, organizing, and designing an Xcode project for optimal performance.

We covered a few selected steps for organizing a project from core project settings to source code structure and leading practice techniques for increasing project maintainability.

More specifically, we covered project preparation and organizational guidelines that affect the life of an Xcode project. Additionally, we laid out an improved project and file structure that can help organize resources for projects of any size.

A project that is built upon a strong and well-designed frame is more likely to be easier to maintain and produce higher levels of performance than an application without dedicated planning. Organization is the key to quality and ultimately success, while chaos leads to unpredictable results. Additionally, organization will no doubt garner points for you on a development team or in situations where others may have to come in and work with code that you have developed.


Further resources on this subject:


iPhone Applications Tune-Up High performance tuning guide for real-world iOS projects
Published: October 2011
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

About the Author :


Loyal Moses

Loyal Moses is an accomplished business owner and entrepreneur as well as technical speaker, writer and multi-lingual developer with more than 20 years of programming experience on every major operating system platform. With a long and diverse technical background, Loyal has a wide-ranging set of both basic and advanced skills from network security and professional hacking to desktop, web, and mobile device development.

Loyal is recognized as creating the first intrusion-detection and correlation App for both the iPhone and iPad to complement Aanval, his globally successful Snort and Syslog network intrusion management creation.
Additionally, Loyal has designed, developed and published several profitable iOS applications, which remain available today on the Apple App Store.

Loyal also semi-regularly maintains his personal blog, which can be found at http://www.loyalmoses.com.

Books From Packt


Xcode 4 iOS Development Beginner's Guide
Xcode 4 iOS Development Beginner's Guide

iPhone JavaScript Cookbook
iPhone JavaScript Cookbook

Cocos2d for iPhone 0.99 Beginner's Guide
Cocos2d for iPhone 0.99 Beginner's Guide

Flash iOS Apps Cookbook: RAW
Flash iOS Apps Cookbook: RAW

Unity iOS Game Development Beginners Guide
Unity iOS Game Development Beginners Guide

iOS Development using MonoTouch Cookbook: RAW
iOS Development using MonoTouch Cookbook: RAW

Cocos2d for iPhone 1 Game Development Cookbook: RAW
Cocos2d for iPhone 1 Game Development Cookbook: RAW

Core Data iOS Essentials
Core Data iOS Essentials


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
r
V
w
5
5
x
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software