In this chapter, we will cover:
Starting with the sketch
Developing a rapid prototype
Migrating to the high-resolution Retina display
Getting our app onto a device
When to use the simulator or a real device
User testing and getting a way for people to test out our app
Taking a screenshot of an application on our device
Working within Apple's guidelines
As an introduction to interface design and development on the iPhone, it's important to learn about the basic skills that we'll need to be comfortable with in order to tackle our first design project.
We'll dive into more technical topics later on, but first we'll start by discussing the different tools of the trade, hardware features that we'll need to focus our design around, and placing our design work on an actual device.
In this chapter, we'll tackle these introductory lessons and gain a foundation for what it will take to jump into the world of iPhone and iPad application user interface design.
As an introduction to interface design and development on the iPhone, it's important to learn about the basic skills that we'll need to be comfortable with in order to tackle our first design project.
We'll dive into more technical topics later on, but first we'll start by discussing the different tools of the trade, hardware features that we'll need to focus our design around, and placing our design work on an actual device.
In this chapter, we'll tackle these introductory lessons and gain a foundation for what it will take to jump into the world of iPhone and iPad application user interface design.
Before we take time to design our user interface in Photoshop, it is important to sit down with a piece of paper and a pencil to sketch out the basics for how users will interact with our app. Once we set a programmer out to begin work on an application with a given interface, it can be very costly to go back and make changes later when we realize that our design has a few small problems that need to be fixed.
Luckily, a notebook and pencil are cheap tools, and we can draw out many example interfaces without ever wasting a dollar of programming time.
For best results, we should find a desk, a good pencil, an eraser, and a couple of pieces of paper. If available, large notepads are preferable, as the extra space will allow room for notes.
Before we step into Adobe Photoshop or XCode with our application design, we should begin by sketching out the idea onto paper.
Note
Photoshop is Adobe's high-profile raster image editing software. XCode is Apple's development environment for iOS and Mac applications. Both apps are essential parts of our development toolbox.
Let's take a look at some basic iOS drawing principles so that we can best prepare our sketches for the transition to pixels on an iPhone screen:
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.
Because iOS devices require a user to physically interact with a variety of interface elements in a small amount of space, sketching up ideas can be a powerful way to test user interface design ideas. If drawn close to scale, we can simulate touch interactions and get a good idea of how our interface will look before we ever paint a pixel in Photoshop.
Several companies provide special graph paper, stencils, and iOS applications that help make it easier to sketch application ideas. Typically these products are inexpensive and make high quality mock ups simple. Many stencil sets also come with many standard UI elements accurately sized, which will allow us to sketch with confidence and precision.
Design Commission produces arguably the best interface design stencils, which can be found at http://www.uistencils.com/products/iphone-stencil-kit. For a low cost, iPhone and iPad stencils can be purchased along with appropriate device sketchpads. Design Commission also has great stencil sets for Android and Web developers, in case we're looking to design for those platforms as well.
As we can see in the following screenshot, the interface stencil contains many common pieces and can help in properly laying out elements on paper:
 |
There are even several iOS applications focused around making the sketching process easier as well. Interface by Less Code LTD, iMockups for iPad by Endloop Systems, and Dapp by Kerofrog are all great applications that can make the mock up process easier. Each offers the ability to drag and drop standard interface elements around on a real iPhone or iPod touch screen, allowing us to quickly grasp the scale and feel of our desired interface on a real device.
Sketching up an application design is a critical step in designing an exceptional user experience, but it doesn't quite compare to actually using our fingers to interact with our interface on a real iOS device.
No matter how well we sketch up our interface, we may come upon a problem wherein a certain aspect of our design doesn't really work well once it's implemented on an iOS device. Sometimes, these design problems are minor and altering our interface to fix the problem isn't a big deal. But there is also the real possibility that a design mistake can be a showstopper, requiring hours of new design work and programming for something that could have been easily solved before development began.
When preparing to put together a rapid prototype, we should first consult with our programmer. There are several different ways to go about developing a rapid prototype, with each having different pros and cons.
Arguably the best way to create a rapid prototype is to literally develop the shell of the application using Apple's suite of development tools for Macintosh and iPhone applications, XCode. This will allow the app to run natively on our test device and also create code that can be used in the final application.
However, there may be situations where developing a rapid prototype in XCode would actually be extremely time intensive and not worth the effort. In these scenarios, there are several other ways to build a simple rapid prototype, which we will discuss in this recipe.
Rapid prototypes can be an exceptional asset to the standard development cycle, allowing us to gain an idea of how our application will work before we spend a good deal of costly time on development. Here are the steps that will help us prepare a rapid prototype:
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.
Note
Several iOS applications have been produced to aid in the development of rapid prototypes. The best example of an iOS native prototyping tool is the simple Prototypes app for Mac by Duncan Wilcox, which can be found on the Mac App Store. Prototypes relies upon its own basic programming language in order to connect different pages of our prototype together, but is a powerful tool for the development of quick prototypes that will run on a real iOS device without requiring XCode.
As seen below, With Prototypes, mock screenshots are given simple properties that are used to contain different attributes of our rapid prototype:
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.
Note
jQTouch, found online at http://jqtouch.com/, is a great jQuery plugin that allows for rapid prototyping of web apps that can be used to test the flow of our application before we go about building our native app.
With a prototype built, we can go about testing our interface ideas for usability and simplicity. It's much easier to alter spacing and button layout on a prototype than it is in a final application and now is the time to verify that our design ideas will make sense when translated onto a physical iOS device.
iOS designers are at a bit of a disadvantage with prototyping when compared to traditional web developers or even desktop application developers.
Interface interaction with a mouse and keyboard has been commonplace for 30 years and most designers have grown to understand basic interface concepts that either work well or fail miserably. In contrast, touch-based interface development is still in its infancy and has really only been prevalent since the launch of the iPhone in 2007.
It's still possible for iOS designers to overcome this competitive disadvantage and develop a great touch-centric interface; it just requires a bit more work. If we start each project with a quick, rapid prototype, we'll help guarantee that we're not sent back to the drawing board late in development because of failed design work.
With the announcement of the iPhone 4, Apple introduced the Retina display. This new technology produces a 3.5 screen with a resolution of 960x640 pixels, which is considered to be the highest resolution screen ever placed inside of a mobile phone. The screen's pixel density is a welcome addition to consumers, but can cause a significant heartache for designers who are unprepared for the change. In this recipe, we'll take a look at how to best prepare resources for future changes in iOS screen resolution.
Updating our art resources for the new screen requires us to double the resolution of our original artwork. To help make this process easier, we'll need the original art resources for our application. Otherwise we'll be producing new high-resolution artwork from scratch, which can be a significant obstacle to overcome.
Now and in the future, it's to be expected that all iPhone and iPod touch devices will feature the high resolution Retina display. If we want success for our application, we should prepare our artwork for the 326 pixel per inch screen.
Let's take a look at a few steps that will help us migrate to the larger screen:
1. We should start by going through our old applications and prepare to update outdated resources for the higher resolution display.
Note
Luckily, Apple has built iOS to properly upscale all standard UI elements that are drawn natively in code or through Interface Builder. Text will also be scaled properly depending upon the device, so we don't need to worry about changing any
UITextViewseither. The only real concern will come into play with art resources, typically stored as .PNG files. Isolate these files so that we have an idea as to what needs to be updated for the Retina 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.
Note
Vector and raster images
Vector graphic files are a type of image format where visual data is stored as a geometrical set of points, lines, curves, or polygons. Vector graphics scale up well because images are displayed as shapes with a specific mathematical relationship, meaning that magnifying the image is no problem because the relationship between the shapes stays the same regardless of size. Vector graphics can be built with an application like Adobe Illustrator but can be somewhat more difficult to use than Photoshop. If our art resources are still available in a vector format, we only need to create new copies of each resource at double the resolution of the old file. Once we do this, we're ready to move forward and prepare these new files for inclusion into our application.
Raster images are built as a grid of square pixels, with each point in the grid having a set color. It is difficult to increase the size of raster graphics because a multiplication in size just means that there will be a multiplication in the amount of pixels that build the image. As such, raster images tend to look pixilated or blurry when increased in size. Doubling the size of a raster graphic will look unprofessional and isn't likely to be of high enough quality for our application.
More likely however, we'll find that our resource files have been saved and only remain in a raster format like PNG:
If, at this point, we're left with only raster images and have no access to either higher resolution artwork or vector images, we have a bit of a predicament on our hands. The tough reality of this situation is that we'll have to go about creating each piece of art again by hand at double its original resolution in order to fit the Retina display.
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
@2xonto 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 asButton@2x.PNG.
4. Once we've renamed all new high-resolution resource files to include the
@2xsuffix, 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.
Apple has developed iOS and XCode so that inclusion of artwork for the Retina display is extremely simple. The operating system is designed to recognize if an iOS device is utilizing the Retina display, and then display the correct resource file size for the specific device. If a Retina display is detected, then the @2x art is used. If not, then the original piece of art is displayed instead.
The introduction of the Retina display with the iPhone 4 was a wonderful example of why designers should create artwork in either a vector format or in a size much larger than they ever intend on using. While it is easy to take something big and make it smaller, it's extremely difficult to take something small and make it bigger.
Even though the Retina unbelievably displays high pixel density of 326 pixels per inch, it seems to be at an upper limit which Apple will likely not increase. Hence, we should prepare for the future by creating artwork at much higher resolutions that we should ever need, just in case.
Since the emergence of the Retina display, several web companies have begun to specialize in the up scaling of mobile phone art for higher resolution displays. We should be wary of hiring such a company, as there are no magical techniques that can automatically increase the size of our low-resolution artwork.
If we do decide to work with a company that specializes in up scaling, we should ask for the contact information of previous clients to insure that the company completely redraws artwork for the higher resolution. We don't want to get stuck paying for artwork that was just magnified in Photoshop.
Once we've planned out our interface and started working on development, we'll need to set up an iOS device for testing. By using XCode and Apple's iOS Dev Center, we'll be able to send pre-release application builds to our iOS device using a standard 30-pin connection cable.
Before we start, we'll want to gather up the iOS device we plan on using for testing, the latest update to the iOS SDK from the iOS Dev Center, and the computer we plan on doing our design work on.
Note
Apple typically keeps a collection of PDFs and videos on the iOS Provisioning Portal, which are much more thorough and up-to-date than this recipe. It would be beneficial to download and read or watch these resources before we begin.
We should also complete this recipe using the Team Agent credentials for our iOS developer account. Apple has two different accounts that we can choose from depending upon our needs as developers. All accounts currently cost $100 per year and allow us to release an unlimited number of apps into the App Store. Little is needed to sign up besides the bank account information and any legal business filings that we may have if we are registering as a company instead of an individual.
Individual accounts are fairly self-explanatory, working best for people looking to release apps under their personal name. If we sign up as an individual, our account log-in serves as the Team Agent.
Company accounts are for development studios that may have two or more developers or designers who all need access to the iOS Development Center forums or operating system pre-release builds. For a company account, the log-in credentials used to create the account is the Team Agent account and this will be needed to create the necessary files for this recipe.
Setting up our computer to process pre-release builds is one of the most difficult tasks that we'll accomplish early on as iOS developers. It's a fairly complex job and can be very confusing at first. Here are some simple steps to help get our test application running on an iPhone, iPod touch, or iPad:
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
.cerfile 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.
Then we head back to our web browser and the iOS Provisioning Portal, where we can select the Devices menu option. Click the Add Devices button, enter a device name, and then paste in the device UDID using the Command+V paste shortcut. Click on Submit and our device has now been configured as a test device.
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.appnameformat, 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 calledcom.abcsoftware.ourgreatapp.
Once we click on the Submit button, our Bundle Seed ID will be created and connected to our new Bundle identifier and this new string is our App ID.
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.
We can now run our application in XCode. We can now use any iOS device to test with, however it is often wise not to use a device that you depend on daily for testing. While there are few repercussions with regards to using a device for testing, it's better to be safe than sorry with a device that you need as a phone or for other work related items.
Installing an application on a test device can be a bit lengthy the first time we go through the process but will become much easier for sequential applications, as we no longer will need to create a developer certificate or register our test device.
Apple's designed the system to make sure that we can securely install pre-release software on devices without fear of our work being pirated or reverse engineered by those looking to take our ideas. The profile system also helps protect users from nefarious developers who may otherwise look to deliver malware applications by circumventing the App Store.
The certificates, profiles, and application IDs that we create will be specific to our developer account, our applications, and our test devices. So unless we specifically intend to run a test application on a specific device, no unintended eyes will be able to see our pre-release work.
Once we've set up our application's Provisioning Profile, we'll be able to run our application as much as we would like on our test device. The benefits of testing our app on a real iOS device will become immediately apparent and we'll forget all about the heartache we went through to get our application up and running in the first place.
Two iOS devices are better than one, and we may find ourselves in a situation where we would like to add multiple iOS devices to our developer account through the Provisioning Portal at one time. Luckily, Apple has developed a method for simplifying this process:
If we're looking to set up multiple iOS test devices at the same time, we can bulk upload the device names and UDIDs using the iPhone Configuration Utility or by creating a tab delimited .txt file. Once we've created a file containing all of our device information, we can upload it through the iOS Developer Portal by clicking on the Upload Devices button under the Devices menu option.
We've discussed setting up test devices, but how many different devices should we use? Should we test on both the iPhone and the iPad?
Ideally, we'll test on as many devices as we can afford. However, we should test on a minimum of three devices. The first should be an iPhone or iPod touch running the latest operating system version available. The second should be an older iPhone or iPod touch running the oldest operating system that we plan on supporting. Finally, we should also test on an iPad, even if we haven't optimized for the tablet interface.
In designing our interface for an application, we're going to be working with pre-release builds where our interface and app features will be changing quite often. We'll find ourselves working on an interface, throwing images or new text into an app to test, and then we'll probably make a few more changes and repeat this process.
It will be useful to take screenshots of our work in progress to email over for viewing on a larger monitor or to send to a friend or project teammate.
In this recipe, we'll learn how to quickly take and email screenshots of an application.
For this application, we'll only need our iOS device. We may also want the charging and syncing connection cable that game with our device to sync images with a computer if this is desirable.
It doesn't matter if we're using an iPhone, iPod touch, or iPad, as the process for taking a screenshot is the same on all devices. Let's take a look at the simple process:
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.
In Photos, we can send or upload the image however we see fit and then use this screenshot to help improve our interface further.
Apple has designed a simple, intuitive way to take a screenshot of any screen in iOS. The problem is, there is little obvious instruction on how to actually perform this function and most users are unaware that the feature even exists.
But once we're able to take screenshots, we'll find ourselves often taking quick screens as a way to quickly get our work in progress from the iPhone onto a traditional computer for further inspection.
The guidelines placed upon developers by Apple have been a hot topic of debate since the App Store first opened in 2007. For over two years, applications were rejected from the store with a vague explanation as to what was or was not acceptable for sale within Apple's walled garden.
Luckily, Apple has been much more open in recent history with regards to what is allowed in the App Store. Many common reasons for rejection involve problems with an app's user interface, so it is important for designers to understand why rules are in place so that a costly app rejection can be avoided.
Apple provides two important documents to help designers keep applications from being rejected. We should take the time to download and study these documents before sending off our application to Apple. The first document is called the iPhone User Interface Guidelines, and this file can be found in its most up to date version on the iOS Dev Center. This detailed document offers a bit of detail and reasoning as to why it is important that iOS interface elements should behave correctly in every application.
Next, we should become familiar with the App Store Review Guidelines document that can also be found in the iOS Dev Center portal. These guidelines were first published in September 2010 as a way to offer explanation of the rules and regulations for approval into the App Store reviewers.
Once we've read both of these documents, we're ready to start glancing over our application user interface to make sure that we abide by all App Store regulations.
Keeping within Apple's requirements isn't difficult so long as we keep focused on the requirements and prepare accordingly. Here are a few steps to help keep our app away from rejection:
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.
With these tips in mind, we'll be less likely to cross the line and violate Apple's terms of service. Rejection can be costly, so we'll want to guarantee that we don't keep our app from approval because of poor interface decisions.
Apple's strict polices may annoy pundits who wish the App Store was more open, but the current plans in place are set to help developers achieve greater success. By making every developer comply with specific UI and functional standards, Apple is ensuring a certain level of quality that builds consumer confidence with applications in the App Store. Once users trust that an app will work as advertised, they will be more willing to buy apps in the future, which will increase the revenue stream for all developers.
When reading Apple guidelines or blog posts about rejection, it can often appear as if Apple discourages innovation and unique interface design. In practice, this is untrue, with Apple offering yearly awards for exceptional app designs that are anything but ordinary.
For an example of exceptional design, check out Apple's web page for their yearly WWDC Design Awards http://developer.apple.com/wwdc/ada/. Design Award winners typically offer a great example of how we can transform standard interface elements into an exceptional user experience, all while remaining within App Store rules and regulations.
To help developers better understand application rejection, Apple has created the Resolution Center within iTunes Connect.
Note
iTunes Connect is the online web portal where we'll submit and make changes to app binaries. If we want to change the price or availability of our app, we'll head here.
The Resolution Center offers explanations as to why the app was rejected, along with suggestions as to how the application can be modified to comply with Apple policies.
