iOS Technology Usage Guidelines

Routing

In iOS 6 and later, Maps displays a list of routing apps—including apps installed on the device and in the App Store—when people want transit information for a route.

A routing app provides information about transit options for the currently selected route. People expect routing apps to be quick, easy to use, and—above all—accurate. Following the guidelines in this section helps you give users transit information they can trust and a user experience they appreciate.

Deliver the functionality your app promises. When people see your app in the transit list, they assume that it can help them reach their destination. But if your app can’t provide information about the selected route—or it doesn’t include the type of transit it appears to include—people are unlikely to give it a second chance. It’s essential to represent your app’s capabilities accurately; otherwise, your app can look like it’s intentionally misleading users.

There are two main ways you can give users confidence in your routing app:

• Define the geographic regions you support as precisely as possible. For example, if your app helps people get information about bus routes in Paris, your supported region should be Paris, not Île-de-France, and not France.

• Be specific about the types of transit that you support. For example, if you specialize in subway information, don’t imply that you provide information about all rail-based transit types.

Streamline the UI for ease of use. Ease of use is especially important for routing apps because people tend to use them under challenging conditions—such as in bright sunlight or in the dim interior of a train, on a bumpy ride, and when they’re in a hurry. Make sure that your text is easy to read in any light and that buttons are easy to tap accurately even when the ride is not smooth.

Focus on the route. Although auxiliary information can be useful, your app should focus on giving users step-by-step directions they can follow to their destination. In particular, you want users to know which step they’re in and how to get to the next step. You can provide additional data—such as timetables and system maps—but don’t make this data more prominent than the transit information.

Provide information for every step of a route. People should never feel abandoned by your app. But even when you accurately report your supported region, you can’t assume that users are already at the first transit stop in a route, or that the last transit stop is at the same location as their destination. To handle this situation, first examine the distances at the beginning and end of the route. If the distances are short enough, provide walking directions from the user’s current location to the first transit stop and from the last transit stop to the user’s final destination. If walking is not a reasonable choice, try to describe the user’s other options. If necessary, you can give users a way to open Maps to get walking or driving directions for these portions of the route.

When users transition to your app from Maps, don’t ask them to reenter information. If users are coming from Maps, you already know the start and end points of the route they’re interested in, so you can present the appropriate transit information as soon as your app opens. If users start your app from the Home screen, provide an easy way for them to enter route details.

Display transit information both graphically and textually. A map view helps people see their complete route in a larger, physical context; a list of steps helps people focus on the actions they must take to arrive at their destination. It’s best when you support both of these tasks and make it easy for users to switch between them.

When your app is chosen from the transit list, it works well to start by displaying the complete route—including walking paths to and from the transit stops, if appropriate—in a map view. A map view gives users an overview of the various steps in their journey and shows them how their route fits into the surrounding geographical area.

Enrich map views with additional information. People expect the maps in your app to behave similarly to other maps they’ve used. In addition to letting users zoom and pan, you should display annotations that give users the information they need. For example, you could display pins that represent the user’s current location, the destination, and transfers or points of interest along the way. Be sure to avoid displaying only a single pin, because it’s hard for users to tell what it represents if there’s no additional context. For more information about using map views in your app, see “Map View.”

As much as possible, integrate static maps—such as a subway system map—with a map view. A good way to do this is to overlay the static image on the map view so that users can see how their route and their current location relate to the larger transit system.

Give users different ways to sort multiple transit options. Lots of factors influence people’s transit decisions—such as time of day, weather, and how much they’re carrying—so it’s important to make it easy to compare transit options. For example, you could let users sort transit options by start or end time, amount of walking required, number of stops along the way, or number of transfers or different transit types required. Regardless of the order in which you display multiple transit options, make sure that users can instantly distinguish the differences between the options.

Consider using push notifications to give people important information about their route. As much as possible, let people know when transit information changes, so that they can adjust their plans. For example, if a train is delayed or a bus line is temporarily unavailable people might need to choose a different route to their destination. And in a route that includes long stops between steps, people might appreciate being notified when their transport is about to depart for the next part of the journey.

Passbook

The Passbook app helps people view and manage passes, which are digital representations of physical items such as boarding passes, coupons, membership cards, and tickets. In your app, you can create a pass, distribute it to users, and update it when things change.

The Pass Kit framework makes it easy to use your custom content to assemble a pass and to access a pass when it’s in the user’s pass library. (To learn about the key concepts of Passbook technology and how to use the Pass Kit APIs in your app, see Passbook Programming Guide.) The following guidelines can help you create a pass that people appreciate having in their pass library and enjoy using.

As much as possible, avoid simply reproducing an existing physical pass. Passbook has an established design aesthetic and passes that coordinate with this aesthetic tend to look best. Instead of replicating the appearance of a physical item, take this opportunity to design a clean, simple pass that follows the form and function of Passbook.

Be selective about the information you put on the front of a pass. People expect to be able to glance at a pass and quickly get the information they need, so the front of a pass should be uncluttered and easy to read. If there’s additional information that you think people might need, it’s better to put it on the back of the pass than to squeeze it onto the front.

In general, avoid using a plain white background. A pass tends to look best when its background is a vivid, solid color or displays an image that uses strong, vibrant colors. As you design the background, always make sure that it doesn’t interfere with the readability of the content.

Use the logo text field for your company name. Text in the logo text field is rendered in a consistent font on all passes. To avoid clashing with other passes in the user’s pass library, it’s recommended that you enter text into the logo text field instead of using a custom font.

Use a white company logo. The logo image is placed in the upper-left corner of the pass, next to your company name. For best results, supply a white, monochrome version of your logo that doesn’t include text. If you want to engrave the logo so that it matches the rendered logo text, add a black drop shadow with a 1 pixel y offset, a 1 pixel blur, and 35% opacity.

Use a rectangular barcode when possible. Because of the layout of a pass, a rectangular barcode—such as PDF417—tends to look better than a square barcode. As shown below on the right, a square barcode creates empty gutters on both sides and can vertically crowd the fields above and below it.

Optimize images for performance. Because users often receive passes via email or Safari, it’s important to make downloads as fast as possible. To improve the user experience, use the smallest image files that achieve the desired visual appearance.

Enhance the utility of a pass by updating it when appropriate. Even though a pass represents a physical item that doesn’t typically change, your digital pass can provide a better experience by reflecting real-world events. For example, you can update an airline boarding pass when a flight is delayed so that people always get current information when they check the pass.

Social Media

People expect to have access to their favorite social media accounts regardless of their current context. The following guidelines help you integrate social media interactions into your app in ways that people appreciate.

Give users a convenient way to compose a post without leaving your app. As much as possible, you want to integrate social media support into your app so users can post content to their account without switching to another app to do so. The Social framework provides a compose view controller that allows you to present users with a view in which they can edit a post. Optionally, you can prepopulate the compose view with custom content before you present it to users for editing (after you present the view to users, only they can edit the content). To learn about the programming interfaces of the Social framework—including the SLComposeViewController class—see Social Framework Reference.

When possible, avoid asking users to sign into a social media account. The Social framework works with the Accounts framework to support a single sign-on model, so you can get authorization to access the user’s account without asking them to reauthenticate. If the user hasn’t already signed into an account, you can present UI that allows them to do so.

Consider using an activity view controller to help users choose one of their social media accounts. By default, an activity view controller—that is, a UIActivityViewController object—lists several system-provided services that act upon the currently selected content, including sending the content via Mail or Messages and posting the content to social media accounts. When you use an activity view controller, you don’t have to provide a custom service that interacts with a social media account and you benefit from the user’s familiarity with the Share button that reveals the list of services. For guidelines on how to use an activity view controller in your app, see “Activity View Controller.”

iCloud

iCloud lets people access the content they care about regardless of which device they’re currently using. When you integrate iCloud into your app, users can use different instances of your app on different devices to view and edit their personal content without performing explicit synchronization. To provide this user experience, it’s likely that you’ll need to reexamine the ways in which you store, access, and present information—especially user-created content—in your app. To learn how to enable iCloud in your app, see iCloud Design Guide.

A fundamental aspect of the iCloud user experience is transparency: Ideally, users don’t need to know where their content is located and they should seldom have to think about which version of the content they’re currently viewing. The following guidelines can help you give users the iCloud experience they’re expecting.

If appropriate, make it easy for users to enable iCloud for your app. On their iOS devices, users log into their iCloud account in iCloud Settings, and for the most part, they expect their apps to work with iCloud automatically. But if you think users might want to choose whether to use iCloud with your app, you can provide a simple option that they can set when they open your app for the first time. In most cases, this option should provide a choice between using iCloud with all the content that users access in your app or not at all.

Respect the user’s iCloud space. It’s important to remember that iCloud is a finite resource for which users pay. You should use iCloud for storing information that users create and understand, and avoid using it to store app resources or content that you can regenerate. Also, note that when the user’s iCloud account is active, iCloud automatically backs up the contents of your app’s Documents folder. To avoid using up too much of the user’s space, it’s best to be picky about the content you place in the Documents folder.

Avoid asking users to choose which documents to store in iCloud. Typically, users expect all the content they care about to be available via iCloud. Most users don’t need to manage the storage of individual documents, so you shouldn’t assume that your app needs to support this experience. To provide a good user experience, you might want to rearchitect the way your app handles and exposes content so that you can perform more file-management tasks for the user.

Determine which types of information to store in iCloud. In addition to storing user-created documents and other content, you can also store small amounts of data such as the user’s current state in your app or their preferences. To store this type of information you use iCloud key-value storage. For example, if people use your app to read a magazine, you might use iCloud key-value storage to store the last page they viewed so that when they reopen the issue on a different device, they can continue reading from where they left off.

If you use iCloud key-value storage to store preferences, be sure that the preferences are ones that users are likely to want to have applied to all their devices. For example, some preferences are more useful in a work environment than they are in a home environment. In some cases, it can make sense to store preferences on your app’s server, instead of in the user’s iCloud account, so that the preferences are available regardless of whether iCloud is enabled.

Make sure that your app behaves reasonably when iCloud is unavailable. For example, if users log out of their iCloud account, turn off iCloud usage for your app, or enter Airplane mode, iCloud becomes unavailable. In these cases, users performed an action that turned off access to iCloud, so your app does not need to tell them about it. However, it can be appropriate to show users that the changes they make will not be visible on their other devices until they restore access to iCloud.

Avoid giving users the option to create a "local” document. Regardless of whether you support iCloud in your app, you should not encourage users to think in terms of a device-specific file system. Instead, you want users to focus on the pervasive availability of their content through iCloud.

When appropriate, update content automatically. It’s best when users don’t have to take any action to ensure that they’re accessing the most up-to-date content in your app. However, you need to balance this experience with respect for the user’s device space and bandwidth constraints. If your users work with very large documents, it can be appropriate to give them control over whether to download an update from iCloud. If you need to do this, design a way to indicate that a more recent version of the document is available in iCloud. When the user chooses to update the document, be sure to provide subtle feedback if the download takes more than a few seconds.

Warn users about the consequences of deleting a document. When a user deletes a document in an iCloud-enabled app, the document is removed from the user’s iCloud account and all other devices. It’s appropriate to display an alert that describes this result and to get confirmation before you perform the deletion.

Tell users about conflicts as soon as possible, but only when necessary. Using the iCloud programming interfaces, you should be able to resolve most conflicts between different versions of a document without involving the user. In cases where this is not possible, make sure that you detect conflicts as soon as possible so that you can help users avoid wasting time on the wrong version of their content. You need to design an unobtrusive way to show users that a conflict exists; then, make it easy for users to differentiate between versions and make a decision.

Be sure to include the user’s iCloud content in searches. Users with iCloud accounts tend to think of their content as being universally available, and they expect search results to reflect this perspective. If your app allows people to search their content, make sure you use the appropriate APIs to extend search to their iCloud accounts. (To learn how to search content in iCloud, see “Incorporating Search into Your Infrastructure” in iOS App Programming Guide.)

In-App Purchase

In-App Purchase lets people buy digital products within your app. For example, they might:

• Upgrade a basic version of an app to a premium version

• Renew a subscription for new monthly content

• Purchase virtual items, such as a new level or weapon in a game

• Buy and download new books

You use the Store Kit framework to embed a store in your app and support In-App Purchase. When a user makes a purchase, Store Kit connects to the App Store to securely process the payment and then notifies your app so that it can provide the purchased item.

The following guidelines can help you design a purchasing experience that users appreciate.

Elegantly integrate the store experience into your app. When presenting products and handling user transactions, create an experience that feels at home in your app. You don’t want users to think that they’ve entered a different app when they visit your store.

Use simple, succinct titles and descriptions. It’s best when people can scan a set of items and quickly find the ones they’re interested in. When you use plain, direct language and titles that don’t truncate or wrap, it’s easier for people to understand the items you’re offering.

Don’t alter the default confirmation alert. When users buy a product, Store Kit presents a confirmation alert (shown above). You shouldn’t modify this alert because it helps users avoid accidental purchases.

Game Center

Game Center lets people play games, organize online multiplayer games, and more. Players use the built-in Game Center app to sign in to an account, discover new games, add new friends, and browse leaderboards and achievements.

As a game developer, you use the Game Kit APIs to post scores and achievements to the Game Center service, display leaderboards in the game UI, and help users find other players. To learn how to integrate Game Center into your app, see Game Center Programming Guide.

The following guidelines can help you give people a great Game Center experience in your app.

Don’t create custom UI that prompts users to sign into Game Center. When people start your Game Center-enabled app—and they’re not already signed into Game Center on their device—the system automatically prompts them to sign in. Displaying custom sign-in UI is unnecessary and might confuse users.

In general, use the standard Game Center UI. In rare cases, it might make sense for a game to customize the Game Center UI, but doing so risks confusing people. The standard Game Center UI—which is familiar to both iOS and OS X users—promotes the sense of belonging to a larger gaming community.

Give users the ability to turn off voice chat. Some users might not want voice chat to be on automatically when they start your game, and most users appreciate the ability to turn off voice chat in certain situations.

Multitasking

Multitasking allows people to switch quickly among recently used apps. To support this experience, multitasking allows an app to enter a suspended state in the background when users switch away from it. When users switch back to the app, the app can resume quickly because it doesn’t have to reload its UI. People use the multitasking bar (shown here below the iPhone Calendar app) to choose a recently used app.

Thriving in a multitasking environment hinges on achieving a harmonious coexistence with other apps on the device. At a high level, this means that all apps should:

• Handle interruptions or audio from other apps gracefully

• Stop and restart—that is, transition to and from the background—quickly and smoothly

• Behave responsibly when not in the foreground

The following specific guidelines help your app succeed in the multitasking environment.

Be prepared for interruptions, and be ready to resume. Multitasking increases the probability that a background app will interrupt your app. Other features, such as the presence of ads and faster app-switching, can also cause more frequent interruptions. The more quickly and precisely you can save the current state of your app, the faster people can relaunch it and continue from where they left off. To give users a seamless restart experience, take advantage of UIKit’s state preservation and restoration functionality (for more information, see “State Preservation and Restoration”).

Make sure your UI can handle the double-high status bar. The double-high status bar appears during events such as in-progress phone calls, audio recording, and tethering. In unprepared apps the extra height of this bar can cause layout problems. For example, the UI can become pushed down or covered. In a multitasking environment, it’s especially important to be able to handle the double-high status bar properly because there are likely to be more apps that can cause it to appear. You can trigger the double-high status bar during testing to help you find and correct any views that don’t handle it well. (To do this using iOS Simulator, choose Hardware > Toggle In-Call Status Bar.)

Be ready to pause activities that require people’s attention or active participation. For example, if your app is a game or a media-viewing app, make sure your users don’t miss any content or events when they switch away from your app. When people switch back to a game or media viewer, they want to continue the experience as if they’d never left it.

Ensure that your audio behaves appropriately. Multitasking makes it more likely that other media activity is occurring while your app is running. It also makes it more likely that your audio will have to pause and resume to handle interruptions. For specific guidelines that help you make sure your audio meets people’s expectations and coexists properly with other audio on the device, see “Sound.”

Use local notifications sparingly. An app can arrange for local notifications to be sent at specific times, whether the app is suspended, running in the background, or not running at all. For the best user experience, avoid pestering people with too many notifications, and follow the guidelines for creating notification content described in “Notification Center.”

When appropriate, finish user-initiated tasks in the background. When people initiate a task, they usually expect it to finish even if they switch away from your app. If your app is in the middle of performing a user-initiated task that does not require additional user interaction, you should complete it in the background before suspending.

Notification Center

Notification Center gives users a single, convenient place in which to view notifications from their apps. Users appreciate the unobtrusive interface of Notification Center and they value the ability to customize the way each app can present its notifications.

Notification Center uses a sectioned list to display recent notification items from the apps that users are interested in. In addition to notifications, users can also choose to see weather and stock market information in Notification Center.

iOS apps can use local or push notifications to let people know when interesting things happen, such as:

• A message has arrived

• An event is about to occur

• New data is available for download

• The status of something has changed

A local notification is scheduled by an app and delivered by iOS on the same device, regardless of whether the app is currently running in the foreground. For example, a calendar or to-do app can schedule a local notification to alert people of an upcoming meeting or due date.

A push notification is sent by an app’s remote server to the Apple Push Notification service, which pushes the notification to all devices that have the app installed. For example, a game that a user can play against remote opponents can update all players with the latest move.

You can still receive local and push notifications when your app is running in the foreground, but you pass the information to your users in an app-specific way.

iOS apps that support local or push notifications can participate in Notification Center in various ways, depending on the user’s preferences. To ensure that users can customize their notification experience, you should support as many as possible of the following notification styles:

• Banner

• Alert

• Badge

• Sound

A banner is a small translucent view that appears onscreen and then disappears after a few seconds. In addition to your notification message, iOS displays the small version of your app icon in a banner, so that people can see at a glance which app is notifying them (to learn more about the small app icon, see “Small Icons”).

An alert is a standard alert view that appears onscreen and requires user interaction to dismiss. You supply the notification message and, optionally, a title for the action button in the alert. You have no control over the background appearance of the alert or the buttons.

A badge is a small red oval that displays the number of pending notification items (a badge appears over the upper-right corner of an app’s icon). You have no control over the size or color of the badge.

A custom or system-provided sound can accompany any of the other three notification delivery styles.

As you design the content that your notifications can deliver, be sure to observe the following guidelines.

Keep badge contents up to date. It’s especially important to update the badge as soon as users have attended to the new information, so that they don’t think additional notifications have arrived. Note that setting the badge contents to zero also removes the related notification items from Notification Center.

Don’t send multiple notifications for the same event. Users can attend to notification items when they choose; the items don’t disappear until users handle them in some way. If you send multiple notifications for the same event, you fill up the Notification Center list and users are likely to turn off notifications from your app.

Provide a custom message that does not include your app name. Your custom message is displayed in alerts and banners, and in Notification Center list items. You should not include your app’s name in your custom message because iOS automatically displays the name with your message.

To be useful, a local or push notification message should:

• Focus on the information, not user actions. Avoid telling people which alert button to tap or how to open your app.

• Be short enough to display on one or two lines. Long messages are difficult for users to read quickly, and they can force alerts to scroll.

• Use sentence-style capitalization and appropriate ending punctuation. When possible, use a complete sentence.

Optionally, provide a custom title for the action button in an alert. An alert can contain one or two buttons. In a two-button alert, the Close button is on the left and the action button (titled View by default) is on the right. If you specify one button, the alert displays an OK button.

Tapping the action button dismisses the alert and launches your app simultaneously. Tapping either the Close button or the OK button dismisses the alert without opening your app.

If you want to use a custom title for the action button, be sure to create a title that clearly describes the action that occurs when your app launches. For example, a game might use the title Play to indicate that tapping the button opens the app to a place where the user can take their turn. Make sure the title:

• Uses title-style capitalization

• Is short enough to fit in the button without truncation (be sure to test the length of localized titles, too)

Provide a sound that users can choose to hear when a notification arrives. A sound can get people’s attention when they’re not looking at the device screen. Users might want to enable sounds when they’re expecting a notification that they consider important. For example, a calendar app might play a sound with an alert that reminds people about an imminent event. Or, a collaborative task management app might play a sound with a badge update to signal that a remote colleague has completed an assignment.

You can supply a custom sound, or you can use a built-in alert sound. If you create a custom sound, be sure it’s short, distinctive, and professionally produced. (To learn about the technical requirements for this sound, see “Preparing Custom Alert Sounds” in Local and Push Notification Programming Guide.) Note that you can’t programmatically cause the device to vibrate when a notification is delivered, because the user has control over whether alerts are accompanied by vibration.

Optionally, provide a launch image. In addition to displaying your existing launch images, you can supply a different launch image to display when people start your app in response to a notification. For example, a game might specify a launch image that’s similar to a screen within the game, instead of an image that’s similar to the opening menu screen. If you don’t supply this launch image, iOS displays either the previous snapshot or one of your other launch images. (To learn how to create a launch image, see “Launch Images.”)

Printing

In iOS 4.2 and later, and on devices that support multitasking, users can wirelessly print content from your app. You can take advantage of built-in support for printing images and PDF content, or you can use printing-specific programming interfaces to do custom formatting and rendering. iOS handles printer discovery and the scheduling and execution of print jobs on the selected printer.

Typically, users tap the standard Share button in your app when they want to print something. When they choose the Print item in the view that appears, they can then select a printer, set available printing options, and tap the Print button to start the job. On iPhone, this view appears in an action sheet that slides up from the bottom of the screen; on iPad, the view appears in a popover that emerges from the button.

Users can check on the print job they requested in the Print Center app, which is a background system app that is available only while a print job is in progress. In Print Center, users can view the current print queue, get details about a specific print job, and even cancel the job.

You can support basic printing in your app with comparatively little additional code (to learn about adding print support to your code, see Drawing and Printing Guide for iOS). To ensure that users appreciate the printing experience in your app, follow these guidelines:

Use the system-provided Share button. Users are familiar with the meaning and behavior of this button, so it’s a good idea to use it when possible. The main exception to this is if your app does not contain a toolbar or navigation bar. When this is the case, you need to design a custom print button that can appear in the main UI of your app, because the Share button can only be used in a toolbar or navigation bar.

Display the Print item when printing is a primary function in the current context. If printing is inappropriate in the current context, or if users are not likely to want to print, don’t include the Print item in the view revealed by the Share button.

If appropriate, provide additional printing options to users. For example, you might allow users to choose a page range or to request multiple copies.

Don’t display print-specific UI if users can’t print. Be sure to check whether the user’s device supports printing before you display UI that offers printing as an option. To learn how to do this in your code, see UIPrintInteractionController Class Reference.

iAd Rich Media Ads

In iOS 4.0 and later, you can allow advertisements to display within your app and you can receive revenue when users see or interact with them. It’s essential that you plan when and how to integrate ads with your UI so that people are motivated to view them without being distracted from your app.

You host an ad served by the iAd Network in a specific view in your UI. Initially, this view contains the ad’s banner, which functions as the entrance into the full iAd experience. When people tap the banner, the ad performs a preprogrammed action, such as playing a movie, displaying interactive content, or launching Safari to open a webpage. The action can display content that covers your UI or it might cause your app to transition to the background.

There are three types of banners that you can display in your app: standard, medium rectangle, and full screen. All types of banners serve the same purpose—that is, to usher users into the ad—but they differ in their appearance and functionality.

A standard banner takes up a small area of the screen and is often visible for as long as the screen is visible. You choose the app screens that should display a standard banner and make room for the banner view in the layout.

All iOS apps running in iOS 4.0 and later can display standard banners. You use a view provided by the ADBannerView class to contain a standard banner in your app.

A medium rectangle banner is similar in behavior to a standard banner and—as with standard banners—you choose where a medium rectangle banner should be displayed. Medium rectangle banners are available only in iPad apps running in iOS 6.0 and later. You use a view provided by the ADBannerView class to contain a medium rectangle banner in your app.

A full screen banner occupies most or all of the screen and is usually visible at specific times during the app flow or in specific locations. You choose whether to display the banner modally or as a separate page within scrollable content.

Full screen banners are available only in iPad apps running in iOS 4.3 and later. You use a view provided by the ADInterstitialAd class to contain a full screen banner in your app.

All banner types appear inside the iAd frame, which displays the iAd mark in the lower-right corner. The iAd frame has been designed to look best when it is anchored to the bottom edge of your app screens.

The dimensions of the standard banner view you place in the app UI vary, according to the device and the orientation.

The dimensions of a medium rectangle banner view don’t vary with changes in device orientation.

The overall dimensions of a full screen banner view can vary with changes in device orientation, but the height can vary further with the presence or absence of iOS bars (such as toolbars and tab bars) in your app’s UI. The width of a full screen banner is always the full width of the iPad screen.

To ensure seamless integration with banner ads and to provide the best user experience, follow these guidelines:

Place a standard banner view at or near the bottom of the screen. This placement differs slightly, depending on whether there is a bar on the bottom of the screen and if so, the kind of bar.

If there are no bars at the bottom of the screen, put the standard banner view at the bottom edge of the screen (iPod touch shown).

If there are no bars at all, again put the standard banner view at the bottom edge of the screen (iPod touch shown).

If there is a toolbar or tab bar, put the standard banner view directly above the toolbar or tab bar (iPod touch shown).

Place a medium rectangle banner view where it doesn’t interfere with the user’s content. As with the standard banner view, the medium banner view looks best at or near the bottom of the screen. Putting the banner near the bottom of the screen also increases the likelihood that it won’t get in people’s way.

Present a full screen banner modally when there are interludes in the user experience. If there are natural breaks or context changes in the flow of your iPad app, the modal presentation style can be appropriate. When you present a full screen banner modally (by using presentFromViewController:), the user must either enter the ad or dismiss it. For this reason, it’s a good idea to use the modal presentation style when users are expecting a change in experience, such as after they complete a task.

Be sure to reveal and close a modal full screen banner view in a way that makes sense in your app. For example, a game might use fade-in and fade-out animations to reveal and close the banner.

As you can see below, a modally presented full screen banner completely covers the app UI and includes the iAd close button in the upper-left corner.

Present a full screen banner nonmodally when there are transitions between app views. If users experience your app by making frequent screen transitions, such as paging through a magazine or flicking through a gallery, the nonmodal presentation style can be appropriate. When you present a full screen banner nonmodally (by using presentInView:), you can preserve the bars in your UI so that users can use app controls to move past or return to the ad. As with all banners, a full screen banner launches the iAd experience when a user taps it, but your app can respond to other gestures within the banner area (such as drag or swipe) if appropriate.

Be sure to use appropriate animations to reveal and hide a nonmodal full screen banner view. For example, a magazine reader app would probably present a banner using the same page-turn animation it uses to reveal other content pages.

The nonmodally presented full screen banner shown below is displayed between a navigation bar and a toolbar. However, it’s up to you to choose which bars should be present.

Ensure that all banners appear when and where it makes sense in your app. People are more likely to enter the iAd experience when they don’t feel like they’re interrupting their workflow to do so. This is especially important for immersive apps such as games: You don’t want to place banner views where they will conflict with playing a game.

Avoid displaying banners on screens that users are likely to see only briefly. If your app includes screens that users move through quickly as they drill down or navigate to the content they care about, it’s best to avoid displaying banners on these screens. Users are more likely to tap a banner when it stays onscreen for more than a second or two.

As much as possible, display banner ads in both orientations. It’s best when users don’t have to change the orientation of the device to switch between using your app and viewing an ad. Also, supporting both orientations allows you to accept a wider range of advertisements. To learn how to make sure a banner view responds to orientation changes, see iAd Programming Guide.

Don’t allow standard or medium rectangle banners to scroll off the screen. If your app displays scrolling content in the screen, make sure the banner view remains anchored in its position.

While people view or interact with ads, pause activities that require their attention or interaction. When people choose to view an ad, they don’t want to feel that they’re missing events in your app, and they don’t want your app to interrupt the ad experience. A good rule of thumb is to pause the same activities you would pause when your app transitions to the background.

Don’t stop an ad, except in rare circumstances. In general, your app continues running and receiving events while users view and interact with ads, so it’s possible that an event will occur that urgently requires their immediate attention. However, there are very few scenarios that warrant the dismissal of an in-progress ad. One possibility is with an app that provides Voice over Internet Protocol (VoIP) service. In such an app, it probably makes sense to cancel a running ad when an incoming call arrives.

Location Services and Data Privacy

Location Services allows apps to determine people’s approximate location geographically, the direction they’re pointing their device, and the direction in which they’re moving. In iOS 6.0 and later, other system services—such as Contacts, Calendar, Reminders, and Photo Library—also allow apps to access the data people store in them.

Although people appreciate the convenience of using an app that already knows a lot about them, they also expect to have the option of keeping their data private. For example, people like being able to automatically tag content with their physical location or find friends that are currently nearby, but they also want to be able to disable such features when they don’t choose to share their location with others. (To learn more about how to make your app location-aware, see Location Awareness Programming Guide.)

In iOS 6.0 and later, the system displays an alert that asks users if they want to permit an app to access their personal data. For example, when Location Services is on and a user opens Compass for the first time, the following alert appears:

The following guidelines can help you ask for user data in ways that help people feel comfortable.

Make sure users understand why they’re being asked to share their personal data. It’s natural for people to be suspicious of a request for their personal information if they don’t see an obvious need for it. To avoid making users uncomfortable, make sure the alert appears only when they attempt to use a feature that clearly needs to know their information. For example, people can use Maps when Location Services is off, but they see an alert when they access the feature that finds and tracks their current location.

Describe why your app needs the information, if it’s not obvious. You can provide text that appears in the alert, below a system-provided title such as ““App Name” Would Like to Access Your Contacts”. You want this text to be specific and polite so that people understand why you’re asking for access to their information and don’t feel pressured. Your reason text should:

• Not include your app name. The system-provided alert title already includes your app name.

• Clearly describe why your app needs the data. If appropriate, you might also explain ways in which your app will not use the data.

• Use user-centric terminology and be localizable.

• Be as short as possible, while still being easy to understand. As much as possible, avoid supplying more than one sentence.

• Use sentence-style capitalization. (Sentence-style capitalization means that the first word is capitalized, and the rest of the words are lowercase unless they are proper nouns or proper adjectives.)

Ask permission at app startup only if your app can’t perform its primary function without the user’s data. People will not be bothered by this if it’s obvious that the main function of your app depends on knowing their personal information.

Avoid making programmatic calls that trigger the alert before the user actually selects the feature that needs the data. This way, you avoid causing people to wonder why your app wants their personal information when they’re doing something that doesn’t appear to need it. (Note that getting the user’s Location Services preference does not trigger the alert.)

For location data, check the Location Services preference to avoid triggering the alert unnecessarily. You can use Core Location programming interfaces to get this setting (to learn how to do this, see Core Location Framework Reference). With this knowledge, you can trigger the alert as closely as possible to the feature that requires location information, or perhaps avoid an alert altogether.

Quick Look Document Preview

In iOS 4 and later, users can preview a document within your app, even if your app cannot open the document. For example, you might allow users to preview documents that they download from the web or receive from other sources. To learn more about how to support Quick Look document preview in your app, see Document Interaction Programming Topics for iOS.

Before users preview a document in your app, they can see information about the document in a custom view that you create. For example, after users download a document attached to an email message, Mail on iPad displays the document’s icon, title, and size in a custom view within the message. Users can tap this view to preview the document.

You can present a document preview in a new view in your app, or in a full-screen, modal view. The presentation method you choose depends on which device your app runs on.

On iPad, display a document preview modally. The large iPad screen is appropriate for displaying a document preview in an immersive environment that users can easily leave. The zoom transition is especially well-suited to reveal the preview.

On iPhone, display a document preview in a dedicated view, preferably a navigation view. Doing this allows users to navigate to and from the document preview without losing context in your app. Although it’s possible to display a document preview modally in an iPhone app, it’s not recommended. (Note that the zoom transition is not available on iPhone.)

Also, note that displaying a document preview in a navigation view allows Quick Look to place preview-specific navigation controls in the navigation bar. (If your view already contains a toolbar, Quick Look places the preview navigation controls in the toolbar, instead.)

Sound

iOS devices produce great sound that users appreciate. In your app, sound might be an essential part of the user experience or provide only incidental enhancement. Regardless of the role that sound plays in your app, you need to know how users expect sound to behave and how to meet those expectations.

VoiceOver and Accessibility

VoiceOver is designed to increase accessibility for blind and low-vision users, and for users with certain learning challenges.

To make sure VoiceOver users can use your app, you might need to supply some descriptive information about the views and controls in your user interface. Supporting VoiceOver does not require you to change the visual design of your UI in any way.

When you use standard UI elements in a completely standard way, you have little (if any) additional work to do. The more custom your UI is, the more custom information you need to provide so that VoiceOver can accurately describe your app.

Making your iOS app accessible to VoiceOver users can increase your user base and help you enter new markets. Supporting VoiceOver can also help you address accessibility guidelines created by various governing bodies.

Edit Menu

Users can reveal an edit menu to perform operations such as Cut, Paste, and Select in a text view, web view, or image view.

You can adjust some of the behaviors of the menu to give users more control over the content in your app. For example, you can:

• Specify which of the standard menu commands are appropriate for the current context

• Determine the position of the menu before it appears so that you can prevent important parts of your app’s UI from being obscured

• Define the object that is selected by default when users double-tap to reveal the menu

You can't change the color or shape of the menu itself.

For information on how to implement these behaviors in code, see “Copy and Paste Operations” in iOS App Programming Guide.

To ensure that the edit menu behaves as users expect in your app, you should:

Display commands that make sense in the current context. For example, if nothing is selected, the menu should not contain Copy or Cut because these commands act on a selection. Similarly, if something is selected, the menu should not contain Select. If you support an edit menu in a custom view, you’re responsible for making sure that the commands the menu displays are appropriate for the current context.

Accommodate the menu display in your layout. iOS displays the edit menu above or below the insertion point or selection, depending on available space, and places the menu pointer so that users can see how the menu commands relate to the content. You can programmatically determine the position of the menu before it appears so that you can prevent important parts of your UI from being obscured, if necessary.

Support both gestures that people can use to invoke the menu. Although the touch and hold gesture is the primary way users reveal the edit menu, they can also double-tap a word in a text view to select the word and reveal the menu at the same time. If you support the menu in a custom view, be sure to respond to both gestures. In addition, you can define the object that is selected by default when the user double taps.

Avoid creating a button in your UI that performs a command that’s available in the edit menu. For example, it’s better to allow users to perform a copy operation using the edit menu than to provide a Copy button, because users will wonder why there are two ways to do the same thing in your app.

Consider enabling the selection of static text if it’s useful to the user. For example, a user might want to copy the caption of an image, but they’re not likely to want to copy the label of a tab item or a screen title, such as Accounts. In a text view, selection by word should be the default.

Don’t make button titles selectable. A selectable button title makes it difficult for users to reveal the edit menu without activating the button. In general, elements that behave as buttons don’t need to be selectable.

Combine support for undo and redo with your support of copy and paste. People often expect to be able to undo recent operations if they change their minds. Because the edit menu doesn’t require confirmation before its actions are performed, you should give users the opportunity to undo or redo these actions (to learn how to do this, see “Undo and Redo”).

In iOS 4 and later, you can provide custom, app-specific commands to display in the edit menu. The following example shows a menu that allows users to copy a style rather simply copy text.

Follow these guidelines if you need to create custom edit menu items.

Create edit menu items that edit, alter, or otherwise act directly upon the user’s selection. People expect the standard edit menu items to act upon text or objects within the current context, and it’s best when your custom menu items behave similarly.

List custom items together after all system-provided items. Don’t intersperse your custom items with the system-provided ones.

Keep the number of custom menu items reasonable. You don’t want to overwhelm your users with too many choices.

Use succinct names for your custom menu items and make sure the names precisely describe what the commands do. In general, item names should be verbs that describe the action to be performed. Although you should generally use a single capitalized word for an item name, use title-style capitalization if you must use a short phrase. (Briefly, title-style capitalization means to capitalize every word except articles, coordinating conjunctions, and prepositions of four or fewer letters.)

Undo and Redo

Users initiate an Undo operation by shaking the device, which displays an alert that allows them to:

• Undo what they just typed

• Redo previously undone typing

• Cancel the undo operation

You can support the Undo operation in a more general way in your app by specifying:

• The actions users can undo or redo

• The circumstances under which your app should interpret a shake event as the shake-to-undo gesture

• How many levels of undo to support

To learn how to implement this behavior in code, see Undo Architecture. If you support undo and redo in your app, follow these guidelines to provide a good user experience.

Supply brief descriptive phrases that tell users precisely what they’re undoing or redoing. iOS automatically supplies the strings “Undo “ and “Redo “ (including a space after the word) for the undo alert button titles, but you need to provide a word or two that describes the action users can undo or redo. For example, you might supply the text Delete Name or Address Change, to create button titles such as “Undo Delete Name” or “Redo Address Change.” (Note that the Cancel button in the alert cannot be changed or removed.)

Avoid supplying text that is too long. A button title that is too long is truncated and is difficult for users to decipher. And because this text is in a button title, use title-style capitalization and do not add punctuation.

Avoid overloading the shake gesture. Even though you can programmatically set when your app interprets a shake event as shake to undo, you run the risk of confusing users if they also use shake to perform a different action. Analyze user interaction in your app and avoid creating situations in which users can’t reliably predict the result of the shake gesture.

Use the system-provided Undo and Redo buttons only if undo and redo are fundamental tasks in your app. Remember that the shake gesture is the primary way users initiate undo and redo, and that it can be confusing to offer two different ways to perform the same task. If you decide it’s important to provide explicit, dedicated controls for undo and redo, you can place the system-provided buttons in the navigation bar. (To learn more about these buttons, see “Standard Buttons for Use in Toolbars and Navigation Bars.”)

Clearly relate undo and redo capability to the user’s immediate context, and not to an earlier context. Consider the context of the actions you allow to be undone or redone. In general, users expect their changes and actions to take effect immediately.

Keyboards and Input Views

If appropriate, you can design a custom input view to replace the system-provided onscreen keyboard. For example, Numbers on iPad provides an input view that’s designed to make entering dates and times easy and efficient.

If you provide a custom input view, be sure its function is obvious to people. Also, be sure to make the controls in your input view look tappable.

You can also provide a custom input accessory view, which is a separate view that appears above the keyboard (or your custom input view). For example, in some contexts, Numbers displays an input accessory view that allows users to perform standard or custom calculations on spreadsheet values.

In iOS 4.2 and later, you can use the standard keyboard click sound to provide audible feedback when people tap the custom controls in your input view. To learn how to enable this sound in your code, see the documentation for playInputClick in UIDevice Class Reference.