Human Interface Principles for iOS part V

iCloud Storage

iCloud storage helps people access the content they care about regardless of which device they’re currently using. When you support iCloud storage in your app, users can use different instances of your app on different devices to view and edit their content without performing explicit synchronization. To enable 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. For some tips on ways to structure your app so that it works well with iCloud, and to learn about the iCloud programming interfaces.

A fundamental aspect of the iCloud storage 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 provide this user experience in your app.

Respect the user’s iCloud account. It’s important to remember that iCloud storage is a finite resource for which users pay. You should use iCloud storage 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.

Determine which types of information to store in iCloud storage. In addition to documents and other user content, you can also store small amounts of key-value data in iCloud storage. For example, if your app helps people consume content (such as a book or a magazine), you might use iCloud storage to store the last page they viewed so that when they open the content on a different device, they can continue from where they left off.

If you store preferences in iCloud key-value storage, 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. Note that 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 available.

Make sure that your app behaves reasonably when iCloud storage is unavailable. For example, if users log out of their iCloud account, turn off iCloud usage for your app, or enter Airplane mode, iCloud storage becomes unavailable. In these cases, users performed an action that turned off access to iCloud storage, 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 storage.

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

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 storage. Your app should not require users to think about the availability of their content on a file-by-file basis. To provide the appropriate user experience, you might have to rearchitect the way your app handles and exposes content so that you can perform more file-management tasks for the user.

Avoid giving users the option to create a "local” document. Regardless of whether you support iCloud storage 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 storage. If you need to do this, design a way to indicate that a more recent version of the document is available for download. 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 app that uses iCloud storage, 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 storage 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 view. 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 storage, see “Incorporating Search into Your Infrastructure” in iOS App Programming Guide.)

Multitasking

Multitasking allows people to switch quickly among recently used applications, because apps can be suspended in the background when they are quit. A suspended app can resume quickly because it does not 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 applications on the device. At a high level, this means that all applications should:

• Handle interruptions or audio from other applications 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 application will interrupt your app. Other features, such as the presence of ads and faster application-switching, can also cause more frequent interruptions. The more quickly and precisely you can save the current state of your application, the faster people can relaunch it and continue from where they left off.
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 applications 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 applications 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 learn how to do this using iOS Simulator.

 

Be ready to pause activities that require people’s attention or active participation. For example, if your application is a game or a media-viewing application, make sure your users don’t miss any content or events when they switch away from your application. 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 application 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 application can arrange for local notifications to be sent at specific times, whether the application 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 conten.


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 application. If your application 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 applications 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 application 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 application 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.

Note: Apps that use local notifications can provide banners, alerts, badges, and sounds. But an app that uses push notifications instead of local notifications can provide only the notification types that correspond to the push categories for which the app is registered. For example, if a push-notification app registers for alerts only, users aren’t given the choice to receive badges or sounds when a notification arrives.

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.

Note: In general, a Notification Center item can display more of a notification message than a banner can. If necessary, iOS truncates your message so that it fits well in each notification delivery style; for best results, you should not truncate your message.

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 application 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 application 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)

Note: Your custom button title can also be displayed in the “slide to view” message people see when a notification arrives while the device is locked. When this happens, your custom title is automatically converted to lowercase and replaces the word “view” in the message.

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 is short, distinctive, and professionally produced. Note that you cannot 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.

Printing

In iOS 4.2 and later, and on devices that support multitasking, users can wirelessly print content from your application. 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 Action 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 application, 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 ensure that users appreciate the printing experience in your app, follow these guidelines:

Use the system-provided Action 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 Action 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 Action 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. 

iAd Rich Media Ads

In iOS 4.0 and later, you can allow advertisements to display within your application 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 application.

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 application to transition to the background.

There are two types of banners that you can display in your application: standard banners and full screen banners. Both types of banners serve the same purpose (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 full screen banner occupies most or all of the screen and is usually visible at specific times during the application 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.
Both 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.

Table 6-1  Standard banner view dimensions

Device	Portrait	Landscape
iPad	768 x 66 points	1024 x 66 points
iPhone	320 x 50 points	480 x 32 points

The overall dimensions of a full screen banner view can also 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.

Table 6-2  Full screen banner view dimensions

iPad orientation	Height range	Width
Portrait	911 points to 1024 points	768 points
Landscape	655 points to 768 points	1024 points

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).

 

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 application. 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 applications 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. 

Don’t allow a standard banner to scroll off the screen. If your app displays scrolling content in the screen, make sure the standard 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 application, 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 application 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 application that provides Voice over Internet Protocol (VoIP) service. In such an application, it probably makes sense to cancel a running ad when an incoming call arrives.

Note: Canceling an ad might adversely impact the kinds of advertisements your application can receive and the revenue you can collect.

Quick Look Document Preview

In iOS 4 and later, users can preview a document within your application, 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.

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-based 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.

Understand User Expectations

People can use device controls to affect sound, and they might use wired or wireless headsets and headphones. People also have various expectations for how their actions impact the sound they hear. Although you might find some of these expectations surprising, they all follow the principle of user control in that the user, not the device, decides when it’s appropriate to hear sound.

Users switch their devices to silent when they want to:

• Avoid being interrupted by unexpected sounds, such as phone ringtones and incoming message sounds
• Avoid hearing sounds that are the byproducts of user actions, such as keyboard or other feedback sounds, incidental sounds, or app startup sounds
• Avoid hearing game sounds that are not essential to using the game, such as incidental sounds and soundtracks

Note: People switch their devices to silent using either the Ring/Silent switch (on iPhone) or the Silent switch (on iPad).

For example, in a theater users switch their devices to silent to avoid bothering other people in the theater. In this situation, users still want to be able to use apps on their devices, but they don’t want to be surprised by sounds they don’t expect or explicitly request, such as ringtones or new message sounds.
The Ring/Silent (or Silent) switch does not silence sounds that result from user actions that are solely and explicitly intended to produce sound. For example:

• Media playback in a media-only app is not silenced because the media playback was explicitly requested by the user.
• A Clock alarm is not silenced because the alarm was explicitly set by the user.
• A sound clip in a language-learning app is not silenced because the user took explicit action to hear it.
• Conversation in an audio chat application is not silenced because the user started the app for the sole purpose of having an audio chat.

Users use the device’s volume buttons to adjust the volume of all sounds their devices can play, including songs, app sounds, and device sounds. Users can use the volume buttons to quiet any sound, regardless of the position of the Ring/Silent (or Silent) switch. Using the volume buttons to adjust an app’s currently playing audio also adjusts the overall system volume, with the exception of the ringer volume.

iPhone: Using the volume buttons when no audio is currently playing adjusts the ringer volume.

Users use headsets and headphones to hear sounds privately and to free their hands. Regardless of whether these accessories are wired or wireless, users have specific expectations for the user experience.
When users plug in a headset or headphones, or connect to a wireless audio device, they intend to continue listening to the current audio, but privately. For this reason, they expect an app that is currently playing audio to continue playing without pause.
When users unplug a headset or headphones, or disconnect from a wireless device (or the device goes out of range or turns off), they don’t want to automatically share what they’ve been listening to with others. For this reason, they expect an app that is currently playing audio to pause, allowing them to explicitly restart playback when they’re ready.

Define the Audio Behavior of Your App

If necessary, you can adjust relative, independent volume levels to produce the best mix in your app’s audio output. But the volume of the final audio output should always be governed by the system volume, whether it’s adjusted by the volume buttons or a volume slider. This means that control over an application’s audio output remains in users’ hands, where it belongs.

Ensure that your app can display the audio route picker, if appropriate. (An audio route is an electronic pathway for audio signals, such as from a device to headphone or from a device to speakers.) Even though people don’t physically plug in or unplug a wireless audio device, they still expect to be able to choose a different audio route. To handle this, iOS automatically displays a control that allows users to pick an output audio route (use the MPVolumeView class to allow the control to display in your app). Because choosing a different audio route is a user-initiated action, users expect currently playing audio to continue without pause.

If you need to display a volume slider, be sure to use the system-provided volume slider available when you use the MPVolumeView class. Note that when the currently active audio output device does not support volume control, the volume slider is replaced by the appropriate device name.

If your application produces only UI sound effects that are incidental to its functionality, use System Sound Services. System Sound Services is the iOS technology that produces alerts and UI sounds and invokes vibration; it is unsuitable for any other purpose. When you use System Sound Services to produce sound, you cannot influence how your audio interacts with audio on the device, or how it should respond to interruptions and changes in device configuration. For a sample project that demonstrates how to use this technology, see Audio UI Sounds (SysSound).

If sound plays an important role in your app, use Audio Session Services or the AVAudioSession class. These programming interfaces do not produce sound; instead, they help you express how your audio should interact with audio on the device and respond to interruptions and changes in device configuration. 

iPhone: No matter what technology you use to produce audio or how you define its behavior, the phone can always interrupt the currently running application. This is because no app should prevent people from receiving an incoming call.

In Audio Session Services, the audio session functions as an intermediary for audio between your application and the system. One of the most important facets of the audio session is the category, which defines the audio behavior of your application.

To realize the benefits of Audio Session Services and provide the audio experience users expect, you need to select the category that best describes the audio behavior of your application. This is the case whether your app plays only audio in the foreground or can also play audio in the background. Follow these guidelines as you make this selection:

• Select an audio session category based on its semantic meaning, not its precise set of behaviors. By selecting a category whose purpose is clear, you ensure that your application behaves according to users’ expectations. In addition, it gives your application the best chance of working properly if the exact set of behaviors is refined in the future.
• In rare cases, add a property to the audio session to modify a category’s standard behavior. A category’s standard behavior represents what most users expect, so you should consider carefully before you change that behavior. For example, you might add the ducking property to make sure your audio is louder than all other audio (except phone audio), if that’s what users expect from your app.
  
  
• Consider basing your category selection on the current audio environment of the device. This might make sense if, for example, users can use your app while listening to other audio instead of to your soundtrack. If you do this, be sure to avoid forcing users to stop listening to their music or make an explicit soundtrack choice when your app starts.
  
• In general, avoid changing categories while your application is running. The primary reason for changing the category is if your app needs to support recording and playback at different times. In this case, it can be better to switch between the Record category and the Playback category as needed, than to select the Play and Record category. This is because selecting the Record category ensures that no alerts (such as an incoming text message alert) will sound while the recording is in progress.

Table 6-3 lists the audio session categories you can use. Different categories allow sounds to be silenced by the Ring/Silent or Silent switch (or device locking), to mix with other audio, or to play while the app is in the background. 

Table 6-3  Audio session categories and their associated behaviors

Category	Meaning	Silenced	Mixes	In Background
Solo Ambient	Sounds enhance app functionality, and should silence other audio.	Yes	No	No
Ambient	Sounds enhance app functionality but should not silence other audio.	Yes	Yes	No
Playback	Sounds are essential to app functionality and might mix with other audio.	No	No (default) Yes (when the Mix With Others property is added)	Yes
Record	Audio is user-recorded.	No	No	Yes
Play and Record	Sounds represent audio input and output, sequentially or simultaneously.	No	No (default) Yes (when the Mix With Others property is added)	Yes
Audio Processing	App performs hardware-assisted audio encoding (it does not play or record).	N/A	No	Yes *

* If you select the Audio Processing category and you want to perform audio processing in the background, you need to prevent your app from suspending before you’re finished with the audio processing. 

Here are some scenarios that illustrate how to choose the audio session category that provides an audio experience users appreciate.

Scenario 1: An educational app that helps people learn a new language. You provide:

• Feedback sounds that play when users tap specific controls
• Recordings of words and phrases that play when users want to hear examples of correct pronunciation

In this application, sound is essential to the primary functionality. People use this app to hear words and phrases in the language they’re learning, so the sound should play even when the device locks or is switched to silent. Because users need to hear the sounds clearly, they expect other audio they might be playing to be silenced.
To produce the audio experience users expect for this app, you would use the Playback category. Although this category can be refined to allow mixing with other audio, this app should use the default behavior to ensure that other audio does not compete with the educational content the user has explicitly chosen to hear.
Scenario 2: A Voice over Internet Protocol (VoIP) app. You provide:

• The ability to accept audio input
• The ability to play audio

In this app, sound is essential to the primary functionality. People use this app to communicate with others, often while they’re currently using a different application. Users expect to be able to receive calls when they’ve switched their device to silent or the device is locked, and they expect other audio to be silent for the duration of a call. They also expect to be able to receive and continue calls when the app is in the background.
To produce the expected user experience for this app, you would use the Play and Record category. In addition, you would be sure to activate your audio session only when you need it so that users can use other audio between calls.
Scenario 3: A game that allows users to guide a character through different tasks. You provide:

• Various gameplay sound effects
• A musical soundtrack

In this app, sound greatly enhances the user experience, but is not essential to the main task. Also, users are likely to appreciate being able to play the game silently or while listening to songs in their music library instead of to the game soundtrack.
The best strategy is to find out if users are listening to other audio when your app starts. Don’t ask users to choose whether they want to listen to other audio or listen to your soundtrack. Instead, use the Audio Session Services function AudioSessionGetProperty to query the state of the kAudioSessionProperty_OtherAudioIsPlaying property. Based on the answer to this query, you can choose either the Ambient or Solo Ambient categories (both categories allow users to play the game silently):

• If users are listening to other audio, you should assume that they’d like to continue listening and would not appreciate being forced to listen to the game soundtrack instead. In this situation, have your app choose the Ambient category.
• If users are not listening to any other audio when your app starts, have your app choose the Solo Ambient category.

Scenario 4: An app that provides precise, real-time navigation instructions to the user’s destination. You provide:

• Spoken directions for every step of the journey
• A few feedback sounds
• The ability for users to continue to listen to their own audio

In this app, the spoken navigation instructions represent the primary task, regardless of whether the app is in the background. For this reason, you would use the Playback category, which allows your audio to play when the device is locked or switched to silent, and while the app is in the background.
To allow people to listen to other audio while they use your app, you can add the kAudioSessionProperty_OverrideCategoryMixWithOthers property. However, you also want to make sure that users can hear the spoken instructions above the audio they’re currently playing. To do this, you can apply the kAudioSessionProperty_OtherMixableAudioShouldDuck property to the audio session. This ensures that your audio is louder than all currently playing audio (except phone audio on iPhone).
Scenario 5: A blogging app that allows users to upload their text and graphics to a website. You provide:

• A short startup sound file
• Various short sound effects that accompany user actions (such as a sound that plays when a post has been uploaded)
• An alert sound that plays when a posting fails

In this app, sound enhances the user experience, but it is incidental. The main task has nothing to do with audio and users do not need to hear any sounds to successfully use the app. In this scenario, you would use System Sound Services to produce sound. This is because the audio context of all sound in the app conforms to the intended purpose of this technology, which is to produce UI sound effects and alert sounds that obey device locking and the Ring/Silent (or Silent) switch in the way users expect.

Manage Audio Interruptions

Sometimes, currently playing audio is interrupted by audio from a different app. For example, an incoming phone call interrupts the current iPhone app’s audio for the duration of the call. In a multitasking environment, the frequency of such audio interruptions can be great.
To provide an audio experience users appreciate, iOS relies on you to:

• Identify the type of audio interruption your app can cause
• Respond appropriately when your app continues after an audio interruption ends

Every application needs to identify the type of audio interruption it can cause, but not every application needs to determine how to respond to the end of an audio interruption. This is because, for most types of apps, the appropriate response to the end of an audio interruption is to resume playing audio. Only apps that are primarily or partly media playback apps, and that provide media playback controls, have to take an extra step to determine the appropriate response.
Conceptually, there are two types of audio interruptions, based on the type of audio that is doing the interrupting and the way users expect the particular app to respond when the interruption ends:

• Resumable interruption. A resumable interruption is caused by audio that users view as a temporary interlude in their primary listening experience.
  After a resumable interruption ends, an app that displays controls for media playback should resume what it was doing when the interruption occurred, whether this is playing audio or remaining paused. An app that doesn’t have media playback controls should resume playing audio.
  For example, consider a user listening to an app for music playback on iPhone when a VoIP call arrives in the middle of a song. The user answers the call, expecting the playback app to be silent while they talk. After the call ends, the user expects the playback app to automatically resume playing the song, because the music—not the call—constitutes their primary listening experience and they had not paused the music before the call arrived. If, on the other hand, the user had paused music playback before the call arrived, they would expect the music to remain paused after the call ends.
  Other examples of apps that can cause resumable interruptions are apps that play alarms, audio prompts (such as spoken driving directions), or other intermittent audio.
• Nonresumable interruption. A nonresumable interruption is caused by audio that users view as a primary listening experience, such as audio from a media playback app.
  After a nonresumable interruption ends, an app that displays media playback controls should not resume playing audio. An app that doesn’t have media playback controls should resume playing audio.
  For example, consider a user listening to a music playback application (music app 1) when a different music playback application (music app 2) interrupts. In response, the user decides to listen to music app 2 for some period of time. After quitting music app 2, the user would not expect music app 1 to automatically resume playing because they’d deliberately made music app 2 their primary listening experience.

The following guidelines help you decide what information to supply and how to continue after an audio interruption ends.
Identify the type of audio interruption your app caused. You do this by deactivating your audio session in one of the following two ways when your audio is finished:

• If your app caused a resumable interruption, deactivate your audio session with the AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation flag.
• If your app caused a nonresumable interruption, deactivate your audio session without any flags.

Providing, or not providing, the flags allows iOS to give interrupted apps the ability to resume playing their audio automatically, if appropriate.
Determine whether you should resume audio when an audio interruption ends. You base this decision on the audio user experience you provide in your app.

• If your app displays media playback controls that people use to play or pause audio, you need to check the AVAudioSessionInterruptionFlags_ShouldResume flag when an audio interruption ends.
  If your app receives the Should Resume flag, you should have your app:
  
  • Resume playing audio if your app was actively playing audio when it was interrupted
  • Not resume playing audio if your app was not actively playing audio when it was interrupted
• If your app does not display any media playback controls that people can use to play or pause audio, you should have your app always resume previously playing audio when an audio interruption ends. You do not have to check for the presence of the Should Resume flag.
  For example, a game that plays a soundtrack should automatically resume playing the soundtrack after an interruption.

Handle Media Remote Control Events, if Appropriate

Beginning in iOS 4.0, apps can receive remote control events when people use iOS media controls or accessory controls (such as headset controls). This allows your app to accept user input that does not come through your UI, whether your app is currently playing audio in the foreground or in the background.
In iOS 4.3 and later, apps can send video to AirPlay-enabled hardware, such as Apple TV, and transition to the background while playback continues. Such an app can also accept user input via remote control events, so that users can control video playback while the app is in the background.
A media playback app, in particular, needs to respond appropriately to media remote control events, especially if it plays audio or video while it’s in the background.
To meet the responsibilities associated with the privilege of playing media while your app is in the background, be sure to follow these guidelines:
Limit your app’s eligibility to receive remote control events to times when it makes sense. For example, if your app allows users to read content, search for information, and listen to audio, it should accept remote control events only while the user is in the audio context. When the user leaves the audio context, you should relinquish the ability to receive the events. If your app allows users to play audio or video on an AirPlay-enabled device, it should accept remote control events for the duration of media playback. Following these guidelines allows users to consume a different app’s media (and control it with headset controls) when they’re in the nonmedia contexts of your app.
As much as possible, use system-provided controls to offer AirPlay support. When you use the MPMoviePlayerController class to enable AirPlay playback, you can take advantage of a standard control that allows users to choose an AirPlay-enabled device that is currently in range. Or, you can use the MPVolumeView class to display AirPlay-enabled audio or video devices from which users can choose. Users are accustomed to the appearance and behavior of these standard controls, so they’ll know how to use them in your app.
Don’t repurpose an event, even if the event has no meaning in your app. Users expect the iOS media controls and accessory controls to function consistently in all apps. You do not have to handle the events that your app doesn’t need, but the events that you do handle must result in the experience users expect. If you redefine the meaning of an event, you confuse users and risk leading them into an unknown state from which they can’t escape without quitting your app.

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 user interface 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 is the right thing to do. It can also increase your user base and it might 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 application. 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 cannot 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 application, 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 does not require confirmation before its actions are performed, you should give users the opportunity to undo or redo these actions .


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.

Note: If you need to enable actions that use the selected text or object in a way that’s external to the current context, it’s better to use an action sheet. For example, if you want to allow people to share their selection with others, you might display an action sheet that lists social networking sites to allow the actions of selecting and sending to a particular site. 

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 application 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

A custom input view can replace the system-provided onscreen keyboard in apps running in iOS 3.2 and later. 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.

Note: The standard click sound is available only for custom input views that are currently onscreen. People can turn off all keyboard clicks (including ones that come from your custom input view) in Settings > Sounds.

Location Services

Location Services allows applications to determine people’s approximate location geographically, the direction they’re pointing their device, and the direction in which they’re moving. People appreciate being able to automatically tag content with their physical location or find friends that are currently nearby, but they also appreciate being able to disable such features when they don’t want to share their location with others. (To learn more about how to make your app location-aware, see Location Awareness Programming Guide.)
When users turn off Location Services and later use an application feature that requires their location, they see an alert that tells them they must change their preference before they can use the feature. The alert does not allow users to make this change within the app; instead, they must go to Settings and change their preference. This ensures that users are fully aware that they are granting systemwide permission to use their location information.

Follow these guidelines to ensure the best user experience for the location-aware features in your app:

Make sure users understand why they’re being asked to turn Location Services on. 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 location. For example, people can use Maps when Location Services is off, but they see the alert when they access the feature that finds and tracks their current location.

Check the user’s Location Services preference to avoid triggering the alert unnecessarily. You can use Core Location programming interfaces to get this setting . 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.

Display the alert when your app starts only if your app cannot perform its primary function without knowing the user’s location. People will not be bothered by this because they understand that the main function of your app depends on knowing their location.

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

 Source: http://developer.apple.com/library/ios