Categories are an Objective-C syntax for adding features to a class without subclassing it and without even having access to its code (its .m file).

This comes in handy when you want to keep using a specific class (for example NSString) but would like to add an extra feature.

We have seen categories before, when using the AFNetworking framework. UIImageView+AFNetworking is a category on UIImage that allows setting an image using a URL. It does this by adding methods to UIImage such as setImageWithURL: and setImageWithURL:placeholderImage:.

Categories have their own .h and .m files. These are usually named +. These can be easily created through the New File menu in Xcode.

Header Source

Categories can have their own methods and properties, but no instance variables. This means that properties must be implemented and cannot be synthesized.

Header Source

To use a category, we just need to import the header into the class where we need the additional functionality. This will make the extra methods available to use.


User Testing

After building and testing your app yourself, it’s always a good idea to have a select group of users test your app. These users should be representative of your target audience, and they will usually give you good insight on what works well and what doesn’t in your app. This is also a good way to find bugs as these testers will try to use your app in ways you didn’t anticipate.

To add a device for testing, it needs to be registered for Ad Hoc distribution. The tester needs to send their device ID to the developer, who will add it to the developer account. Most Apple Developer Programs allow for a total of 100 test devices, except for the University Program which allows for 200 test devices.

This device ID is then included in an Ad Hoc Provisioning Profile. This profile is a simple file that contains access rights for an app. The provisioning profile can then be added to Xcode and used to build the app, and must be installed on the device at the same time as the app to allow it to run.

The traditional way of doing this is relatively long and demands a lot from the testers:

  1. Find your device identifier (UDID) by connecting it to a computer and launching iTunes.
  2. Email this identifier to the developer.
  3. Wait for the developer to add your device ID to the portal, to compile it in a provisioning profile, and to rebuild the app using this updated provisioning profile.
  4. Receive the app (with extension .ipa) and the profile (with extension .mobileprovision) from the developer.
  5. Drag both files to iTunes.
  6. Sync the apps on your phone.
  7. If everything went well the app should run, otherwise you will need to troubleshoot.

Fortunately for us, a company called TestFlight has developed a process for distributing apps to testers that is easy and painless. A user simply needs to visit the website on their device and follow the simple steps to create an account and register their device. Once that’s done, a developer can add them to a team and prepare an app for testing without requiring more info from the tester. Once the app is ready, the developer simply uploads it to the TestFlight site where it becomes available to all testers for download. There is no need to manage files or to connect the device to a computer.

Another great feature of TestFlight is that it automatically logs errors and crashes for the app, so that if something goes wrong, the developer can investigate without having to ask the tester for details they probably will not be able to provide.


Once your app is ready for the general public, it is time to package a release build for it. The most common distribution platform is the App Store, but depending on the Developer Program you are registered in, you might also be able to build apps for In House distribution.

In House distribution essentially means bypassing the App Store and is typically used for distributing apps on a group of devices within an organization. The process is very similar to Ad Hoc distribution. You create a specific In House Provisioning Profile which you use to build the app. The main difference is that you don’t need to populate a list of device IDs as the app can run on any device. You can then install the app on the actual devices using iTunes or TestFlight.

App Store distribution is a little more complicated. Once again, you need to create a specific App Store Provisioning Profile and build the app against it. This app is then submitted to Apple using the iTunes Connect tool. You will need to fill out information about the app (description, category, icons) which will be used in the App Store. Your submission will then have to be approved by someone at Apple, and that can take anywhere from a couple of days to a few weeks depending on how busy they are.

Once your app is approved, it will go up in the store and stay available as long as you keep paying your $99 yearly developer fees.

If your app gets rejected, you will usually get a specific reason as to why it was rejected, and you will be able to resubmit once you fix whatever it is that Apple did not like. Unfortunately, your app will go back at the end of the submission queue, and it could take a few days until it is reviewed again.


Core Data

There are many different ways to save and load data for your app. We’ve already been using NSUserDefaults for storing preferences and small amounts of data. For larger data sets, you can use XML files or an SQLite database. This data can then be read and written directly, but that tends to be more complicated than you’d expect.

That’s where Core Data comes in. It is a framework that allows you to manipulate your data directly in Objective-C. A lot of the setup and connection work is already taken care of, and you create your data models and relationships using a graphical interface. Behind the scenes, the actual data files can be XML, SQLite or binary, and your application will still access it in the same way.

To use Core Data in your project, you need to check the corresponding box on the New Project window. Note that this option does not appear for all project types, so make sure to pick a Master-Detail Application.

Core Data Classes

The managed object model is like the database schema. This class that contains the definitions for each of the objects that you are storing in the database. You will hardly ever create or edit this file in code, but do so visually using the .xcdatamodeld file in the project.

The persistent store coordinator is like the database connection. You use this object to set the name, type, and location of your database. Any save operation also goes through this single connection which, as its name implies, keeps all the data coordinated.

The managed object context is like the “scratch pad” for objects. Whenever you need to get, delete, or insert objects in the persistent store, you will call methods on the managed object context.

The managed object is a generic class that is at the base of any Core Data models. Think of it as NSObject for Core Data.

You will always have a single instance of the NSManagedObjectModel, NSPersistentStoreCoordinator, and NSManagedObjectContext. You will usually have many instances of many different NSManagedObject subclasses.

If we look at the App Delegate implementation in the project we just created, we can see how each of these objects is created.

First, the model is loaded from the visual file.

Then, the model is used to build a connection to the persistent store. You’ll notice that by default, this is an SQLite database stored in the application’s documents directory.

And finally, a managed context is created and linked to the persistent store coordinator.

Defining the Model

The model for the data is defined in the .xcdatamodeld file. Objects are called entities here, and they hold attributes with a name and a type. You can also create relationships linking entities together.

You build a new entity by clicking the Add Entity button at the bottom. You can then assign a set of attributes to this entity.

The entity can also have relationships to others. You can customize the type of relationship in the Data Model Inspector on the right.

In our example, a Session can have any number of Events (including none), and an Event can only be linked to one Session. Furthermore, if you delete a Session, it will automatically delete all linked Events, because we set the Delete Rule to Cascade.

Reading and Writing

We want to create a new Session every time the Master view is shown on screen. We will first check if any Sessions already exist in the store.

The first step is to build an NSFetchRequest for the requested entity.

We will then execute the request on the managed object context and retrieve all of the results in an NSArray. We can then check whether or not any Sessions exist by looking at the number of elements in the array.

If no previous Session exists, we’ll create a new one with number set to 1. Note that we use the setValue:forKey: method to set the entity attributes.

Once our new Session is created, we need to save the managed object context to the store.

If a previous Session already exists, we’ll create a new one with number set to the incremented value of whatever the last number was.

First we’ll need to sort the fetched results using an NSSortDescriptor.

We can then read the highest Session number, and use that value to build our new Session. Note that we use the valueForKey: method to read entity attributes.

We can clean up our implementation by removing duplicate code.


If you try to add a new entry to the table, the app will crash because the Event entity now requires a relationship to a Session.

First, we will add an attribute to store the current Session to our MasterViewController class.

We can then add the Session value to any newly created Event.

If we print out our fetch results, we’ll see that Events are automatically added to the Session‘s events array. This is because and Event.session are set as inverse relationships.

Strongly-Typed Models

So far, we’ve used the base NSManagedObject class to access our data, and the setValue:forKey: and valueForKey: methods for setting and getting attributes and relationships. Although this can work fine, it can lead to errors and typos as we are not getting any help from the compiler to use the correct names and types.

A better way of doing this is to create a model class for each entity.

  1. Open the .xcdatamodeld file.
  2. Select an entity.
  3. Go to the File / New / File… menu and select the NSManagedObject subclass option.

  1. This will generate and add a header and implementation file to the project.
  2. Repeat with the remaining entities.

You can now use these subclasses instead of the base NSManagedObject.

  1. Core Data Programming Guide. Apple, Sep 19 2012.
  2. Core Data on iOS 5 Tutorial. Ray Wenderlich, Apr 13 2010.


Localization is the process of making your apps work with multiple languages.

This is surprisingly a lot simpler than it sounds, and is achieved by calling special functions and through built-in Xcode support.

Download the starter project to begin.

Localizing Strings

The first step in localizing an app is to separate all the text from the code. We will move all hard-coded strings to a special .strings file. You should name this file Localizable.strings so that your app knows where to look for it. Otherwise, you’ll have to add an entry to your .plist file.

The format for each entry in the file is "Key" = "Value";.

You can then read and use this data in your app using the NSLocalizedString macro.

You can now localize this file for the English language.

  1. Select the Localizable.strings file from the Project Navigator (on the left).
  2. Click on the Make localized… button in the File Inspector (on the right).
  3. Select English as the initial localization from the menu that pops up.

Repeat the process for the hello.jpg file.

If you examine the project files in the Finder, you will notice that both files have been moved inside a folder called en.lproj. You can localize your app in 40 languages, each identified with a 2-letter code.

You can add a French localization to the app from the project’s Info tab.

Xcode will ask you which files to include in the new localization. Select all but the Storyboard.

This will copy the selected files into an fr.lproj folder.

Rename allo.jpg to hello.jpg, and replace the version in fr.lproj.

Back in Xcode, you will notice that you can now edit two versions of the localized files. Replace the contents of Localizable.strings by their French counterparts.

You can now run your app on a French language device, and it will automatically load the correct text and resources.

You can also localize the app name by adding an entry for the CFBundleDisplayName key of the InfoPlist.strings file.

Note that sometimes changes won’t load while testing because of caching issues. Make sure to delete the app from the Simulator and to clean the project in Xcode if you encounter any refresh problems.


Many of the frameworks listed below are written in the C++ language. C++ is an object-oriented superset of C, much like Objective-C is. It is one of the most popular programming languages and can be used directly in your iOS programs.

  • Source code header files always use the .h extension.
  • Source code implementation files written in pure C and Objective-C use the .m extension.
  • Source code implementation files written in C++ use the .cpp extension.
  • Source code implementation files written in in both Objective-C and C++ use the .mm extension.

C++ is a very powerful language that is less abstracted than Objective-C. This means that it will generally be more complicated but offer better performance. One of the main differences you might notice is that you’ll have to manually manage your memory (allocations and deallocations). However, most of the frameworks listed below include some type of reference counting.


openFrameworks is an open source C++ toolkit for creative coding. Its design is heavily influenced by Processing, which should make many of the functions familiar to you. openFrameworks was originally created for high-performance graphics and video processing, but can be used for a variety of applications.

A few years ago, openFrameworks was ported to iOS, allowing desktop applications to run on mobile devices without changing a single line of code. Many successful iOS apps are built with openFrameworks, such as SpellTower.

One of the strengths of openFrameworks is its large user base and their dedication to open source software. You can find a long list of contributed addons which can help you perform a variety of tasks. If you’re stuck on a problem, you can browse through the forum or post a new question, and it will most probably be answered within the hour.

You can download the iOS version of openFrameworks here and follow the setup guide to get started. This solution will create an app that is “openFrameworks driven”, meaning that most of your code (if not all) will be part of the openFrameworks project. Alternatively, you can use the ofxiOS addon, which treats openFrameworks projects similarly to other views, and keeps your app “Objective-C driven”.


Cinder is another creative coding library for C++. The main difference with openFrameworks is that it uses more specific system libraries instead of opting for cross-platform open-source solutions. This will usually result in better performance but is more complex to use and code. Cinder also makes heavy use of C++ namespaces, which can be confusing and hard to read. Cinder is aimed and experienced developers, so it’s harder to get into if you don’t know what you are doing.

There are a few Cinder apps in the App Store, notably DMesh and Planetary.

The Mac version of Cinder can be downloaded here and includes compilation targets for iOS.


pocode is yet another C++ library for interactive media. Whereas openFrameworks and Cinder are all about high performance graphics, pocode’s strength lies in interface design. It borrows a page from Flash where every object has spatial properties (position, rotation, scale), built-in event handlers, and a cascading parent-child relationship.

pocode for Mac can be downloaded here and includes iOS templates and compilation targets.


C4iOS is the newcomer to the game, having only been released a few months ago. It is also a creative coding toolkit, but unlike the frameworks listed above, C4iOS is written in Objective-C. Instead of having to switch in and out of a special C++ view, you can simply use C4iOS objects directly in your code. As the name implies, C4iOS is also iOS specific and works seamlessly with multitouch interactions and gestures.

Although C4iOS still does not have a very large user base, it has very clear and complete documentation, including examples and tutorials. It’s also Canadian, so +1 for that :)

C4iOS can be downloaded from here.


Cocos2D is an open source game engine that has been ported to many different languages and platforms, including Objective-C for iOS. It only supports 2D, meaning that it’s a great toolkit to build a puzzler or platformer, but not ideal for a shooter.

Cocos2D simplifies the process of creating scenes in apps (for example a menu scene, a game scene, a high score scene, etc.) It uses OpenGL ES for rendering and can easily incorporate one of two robust and popular physics engines: Box2D and Chipmunk.

Cocos2D has been used by many games and apps in the App Store, including FarmVille, Trainyard, and Björk’s Biophilia.

Cocos2D can be downloaded from here.


Unity is a multi-platform game engine with a port for iOS. It is the industry standard for developing high performance, complex games, and its $1500 price reflects that. You can however download a limited version free-of-charge, but will still need the $400 iOS plugin.

Unity projects are built in C#. It can be used to build 2D and 3D environments and includes a multitude of plugins for animation, modeling, physics, etc.

Unity is used for many games in the App Store, such as Triple Town and Shadowgun.


The Open Graphics Library (OpenGL) is a framework for rendering 2D and 3D graphics. OpenGL usually interacts directly with the GPU, achieving hardware-accelerated rendering. OpenGL is a cross-platform, multi-language API and it is widely used in visualization software and video games.

OpenGL ES is the version of the library that runs on embedded devices such as the iPhone and iPad. It is a subset of desktop implementations of OpenGL. There are two versions of OpenGL ES available for use on iOS. Version 1.1 uses a fixed pipeline, meaning that you use a set of built-in functions to build your scene. Version 2.0 uses a programmable pipeline, meaning that there are no built-in functions and everything must be built from scratch. As you’ve probably guessed, 2.0 is a lot more complicated but allows for more control than 1.1. For this lesson, we’ll be using version 1.1 as we’re just getting our hands dirty with OpenGL.

The OpenGL API for iOS is written in pure C, much like the Core Graphics framework, and integrates seamlessly with Objective-C classes. You need to link against three additional frameworks to use OpenGL code in your apps: Quartz Core, OpenGL ES, and GLKit.

GL View

GLKView is a UIView subclass used to render OpenGL graphics.

The GLKView needs to be attached to an EAGLContext. This is a drawing context, which manages all of the data iOS needs to draw with OpenGL.

The GLKView must also be connected to a GLKViewDelegate, which will be polled periodically to draw content in the view. This is done by implementig the glkView:drawInRect: method.

We can try pulsing the red background by using a couple of variables to set the color.

You’ll notice that this does not work as expected, and that is because glkView:drawInRect: is not called regularly. Similarly to drawInRect:, this method is only called when the view is first shown, when it is resized, etc.

When using OpenGL, you will often need to redraw the view at every frame. We need to replace the default redraw behaviour by another that redraws in sync with the screen refresh rate. This can be achieved using a CADisplayLink timer.

GL View Controller

We just saw how to build and render to a GL view from scratch. GLKit offers a much easier solution for doing this using a GLKViewController. This is a UIViewController subclass that also implements an OpenGL ES rendering loop. The GLKViewController will create the GLKView and set itself as its delegate automatically, but you still need to set the EAGLContext manually.

Header Source

At this point, it’s a good idea to cleanly initialize and destroy the context.

GLKViewController also provides us with an update method, which is called every frame like the draw method, but intended for app logic.

GLKViewController allows us to set the desired frame rate using the preferredFramesPerSecond property. Note that the actual frame rate may be lower than this, depending on how long it takes to render a frame. The actual frame rate can be read using the framesPerSecond property.

Drawing Shapes

Rendering geometry in OpenGL is done using vertices (points). Vertices can have multiple properties such as position, colour, texture coordinates, etc. These vertices can be passed to the buffer using many different methods. We will use one of the simplest called vertex arrays.

Note that the origin (0, 0) is set to the center of the view by default.

OpenGL ES can only render triangles, so you will often need to combine multiple triangles to build the desired shape.

As we are only working in 2D, we can get rid of the z-coordinate.

We can set the shape color using glColor4f(). This will change the color of anything that is drawn until the next call to glColor4f().

We can also set the color on a vertex-by-vertex basis by passing a color array along with the vertex array.

We can optimize our data by removing duplicate points. We can then use an index array to indicate the order in which the vertices should be drawn.

  1. Beginning OpenGL ES 2.0 with GLKit Part 1. Ray Wenderlick, Oct 19 2011.
  2. OpenGL ES Programming Guide for iOS. Apple, Feb 24 2011.

Final Project

For the final project, you will need to develop a fully functional mobile application for iOS devices.


You can build any type of app you want. It can be a game, a utility, an artistic piece, a fun toy, etc. Your idea needs to be original and fresh. You should not build something identical to an already available app. However, an idea will take a pre-existing product in a new direction is totally fine. For example, a photo album app is a bad idea, but a photo album app that identifies animals in pictures and automatically creates albums by species is a good idea.

Your app can be designed for iPhone/iPod only, iPad only, or Universal. Your choice of device support should depend on the type of application you are developing. For example, a geolocation app would be better suited for iPhone, and a text editing app would be better suited for iPad. A Universal app must reflect in its design the differences (in hardware and function) between iPhone and iPad.

App design guidelines must be considered in your project. Make sure the features correspond to the main purpose of the app, and that the experience is consistent and user-centric.



Nov 7

Project Launch

  • Come up with an idea (or many) for your app
  • Present your app idea to the class
  • Use your peers’ comments to solidify your idea

Nov 14

Design Pitch

  • Present your app design to the class
  • Explain the main purpose and features
  • Define the target audience
  • Prepare wireframes to help visualize the user experience
  • Use your peers’ comments to solidify your design

Nov 21

Work Session

  • Develop your app

Nov 28


  • Present your fully functional app to the class
  • Explain any challenges you encountered
  • Peer review each other’s apps
  • Celebrate

You have almost 4 weeks to complete your project. The scope and complexity of your app must reflect this timeline. It should be much more complex than an assignment question, but a multi-level first-person 3D shooter is probably wishful thinking.

Make sure that you can complete the project by the deadline.


11 iPad 2 devices are available to our class for the final project. You will be able to use these for development starting on November 13. The details aren’t set in stone yet, but it’s looking like the iPads will live in the Computation Lab, and you’ll be able to check them out from there.

You will install your app on all of the iPads for the final presentation, so that we can all test them out directly.

If you have your own iOS device, you can use it for development, but you will still need to install your project on the class iPads for delivery.


Your final project is worth 50% of your total grade for the class.


Concept and Idea

Platform Awareness
Audience Awareness


User Experience and Design

Platform Characteristics
Human Interface Principles
User Experience Guidelines



Code Correctness
Code Elegance and Style


Peer Review

Anonymous grading of each other’s projects


Design Briefs

In today’s lab you are going to team up with another student in the class and come up with solutions to design briefs. You will then present your results to the rest of the class and we will discuss the pros and cons of your solutions.

Keep in mind the App Design Guidelines when thinking about these problems.

  1. Design a control interface for a 2D platformer game for the iPhone.
    • You need controls for moving to the left and to the right, and for controlled jumping, i.e. the user needs to be able to perform short and long jumps.
    • Because of the limited space on the iPhone screen, you can’t use a directional pad.
  2. Design the complete experience and interface for a video kiosk app for iPad.
    • The app is intended for a museum setting, as a guestbook for patrons to leave comments at the end of their visit.
    • The app must record a short video using the camera and submit this video to the museum’s YouTube account. It can provide any features you feel are necessary to perform this main task.
    • Include all the screens you design and the flow from screen to screen in your solution.
  3. Design the control interface for a Tetris game for the iPhone.
    • You need controls for moving the falling piece to the left and to the right.
    • You need controls for rotating the falling piece clockwise and counterclockwise.
    • You need controls for dropping the falling piece instantly onto the game floor.

App Design Guidelines

Before diving into code, you need to take the time to properly design your app, both from an interface and experience point of view. It is important to take the time to define an app’s feature set and intended audience to help guide the design process. This must be done while keeping in mind the features and limitations of the platform this app will run on. Tailoring the experience to the function, to the user, and to the platform are all necessary to the development of a successful app.

  1. Determine what the app’s main purpose is.
  2. List all the features you think are important for this purpose.
  3. Determine who your users are.
  4. Filter the feature list for your audience.
  5. Filter the feature list for the target platform.

Platform Characteristics

The display is at the heart of the user experience as it is both the main input and output interface. The content is viewed on screen and the experience is driven by touching that same screen.

Users must be able to “grab” a control without seeing it. All controls should therefore be large enough and spaced apart enough so that there is no confusion when they are being selected. A good rule of thumb is to have controls of at least 44 x 44 points in size.

The device being handheld, it is often rotated in different orientations. This can happen for a variety of reasons, from the user being tired to feeling that some tasks are more natural in specific orientations. This is something that must be taken into account and accommodated in the app design if it makes sense.

Finally, it is important to remember that apps respond to gestures, as opposed to mouse clicks and keyboard typing on desktop devices. Furthermore, a gestural language has been established over the last few years because it has been adopted by many apps, and should be considered when designing interactions. For example, dragging to scroll or pan, and pinching to zoom in and out.

Human Interface Principles

A great user interface does not focus on the device capabilities but on the way users think and work. It must be inviting, simple, and intuitive.

Aesthetic Integrity – How well does the appearance of the app integrate with its function? For example, a game should be immersive and take over the entire screen, while a to-do list should be more subtle and sober.

Consistency – This includes both consistency with other apps and within the app itself. Does the app take advantage of established standards users are comfortable with? Does the app maintain its visual identity throughout the experience? Do UI elements mean the same thing and are used the same way all the time?

Direct Manipulation – The multi-touch screen allows users to directly manipulate elements instead of going through a separate interface. For example, instead of having buttons for zooming in and out of an image, use a pinch gesture.

Feedback – Users expect immediate feedback when interacting with an interface. If an operation takes a long time, like a network request for example, let them know that the system is “thinking”. If an operation takes longer than expected, offer a status update reassuring them that everything is under control.

Metaphors – References to real life objects allow users to quickly understand how to use an interface. For example, a switch can be flicked to toggle a setting, or a rotary dial can be turned to fine tune a value.

User Control – The user should always initiate any action and feel in control while using the app. Users also expect to be able to undo or cancel an action that is underway.

User Experience Guidelines

Focus on the primary task – If a feature does not relate to the main purpose of the app, it is unnecessary. This also works on a feature basis. You should analyze what information is needed in each screen, and get rid of anything extra (either including it in a different context or removing it altogether).

Emphasize the content users care about – Decrease the weight of the UI by minimizing the number of controls and their prominence on screen. For example, you can fade away navigation controls in a slideshow if the user has not interacted with them for a few seconds.

Think top down – The top of the screen is most visible to users as they tend to hold the device in their hand, interacting with the screen using their thumb. The most important and frequently used information should be placed at the top.

Make usage easy and logical – Navigation through the app should be predictable. Users should immediately understand how to use the app and where to find information they are looking for. For example, clicking on a person’s name in the address book reveals their contact information.

Use user-centric language – You want to avoid technical terms and keep terminology simple yet accurate. For example, “load a webpage” instead of “perform an HTTP request”.

Keep file-handling in the background – Users do not expect to have to deal with files and folders on a handheld device. Information about file paths, saving, loading are usually irrelevant to the experience and should happen silently.

Start instantly – Users tend to interact with apps for only a few minutes at a time. Avoid splash screens, only display about screens on user request, and delay login screens as much as possible.

Always be prepared to stop – Save data reasonably often and save the app state when it moves to the background to allow the user to continue where they left off.

Make it pretty – Use beautiful graphics and subtle animations to make your app attractive and enjoyable to use.


It is often useful to start thinking about an app outside of Xcode and even completely offscreen. Although a napkin and a pen are good enough to sketch out an initial idea, some tools can come in handy when moving forward into more concrete interface and experience design.

Pen and Paper

iPhone Application Sketch Template (Oliver Waters) – Printable iPhone template with grid squares at every 10 pixels, and tick marks indicating the position of the status bar, navigation bar, and tab bar.

App Sketchbook (Square Position, LLC) – Booklet with iPhone or iPad stencils for sketching mockups, with a notes section at the bottom of the page.

Stencil Kit (UI Stencils) – Stencils for commonly used iPhone and iPad controls and icons. A sketchpad and PDFs at the same scale are also available.


iPhone Mockup (Lukas Mathis) – Online stylized design tool including standard component library. Designs can be collaborated on by sharing the URL.

MockFlow – Online wireframing tool with a large library of user-generated content.

OmniGraffle (OmniGroup) – Diagramming application that can be used for creating wireframes and flowcharts. Many free iPhone and iPad stencils can be downloaded from Graffletopia (and various other places on the web) for interface design.


iOS 6 GUI PSD (iPhone 5) (Geoff Teehan) – Photoshop document containing a complete and well-organized collection of standard UI elements for iOS.

iOS Photoshop Actions & Workflows (Bjango) – Photoshop actions for performing common iOS design tasks.

DevRocket (Ui Parade) – Photoshop plugin for performing common iOS design tasks.


Cocoa Controls – Collection of user submitted interface elements for iOS apps.

  1. iOS Human Interface Guidelines. Apple, Sep 19 2012.