iPhone User Interface Cookbook: A concise dissection of Apple's iOS user interface design principles

1. We should start by sketching several rough boxes that are scaled roughly to the size of an iPhone or iPad. The iPhone screen is a rectangle measuring approximately 4.5 inches by 2.5 inches. The iPad screen measures approximately 9 inches by 7 inches.

Next, we should go about designing a wire frame mock up of how we anticipate interacting with our application, so that we know exactly what we are looking for in our prototype. The following screenshot shows how a wire frame should give a visual representation of how the user will flow through the final application. In the quick wire frame of a dictionary application below, we gain a good idea as to how the user will interact with our work.

2. The paper is literally our blank canvas right now, so we should experiment with ideas and get an idea of what we want our app to look like.

Often, it's useful if large sketch paper is used when designing an interface. This allows space for notes and multiple screens to be sketched.

We'll be designing an application in either landscape or portrait view, and may want to place out multiple possible screens on our page of sketch paper to help lay out an intended application flow.

From here, we can begin to sketch out our interface on screen. Buttons, text, and other interface elements can be placed in the approximate size and position that we desire our future app to look like.

3. With our application screens laid out on paper, you begin to literally place the paper in your hand and touch it as if it were a real iOS device.

Take a quick note of the visual changes that occur when a finger is placed upon the interface. Does touching a button cause the user to place their hand over important data? Do buttons seem to be spaced far enough apart that a user could easily tap on one without errantly tapping upon another?

4. Take notes on the process of interacting with your sketched mock up application and proceed to make changes to the sketch, and then repeat the process.

Ideally, we will go through three or four revisions until we design something that we could see ourselves enjoying on our iOS device.

5. At this point, our drawings may be slightly sporadic and our notes may be messy. Since the reasoning behind our design is still fresh in our minds, now would be the best time to go back and redraw views or notes that are unclear. Once we're happy with our work, we are done sketching up our application.

1. Much like we did in the previous recipe, we should begin by constructing a wireframe of our application.

This will help us to get an idea as to how our application will flow and what screens will be required for our work.

2. Next, we should go about sketching out each of our intended screens so that we have an expected design for our rapid prototype.

We don't need to add an exceptional amount of polish or have our design be 100 percent completed, but it will be useful to have an idea as to what we're planning for the application to look like.

3. After we have a wire frame to visualize application flow, we should go about determining how to build the prototype application with the least amount of content possible.

For example, if we're building a dictionary application, what would be the fewest number of entries we need in order to make sure that our design and concept works? As a rule of thumb, we should have enough substance in our prototype to not have doubts about the success of any feature in the application.

4. With our prototype planned, we should go forward with programming our basic application in whatever format that works the best.

If we have the time, it's often best to produce an actual app in XCode for our rapid prototype, as this will give us a significant code base to start with when we begin work on the final application. However, this method is often time consuming and costly, so we may decide to go by another route.

Prototypes - © iridescent.co

5. If we are looking to avoid XCode and Prototypes, we can design our prototype in basic HTML instead.

Several open source HTML and JavaScript frameworks exist for web developers looking to build a mobile friendly website and these tools can be used for prototyping an application as well.

1. We should start by going through our old applications and prepare to update outdated resources for the higher resolution display.

2. Next, we hope that our original art files were created either as vectors, or as raster pieces greater in resolution than 640 pixels by 960 pixels, that were scaled down for the iPhone. If either of the previous two statements is true, we're fairly well off. If not, we've got a bit of a rough road ahead of us.

3. After we've gone about updating our resource art for the Retina display, it's time to update the file names of each piece for inclusion into our app project.

Due to exceptional engineering by Apple's iOS team, it's extremely simple to name our high-resolution art so that our app knows how to handle these new files. To properly name our high-resolution files, we only need to append @2x onto the file name of the low-resolution resource file name.

For example, if we have a resource called Button.PNG, we need to name our new double resolution resource file as Button@2x.PNG.

4. Once we've renamed all new high-resolution resource files to include the @2x suffix, we're ready to hand the new files off to our programmer or include them into the XCode project ourselves.

5. We should take the new files and include them into the XCode project as we would do to any other art file and that's it. There's no need to play around with any code or project settings; just leave the new art in the same resource folder as the original resource file.

At this point, our application should be well prepared for the Retina display. No matter if our user has the high-resolution screen or not, our application will continue to look great.

1. In preparing our application and device for testing, we're going to build what is called a Provisioning Profile. This file is required for applications that we want to test on a device and will include information from our Development Certificate, Device UDID, and App ID. The Provisioning Profile works with XCode, iTunes, and our device to make sure that we're running an authentic copy of our app.

First, acquire the iOS Development Certificate by generating a Certificate Signing Request with Keychain Access. This process will give your applications the appropriate private key required for an iOS device to run our application.

Launch Keychain Access from our Applications folder in OS X. Next, visit the Preferences window, which can be found in the Keychain Access menu bar or by using the Command + comma keyboard shortcut. Navigate over to the Certificates tab, and then turn Online Certificate Status Protocol and Certificate Revocation List modes off before closing the Preferences window.

2. Next, go back to the menu bar and select Request a Certificate from a Certificate Authority under the Certificate Assistant menu item.

3. When filling out the Certificate Assistant form, be sure to use the email address that is associated with our iOS Team Agent Apple account.

4. Fill out the Common Name field, leave CA Email Address blank, click on the Saved to Disk radio button, select Let Me Specify Key Pair, and then click on Continue to proceed.

5. Select 2048 bits key size and RSA algorithm options when prompted on the next screen. After clicking on Continue, a CSR file will be created on our computer's desktop.

6. Now log into the iOS Provisioning Portal using our Team Agent account. Click upon the Certificates navigation option, then click on Request Certificate under the Development tab.

7. Scroll down the page, click on Choose File, then select the CSR file from our desktop.

8. After successfully submitting the file, an email should be sent to the Team Admin and the status of our uploaded certificate will change to Pending Approval. The Team Agent account user can then approve the certificate request and a new certificate will be available for download in the Certificates menu in the iOS Provisioning Portal.

9. Once downloaded, double click the new .cer file and install the certificate using Keychain Access. This new certificate will last for a year before it expires, after which we'll have to go through this whole process again.

10. With our new certificate loaded onto our computer through Keychain Access, we're now ready to configure our test device through XCode. We should now tether our iOS device to our computer through the standard 30-pin connecter and launch iTunes.

Once the device finishes the sync process, select the device under the Devices menu and click on the Summary tab. Now we'll want to use our mouse to click on the device serial number that is located near the top of the window. This will reveal our device's UDID, which we can select by using the Command+C copy shortcut.

iTunes - © 2001-2011 Apple Inc.

11. We now need to create an App ID, which is a unique identifier that Apple uses as part of the Provisioning Profile. App IDs help make special iOS features like in App Purchase, Push Notification, or Game Center work.

Using our Team Agent account, log into the iOS Provisioning Portal and navigate to the App ID menu section. Click the New App ID button and give a short description for our App ID. For the Bundle Seed ID drop down option, either generate a new Bundle Seed ID or use a previous ID. We would use a previously generated ID if we wanted our application to share data with an existing application.

Now we should enter a Bundle Identifier into the text field. This identifier should match the CF Bundle Identifier that has been set for the app under the Application Settings in XCode. If we ever plan on using features like in App Purchase or Push Notifications in our app, we should use a unique Bundle Identifier. Apple suggests the com.companyname.appname format, to guarantee that our Bundle Identifier is unique across all IDs. For example, a company called ABC Software with an application called Our Great App would create a Bundle Identifier called com.abcsoftware.ourgreatapp.

12. Since we've now created our development certificate, registered our test device, and created an App ID, we can move forward and create the actual Provisioning Profile for our application. Using this new profile, we can successfully send a test application to a device and finally try out our application.

Using our Team Agent account, visit the Provisioning menu section of the iOS Provisiong Portal. Click on the Add button and give a name to our new Provisioning Profile. We should then click the check buttons for each device that we want to test our application on. Finally, we should select the Developer Certificate and unique App ID that we want to use for our application.

After entering in all of this information, click on the Submit button and a new Provisioning Profile will be created which we can use to test our application. While still in the Provisioning section of the iOS Provisioning Portal, we can download our new profile and save it to our computer.

13. Once the Provisioning File has finished downloading, drag the file from Finder to XCode or iTunes to install the profile. We should now launch XCode and open the Organizer under the Window menu bar option. As long as our iOS device is still connected, we should see it here in the side menu. Under the provisioning option in the window, click the plus button and locate the Provisioning Profile if it isn't already selected.

14. At this point, we've successfully created a provisioning profile for our test application. Now head to our project file in XCode, select the project from the Target option in the side bar, then hit the blue Info button up on the toolbar. Scroll down and set the Code Signing Identity field to developer certificate associated with our new Provisioning Profile. We can now close the Info window.

1. We should start by loading the application and specific view that we desire to take a screenshot of on our iOS device.

Start by heading to the application that we want to take a screenshot of, and keep it open on our iOS device.

2. Next, we should hold down on the sleep button sitting on the top right or left of the device and then quickly press down the home button.

Both buttons must be pressed at the same time for the screenshot to be taken. It may take a bit of practice to not put the device to sleep while taking a screenshot.

3. We should see a white flash, indicating that a screenshot was successfully taken. Next, we need to go into the Photos application.

Once we see the white flash of light on screen, we'll know that the screenshot had been taken successfully and we can move on to the Photos app to send the screenshot to our email inbox.

4. Our screenshot will show up as the last taken photo, so we can now email, print, MMS, or upload the photo to a computer using iPhoto.

1. The iPhone Human Interface Guidelines offer a great example of how essential UI elements should interact and behave.

We should start by verifying that our Tab Bar, Navigation Bar, and Alert Views work as emphasized by Apple. Many app rejections occur because fundamental UI elements do not work as suggested in the Human Interface Guidelines.

2. Next, we want to make sure that our interface does not mimic form and function of an Apple application that comes pre-installed on iOS, such as Music, the iTunes Music Store, or the App Store.

Apple tends to pick and choose when to implement this rule, with many web browsers and compasses seeing approval into the store.

3. We'll want to be sure that we're not using trademarks, logos, or a brand identity which we have not been given rights to use.

Developing an unofficial sequel to our favorite video game may seem like a great idea, but Apple will reject our application if we do not have the rights to use a character or specific image.

This rule also applies to using icons or artwork that looks similar to iOS system artwork. So for example, if we decided to build an eBook reader, we should refrain from using an icon that could be confused with the iBooks icon.

4. We should also guarantee that we do not include excessive swear words, gratuitous sex, or drug use in our application.

Apple is very adamant about the fact that the App Store should be a family friendly place to purchase software, and inappropriate language or crude content could lead to rejection of our application.

We must also assure that we do not reprogram hardware buttons on the iOS device to serve a function other than their dedicated system wide function. This means that we can't set up the volume up or down button to serve as a shutter button in our camera app, nor could we program the home button to work as a way to fire a weapon in our video game. All device hardware buttons must work as intended throughout our application.