You can customize many UI elements by supplying a resizable image for the element’s background.
You can create a resizable image to customize the background of several standard UI elements, such as popovers, buttons, navigation bars, tab bars, and toolbars (including the items on these bars). Providing resizable images for these elements can result in better app performance.
Bars
1. The Status Bar
The UIStatusBarStyle constant, described in UIApplication Class Reference , controls the status bar style.
To specify the status bar style, you set a value in your Info.plist file.
Think twice before hiding the status bar if your application is not a game or full-screen media-viewing
application.
2. Navigation Bar
A navigation bar enables navigation through an information hierarchy and, optionally, management of screen
contents.
A navigation bar is contained in a navigation controller, which is an object that manages the display of your hierarchy of custom views.
Consider putting a segmented control in a navigation bar at the top level of an application. This is especially useful if doing so helps to flatten your information hierarchy and makes it easier for people to find what they’re looking for.
On iPhone, take into account the automatic change in navigation bar height that occurs on device rotation.
Don’t specify the height of a navigation bar programmatically; instead, you can take advantage of the UIBarMetrics constants to ensure that your content fits well.
3. Toolbar
A toolbar contains controls that perform actions related to objects in the screen or view.
A toolbar is typically contained in a navigation controller, which is an object that manages the display of a hierarchy of custom views.
Try to avoid mixing plain style (borderless) and bordered toolbar items in the same toolbar.
4. Tab Bar
A tab bar gives people the ability to switch between different subtasks, views, or modes.
On iPhone, a tab bar can display no more than five tabs at one time; if the app has more tabs, the tab bar
displays four of them and adds the More tab, which reveals the additional tabs in a list.
On iPad, a tab bar can display more than five tabs. So, avoid creating a More tab. In an iPad app, a screen devoted solely to a list of additional tabs is a poor use of space.
In general, try to limit the number of tabs in the main view or in the right pane of a split view to about seven. In a popover or in the left pane of a split view, up to about five tabs fit well.
Consider badging a tab bar icon to communicate unobtrusively. You can display a badge on a tab bar icon
to indicate that there is new information associated with that view or mode.
In general, use a tab bar to organize information at the application level. A tab bar is well-suited for use in the main app view because it’s a good way to flatten your information hierarchy and provide access to several peer information categories or modes at one time.
Don’t remove a tab when its function is unavailable. If a tab represents a part of your app that is unavailable in the current context, it’s better to display a disabled tab than to remove the tab altogether.
On iPad, you might use a tab bar in a split view pane or a popover if the tabs switch or filter the content within that view. However, it often works better to use a segmented control at the bottom edge of a popover or split view pane, because the appearance of a segmented control coordinates better with the popover or split view appearance.
Content Views
1. Popover (iPad Only)
A popover is a self-contained view that hovers above the contents of a screen. It always displays an arrow that indicates the point from which it emerged.
In iPad apps, an action sheet always appears inside a popover.
You can use a popover to:
● Display additional information or a list of items related to the focused (or selected) object.
● Display an action sheet that contains a short list of options that are closely related to something on the screen.
● Display the contents of the left pane when a split view–based app is in portrait. If you do this, be sure to provide an appropriately titled button that displays the popover, preferably in a navigation bar or toolbar at the top of the screen.
Avoid providing a “dismiss popover” button. A popover should close automatically when its presence is no
longer necessary.
● When a popover’s only function is to provide a set of options or items that have an effect on the main view, it should close as soon as people make a choice.
Occasionally, it can make sense to provide a popover that contains items that affect the main view, but
that does not close when people make a choice. You might want to do this if you implement an inspector
in a popover, because people might want to make an additional choice or change the attributes of the
current choice.
A popover that provides menu or inspector functionality should close when people tap anywhere outside
its bounds, including the control that reveals the popover.
● If a popover enables a task, it can be appropriate to display buttons that complete or cancel the task and simultaneously dismiss the popover.
In general, save users’ work when they tap outside a popover’s borders. You should discard their work only if they tap a Cancel button.
Make sure people can use a popover without seeing the application content behind it.
Ensure that only one popover is visible onscreen at a time.
Except for an alert, nothing should display on top of a popover.
Ideally, the width of a popover should be at least 320 points, but no greater than 600 points. The height of a popover is not constrained, so you can use it to display a long list of items. In general, though, you should try to avoid scrolling in a popover that enables a task or that presents an action sheet.
You might want to change a popover’s size if you use it to display both a minimal and an expanded view of the same information. If you adjust the size of a popover while it’s visible, you can choose to animate the change. Animating the change is usually a good idea because it avoids making people think that a new popover has replaced the old one.
2. Split View (iPad Only)
A split view consists of two panes. The width of the left pane is fixed at 320 points in all orientations. Users cannot resize either pane of a split view.
Avoid creating a right pane that is narrower than the left pane.
Avoid displaying a navigation bar in both panes at the same time.
In general, indicate the current selection in the left pane in a persistent way.
3. Table View
If you include an index, avoid using table-view elements that display on the right edge of the table (such as the disclosure indicator), because these elements interfere with the index.
If table content is extensive or complex, avoid waiting until all the data is available before displaying anything. Instead, fill the onscreen rows with textual data immediately and display more complex data (such as images) as they become available.
Don’t use white in areas of an image that you want to look transparent.
If appropriate, use a custom title for the Delete button.
Generally, use grouped tables for the value 1 and value 2 cell styles.
As much as possible, ensure that your text labels are succinct to avoid truncation.
4. Text View
You have control over the font, color, and alignment of the text in a text view, but only as they apply to the entirety of the text.
If you must enable variable fonts, colors, or alignments within a view that displays text, you can use a web view instead of a text view, and style the text using HTML.
5. Web View
A web view is a region that can display rich HTML content.
In addition to displaying web content, a web view performs some automatic processing on web content, such as converting a phone number to a phone link.
6. Container View Controller
A container view controller manages and presents its set of child views (or view controllers) in a custom way.
Examples of system-defined container view controllers are tab bar view controller, navigation view controller, and split view controller.
Make sure that your custom container view controller works in both orientations.
In general, avoid flashy view transitions. When you use storyboards to design a custom view controller, it’s easy to define custom animations for the transitions between content views. But in most cases, flamboyant view transitions distract people from their purpose and often decrease the aesthetic appeal of your app.
Alerts, Action Sheets, and Modal Views
1. Alert
An alert gives people important information that affects their use of the application (or the device).
The unattached appearance of an alert emphasizes the fact that its arrival is due to some change in the application or the device, not necessarily as the result of the user’s most recent action.
The background appearance of an alert is system-defined and cannot be changed.
Write alert text that succinctly describes the situation and explains what people can do about it.
Keep the title short enough to display on a single line, if possible. Avoid single-word titles that don’t provide any useful information, such as “Error” or “Warning.”
Be sure to test the appearance of your alert in both orientations.
A two-button alert is often the most useful, because it is easiest for people to choose between two alternatives.
● In a two-button alert that proposes a potentially risky action, the button that cancels the action should be on the right (and light-colored).
● In a two-button alert that proposes a benign action that people are likely to want, the button that cancels the action should be on the left (and dark-colored).
Pressing the Home button while an alert is visible should quit the app, as expected. It should also be identical to tapping the Cancel button—that is, the alert is dismissed and the action is not performed.
2. Action Sheet
An action sheet displays a set of choices related to a task the user initiates.
An action sheet always contains at least two buttons that allow users to choose how to complete their task.
An action sheet prompts users to think about the potentially dangerous effects of the step they’re about to take and gives them some alternatives.
Avoid making users scroll through an action sheet.
On iPad, Display an action sheet without animation to provide alternatives related to a task that the user initiates from outside a popover. Do not include a Cancel button when the action sheet is displayed without animation, because people can tap outside the popover to dismiss the action sheet without selecting one of the other alternatives.
On iPad, Display an action sheet with animation to provide alternatives related to a task that the user initiates from within an open popover.
On both devices, use the red button color if you need to provide a button that performs a potentially destructive action.
3. Modal View
A modal view (that is, a view presented modally) provides self-contained functionality in the context of the current task or workflow.
A modal view occupies the entire application screen, which strengthens the user’s perception of entering a
separate, transient mode in which they can accomplish something.
Use a modal view when you need to offer the ability to accomplish a self-contained task related to your application’s primary function. A modal view is especially appropriate for a multistep subtask that requires UI elements that don’t belong in the main application user interface all the time.
With the possible exception of an alert, nothing should display on top of a popover.
Controls
Controls are UI elements that users view to get information, or interact with to perform an action.
1. Activity Indicator
2. Date and Time Picker
On iPad, present a date and time picker only within a popover.
3. Detail Disclosure Button
4. Info Button
On iPad, avoid using an Info button to flip the entire screen. Instead, you might use an Info button to show people that they can access an expanded view that contains related information or additional details.
5. Label
6. Network Activity Indicator
7. Page Indicator
A screen in portrait orientation can accommodate approximately 20 dots; if you try to display more dots than will fit in the screen, they will be clipped.
Do not use a page indicator if your application displays information in a hierarchy of views, because a page indicator does not help users retrace their steps through a specific path.
On iPad, investigate ways to display your content on a single screen. On the large iPad screen multiple parallel screens don’t work as well, so the need for the page indicator control is decreased.
8. Picker
Use a picker to make it easy for people to choose from a set of values. It’s often best to use a picker when people are familiar with the entire set of values.
Use the translucent selection bar to display contextual information, such as a unit of measurement. Do not display such labels above the picker or on the wheel itself.
9. Progress View
Use a progress view to provide feedback to people on a task that has a well-defined duration, especially when it’s important to show them approximately how long the task will take.
10. Rounded Rectangle Button
Use title-style capitalization (that is, capitalize every word except articles, coordinating conjunctions, and prepositions of four or fewer letters)
11. Scope Bar
A scope bar is available only in conjunction with a search bar, and is often displayed below it.
When you use a search display controller, the scope bar is displayed within the search bar to the right of the search field when the device is in landscape orientation (in portrait orientation, it’s below the search bar).
12. Search Bar
Placeholder text. The Bookmarks button. The Clear button. The results list icon. A descriptive title, called a prompt, that appears above the search bar.
The Bookmarks button is visible only when there is no user-supplied or nonplaceholder text in the search bar, because the Clear button is visible when there is text in the search bar that users might want to erase.
13. Segmented Control
A segmented control is a linear set of segments, each of which functions as a button that can display a different view.
Use a segmented control to offer closely related, but mutually exclusive choices.
An individual segment can contain either text or an image, but not both. Avoid mixing text and images in a single segmented control.
14. Slider
A slider allows users to make adjustments to a value or process throughout a range of allowed values.
15. Stepper
16. Switch
17. Text Field
Use a text field to get a small amount of information from the user. Before you decide to use a text field, consider whether there are other controls that might make inputting the information easier, such as a picker or a list.
iOS provides several different keyboard types, each designed to facilitate a different type of input. Specify different keyboard types to accommodate different types of content you expect users to enter.
System-Provided Buttons and Icons
1. Standard Buttons for Use in Toolbars and Navigation Bars
To find out which symbol names to use to specify these buttons, see the documentation for UIBarButtonSystemItem in UIBarButtonItem Class Reference .
In addition, you can use the system-provided page curl button in a toolbar. The page curl button is not available for use in a navigation bar.
The page curl button allows you to give users a way to curl up the bottom corner of a screen to see information underneath.
Don’t use the page curl button to flip the screen.
2. Standard Icons for Use in Tab Bars
To find out which symbol names to use to specify these icons, see the documentation for UITabBarSystemItem
in UITabBarItem Class Reference .
3. Standard Buttons for Use in Table Rows and Other UI Elements
iCloud Storage
Respect the user’s iCloud account.
It’s important to remember that iCloud storage is a finite resource for
which users pay. Also, note that when the user’s iCloud account is active, iCloud automatically backs up the contents of your app’s 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.
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.
Make sure that your app behaves reasonably when iCloud storage is unavailable.
If appropriate, make it easy for users to enable iCloud storage for your app.
Avoid asking users to choose which documents to store in iCloud.
Avoid giving users the option to create a “local” document.
When appropriate, update content automatically.
Warn users about the consequences of deleting a document.
Tell users about conflicts as soon as possible, but only when necessary.
Be sure to include the user’s iCloud content in searches.
Multitasking
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
Be prepared for interruptions, and be ready to resume.
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.
Be ready to pause activities that require people’s attention or active participation.
Ensure that your audio behaves appropriately.
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 content described in “Notification Center”.
When appropriate, finish user-initiated tasks in the background.
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.
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.
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
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.
A banner is a small translucent view that appears onscreen and then disappears after a few seconds.
An alert is a standard alert view that appears onscreen and requires user interaction to dismiss.
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).
A custom or system-provided sound can accompany any of the other three notification delivery styles.
Keep badge contents up to date.
Don’t send multiple notifications for the same event.
Provide a custom message that does not include your app name.
Optionally, provide a custom title for the action button in an alert.
Provide a sound that users can choose to hear when a notification arrives.
Optionally, provide a launch image.
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.
If you want to use a custom title for the action button, 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)
Printing
Typically, users tap the standard Action button in your app when they want to print something.
iAd Rich Media Ads
There are two types of banners that you can display in your application: standard banners and full screen banners.
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.
iPad 768 x 66 points 1024 x 66 points
iPhone 320 x 50 points 480 x 32 points
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.
Portrait 911 points to 1024 points 768 points
Landscape 655 points to 768 points 1024 points
Place a standard banner view at or near the bottom of the screen. If there is a toolbar or tab bar, put the standard banner view directly above the toolbar or tab bar.
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.
Present a full screen banner nonmodally when there are transitions between app views.
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.
Avoid displaying banners on screens that users are likely to see only briefly. 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.
Don’t allow a standard banner to scroll off the screen.
While people view or interact with ads, pause activities that require their attention or interaction.
Don’t stop an ad, except in rare circumstances.
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.
On iPad, display a document preview modally.
On iPhone, display a document preview in a dedicated view, preferably a navigation view.
Sound
Understand User Expectations
1. Users switch their devices to silent when they want to
2. Users use the device’s volume buttons to adjust the volume of all sounds their devices can play
3. Users use headsets and headphones to hear sounds privately and to free their hands
Define the Audio Behavior of Your App
1. If necessary, you can adjust relative, independent volume levels to produce the best mix in your app’s audio output.
2. Ensure that your app can display the audio route picker, if appropriate.
3. If you need to display a volume slider, be sure to use the system-provided volume slider available when you use the MPVolumeView class.
4. 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.
5. If sound plays an important role in your app, use Audio Session Services or the AVAudioSession class.
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.
● Select an audio session category based on its semantic meaning, not its precise set of behaviors.
● In rare cases, add a property to the audio session to modify a category’s standard behavior.
● Consider basing your category selection on the current audio environment of the device.
● In general, avoid changing categories while your application is running.
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.
Manage Audio Interruptions
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
Handle Media Remote Control Events, if Appropriate
Limit your app’s eligibility to receive remote control events to times when it makes sense.
As much as possible, use system-provided controls to offer AirPlay support.
Don’t repurpose an event, even if the event has no meaning in 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.
Edit Menu
1. Display commands that make sense in the current context.
2. Accommodate the menu display in your layout.
3. Support both gestures that people can use to invoke the menu.
4. Avoid creating a button in your UI that performs a command that’s available in the edit menu.
5. Consider enabling the selection of static text if it’s useful to the user.
6. Don’t make button titles selectable.
7. Combine support for undo and redo with your support of copy and paste.
8. Create edit menu items that edit, alter, or otherwise act directly upon the user’s selection.
9. List custom items together after all system-provided items.
10. Keep the number of custom menu items reasonable.
11. Use succinct names for your custom menu items and make sure the names precisely describe what the commands do.
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
1. Supply brief descriptive phrases that tell users precisely what they’re undoing or redoing.
2. Avoid supplying text that is too long.
3. Avoid overloading the shake gesture.
4. Use the system-provided Undo and Redo buttons only if undo and redo are fundamental tasks in your app.
5. Clearly relate undo and redo capability to the user’s immediate context, and not to an earlier context.
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.
The user experience of iOS-based devices revolves around streamlined interaction with content that people care about.
Focus on the Primary Task
Your application definition statement will help you focus your app on its primary task.
1. Analyze what’s needed in each screen
As you decide what to display in each screen always ask yourself, Is this critical information or functionality users need right now ? If your answer is no, decide whether the information or functionality might be critical in a different context, or if it’s not that important after all.
2. Elevate the Content that People Care About
In a game, people care about the experience; they don’t expect to manage, consume, or create content. If you’re developing a game, you elevate content by enhancing the experience with a satisfying story, beautiful graphics, and responsive gameplay.
If you’re not developing a game, you can help people focus on the content by designing your UI as a subtle frame for the information they’re interested in.
a. Minimize the number and prominence of controls to decrease their weight in the UI.
b. Consider subtly customizing controls so that they integrate with your app’s graphical style.
c. Consider fading controls after people have stopped interacting with them for a little while.
3. Think Top Down
The top of the screen is most visible to people, because they tend to interact with the device by holding the device in the following ways:
● In their nondominant hand (or laying it on a surface), and gesturing with a finger of the dominant hand
● In one hand, and gesturing with the thumb of the same hand
● Between their hands, and gesturing with both thumbs
Put the most frequently used (usually higher level) information near the top.
As the user scans the screen from top to bottom, the information displayed should progress from general to specific and from high level to low level.
4. Give People a Logical Path to Follow
Make the path through the information you present logical and easy for users to predict.
In addition, be sure to provide markers, such as back buttons, that users can use to find out where they are and how to retrace their steps.
In most cases, give users only one path to a screen. If a screen needs to be accessible in different circumstances, consider using a modal view that can appear in different contexts.
5. Make Usage Easy and Obvious
Make the main function of your application immediately apparent. You can make it so by:
● Minimizing the number of controls from which people have to choose
● Using standard controls and gestures appropriately and consistently so that they behave the way people expect
● Labeling controls clearly so that people understand exactly what they do
Be consistent with the usage paradigms of the built-in applications.
6. Use User-Centric Terminology
In all your text-based communication with users, use terminology you’re sure that your users understand.
Take care to be accurate when describing dates.
It can be confusing if you don’t account for the user’s current locale.
7. Minimize the Effort Required for User Input
Balance any request for input by users with what you offer users in return.
Make it easy for users to input their choices.
Get information from iOS, when appropriate.
When it makes sense, don’t force people to give you information you can easily find for yourself, such as their contacts or calendar information.
8. Downplay File-Handling Operations
As much as possible, allow people to manage documents without opening iTunes on their computer. Consider using iCloud storage to help users access their content on all of their devices.
9. Enable Collaboration and Connectedness
When appropriate, make it easy for people to interact with others and share things like their location, opinions, and high scores.
For iPad, think of ways to allow more than one person to use your app on the same device.
10. De-emphasize Settings
Avoid including settings in your application if you can.
Let users set the behavior they want by using configuration options in your application. Configuration options let your application react dynamically to changes, because people do not have to leave your application to set them.
Offer configuration options in the main user interface or (in iPhone apps) on the back of a view.
11. Brand Appropriately
Incorporate a brand’s colors or images in a refined, unobtrusive way.
Branding is most effective when it is subtle and understated. For the best user experience, you want to quietly remind users of your identity.
Avoid taking space away from the content people care about.
12. Make Search Quick and Rewarding
Build indexes of your data so that you are always prepared for search.
Live-filter local data so that you can display results more quickly.
It’s best when you can begin filtering as soon as users begin typing, and narrow the results as they continue typing.
When live filtering is impractical, you can begin the search process after the user taps the Search button in the keyboard. If you do this, be sure to provide
feedback on the search’s progress so users know that the process has not stalled.
When possible, also filter remote data while users type.
Display a search bar above a list or the index in a list.
Use a tab for search only in special circumstances.
If search is a primary function in your application you might want to feature it as a distinct mode.
If necessary, display placeholder content right away and partial results as they become available.
Consider providing a scope bar if the data sorts naturally into different categories.
13. Entice and Inform with a Well-Written Description
Be sure to correct all spelling, grammatical, and punctuation errors.
Keep all-capital words to a minimum.
Consider describing specific bug fixes.
14. Be Succinct
Think like a newspaper editor, and strive to convey information in a condensed, headline style.
Give controls short labels, or use well-understood symbols
15. Use UI Elements Consistently
Follow the recommended usages for standard user interface elements.
For an app that enables an immersive task, such as a game, it’s reasonable to create completely custom controls.
Avoid radically changing the appearance of a control that performs a standard action.
To avoid confusing people, never use the standard buttons and icons to mean something else.
16. Consider Adding Physicality and Realism
When appropriate, add a realistic, physical dimension to your application. Often, the more true to life your application looks and behaves, the easier it is for people to understand how it works and the more they enjoy using it.
Think of the objects and scenes you design as opportunities to communicate with users and to express the essence of your app. Don’t feel that you must strive for scrupulous accuracy. Often, an amplified or enhanced portrayal of something can seem more real, and convey more meaning, than a faithful likeness.
Use appropriate animation to further enhance realism in your application. As
much as possible, make sure your virtual views and controls mimic the behavior of the physical objects and controls they resemble.
17. Delight People with Stunning Graphics
Rich, beautiful, engaging graphics draw people into an application and make the simplest task rewarding.
Consider replicating the look of high-quality or precious materials.
When appropriate, create high-resolution artwork.
In most cases, scaling up your artwork is not recommended as a long-term solution. Instead, try creating your artwork in a dimension that is larger than you need, so you can add depth and details before scaling it down.
Ensure that your launch images and application icon are high quality.
Remove hard-coded values that identify screen dimensions.
18. Handle Orientation Changes
In all orientations, maintain focus on the primary content. This is your highest priority.
Think twice before preventing your application from running in all orientations.
If your application interprets changes in device orientation as user input, you can handle rotation in app-specific ways.
Take advantage of the one-step change in orientation to perform smoother, often faster rotations.
On iPhone, anticipate users’ needs when you respond to a change in device orientation. Users often rotate their devices to landscape orientation because they want to “see more.”
On iPad, strive to satisfy users’ expectations by being able to run in all orientations. As much as possible, your application should encourage people to interact with iPad from any side by providing a great experience in all orientations.
Pay attention to accelerometer values.
Follow these guidelines as you design how your iPad app should handle rotation:
Consider changing how you display auxiliary information or functionality.
Avoid gratuitous changes in layout.
When possible, avoid reformatting information and rewrapping text on rotation.
Provide a unique launch image for each orientation.
If it’s essential that your application run in only one orientation,
you should:
Launch your app in your supported orientation, regardless of the current device orientation.
Avoid displaying a UI element that tells people to rotate the device.
Support both variants of an orientation.
If your application runs only in landscape, people should be able to use it whether they’re holding the device with the Home button on the right or on the left.
19. Make Targets Fingertip-Size
Give tappable elements in your application a target area of about 44 x 44 points.
20. Use Subtle Animation to Communicate
Subtle and appropriate animation can:
● Communicate status
● Provide useful feedback
● Enhance the sense of direct manipulation
● Help people visualize the results of their actions
Add animation cautiously, especially in applications that do not provide an immersive experience.
Make animation consistent with built-in applications when appropriate.
Use animation consistently throughout your app.
21. Support Gestures Appropriately
Avoid associating different actions with the standard gestures users know.
Use complex gestures as shortcuts to expedite a task, not as the only way to perform a task.
In general, avoid defining new gestures.
For iPad, consider using multifinger gestures.
22. Ask People to Save Only When Necessary
People should have confidence that their work is always preserved unless they explicitly cancel or delete it. iOS apps should take responsibility for saving people’s input, both periodically and when they open a different document or quit the application.
For iPad, save information that people enter in a popover (unless they cancel their work).
23. Make Modal Tasks Occasional and Simple
Keep modal tasks fairly short and narrowly focused.
Always provide an obvious and safe way to exit a modal task.
If the task requires a hierarchy of modal views, make sure your users understand what happens if they tap a Done button in a view that’s below the top level.
24. Start Instantly
It’s often said that people spend no more than a minute or two evaluating a new app.
Display a launch image that closely resembles the first screen of the application.
Avoid displaying an About window or a splash screen. In general, try to avoid providing any type of startup experience that prevents people from using your application immediately.
On iPhone, specify the appropriate status bar style. In general, you want the status bar to coordinate with the rest of your application’s UI.
Launch in the appropriate default orientation.
Avoid asking people to supply setup information.
Focus your solution on the needs of 80 percent of your users.
Get as much information as possible from other sources.
If you must ask for setup information, prompt people to enter it within your application.
Delay a login requirement for long as possible.
Restore the state of the app to that in use when the user last stopped using the application.
Important: Don’t tell people to reboot or restart their devices after installing your application because restarting takes extra time and can make the app seem less easy to use. If your application has memory-usage or other issues that make it difficult to run unless the system has just booted, you need to address those issues.
25. Always Be Prepared to Stop
Save user data as soon as possible and as often as reasonable because an exit or terminate notification can arrive at any time.
Save the current state when stopping at the finest level of detail possible so that people don’t lose their context when they start the application again.
26. Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to interpret this as a crash.
However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it.
Display an attractive screen that describes the problem and suggests a correction.
If only some of your application’s features are not working, display either a screen or an alert when people activate the feature. Display the alert only when people try to access the feature that isn’t functioning.
27. If Necessary, Display a License Agreement or Disclaimer
If you provide an end-user license agreement (or EULA) with your iOS application, the App Store displays it so that people can read it before they get your application.
28. For iPad: Enhance Interactivity (Don’t Just Add Features)
The best iPad applications give people innovative ways to interact with content while they perform a clearly defined, finite task.
Resist the temptation to add features that are not directly related to the main task.
29. For iPad: Reduce Full-Screen Transitions
Closely associate visual transitions with the content that’s changing.
30. For iPad: Restrain Your Information Hierarchy
In general, focus the main screen on the primary content.
Use a navigation bar in the right pane of a split view.
Use a navigation bar in the left pane of a split view.
Use a popover to enable actions or provide tools that affect onscreen objects.
Use a segmented control in a toolbar.
Use a tab bar.
31. For iPad: Consider Using Popovers for Some Modal Tasks
32. For iPad: Migrate Toolbar Content to the Top
If your iPhone application has a toolbar, consider moving it to the top of the screen instead of leaving it at the bottom, with the additional width of the iPad screen.
1. The Display Is Paramount, Regardless of Its Size
2. Device Orientation Can Change
3. Apps Respond to Gestures, Not Clicks
4. People Interact with One App at a Time
Multitasking is available on certain devices running iOS 4 and later.
5. Preferences Are Available in Settings
6. Onscreen User Help Is Minimal
7. Most iOS Apps Have a Single Window
8. Two Types of Software Run in iOS
● iOS apps
● Web content
Web apps. Webpages that provide a focused solution to a task and conform to certain display guidelines are known as web apps because they behave similarly to iOS apps.
A web app often hides the UI of Safari on iOS so that it looks more like a native app. Using the web clip feature, a web app can also supply an icon for people to put on the Home screen. This allows people to open web apps in the same way that they open iOS apps.
9. Safari on iOS Provides the Web Interface
Create an Application Definition Statement
An application definition statement is a concise, concrete declaration of an app’s main purpose and its intended audience.
1. List All the Features You Think Users Might Like
2. Determine Who Your Users Are
Apart from the likelihood that your users are mobile and that they expect beautiful graphics, simple interactions, and high performance, what distinguishes them? In the context of the app you’re planning, what is most important to your users?
3. Filter the Feature List Through the Audience Definition
If, after deciding on a few audience characteristics, you end up with just a few features, you’re on the right track: Great iOS applications have a laser focus on the task users want to accomplish.
4. Don’t Stop There
Use your application definition statement throughout the development process to determine the suitability of features, controls, and terminology.
As you consider whether to add a new feature, ask yourself whether it is essential to the main purpose of your app and to your target audience.
As you consider the look and behavior of the UI, ask yourself whether your users appreciate a simple, streamlined style or a more overtly thematic style.
Be guided by what people might expect to accomplish with your app, such as the ability to accomplish a serious task, to get a quick answer, to delve into comprehensive content, or to be entertained.
As you consider the terminology to use, strive to match your audience’s expertise with the subject.
Design the App for the Device
Embrace iOS UI Paradigms
1. Controls should look tappable.
iOS controls, such as buttons, pickers, and sliders, have contours and gradients that invite touches.
2. App structure should be clean and easy to navigate.
iOS provides the navigation bar for drilling down through hierarchical content, and the tab bar for displaying different peer groups of content or functionality.
3. User feedback should be subtle, but clear.
iOS apps often use precise, fluid animations to show the results of user actions. iOS apps can also use the activity indicator and the progress view to show status, and the alert to give users warnings or other critical information.
Ensure that Universal Apps Run Well on Both iPhone and iPad
1. Mold the UI of each app version to the device it runs on.
Most individual UI elements are available on both devices, but overall the layout differs dramatically.
2. Adapt art to the screen size.
Users tend to expect more high-fidelity artwork in iPad apps than they do in iPhone apps. Merely scaling up an iPhone app to fill the iPad screen is not recommended.
3. Preserve the primary functionality of your app, regardless of the device it runs on.
Even though one version might offer a more in-depth or interactive presentation of the task than the other, it’s important to avoid making users feel that they’re choosing between two entirely different apps.
4. Go beyond the default.
Unmodified iPhone apps run in a compatibility mode on iPad by default. Although
this mode allows people to use an iPhone app on iPad, it does not give them the device-specific experience they want.
Reconsider Web-Based Designs
Tailor Customization to the Task
The best iOS apps balance UI customization with clarity of purpose and ease of use.
1. Always have a reason for customization.
2. As much as possible, avoid increasing the user’s cognitive burden.
3. Be internally consistent.
4. Always defer to the content.
5. Think twice before you redesign a standard control.If you plan on doing more than customizing a standard control, make sure your redesigned control provides as much information as the standard one.
6. Be sure to thoroughly user-test custom UI elements.
Prototype and Iterate
Before you invest significant engineering resources into the implementation of your design, it’s a really good idea to create prototypes for user testing.
You don’t need to supply a large amount of content or enable every control in your prototype app, but you do need to provide enough context to suggest a realistic experience.
When you base your prototype on an Xcode template, you get lots of functionality for free and it’s relatively easy to make design adjustments in response to feedback. With a short turnaround time, you should be able to test several iterations of your prototype before you solidify your design and commit resources to its implementation.
The comfortable minimum size of tappable UI elements is 44 x 44 points.
Pixel is the appropriate unit of measurement to use when discussing the size of a device screen or the size of an icon you create in an image-editing application. Point is the appropriate unit of measurement to use when discussing the size of an area that is drawn onscreen.
On a standard-resolution device screen, one point equals one pixel, but other resolutions might dictate a different relationship. On a Retina display, for example, one point equals two pixels.
On iPhone and iPod touch, the Home screen is displayed in one orientation only, which is portrait, with the Home button at the bottom. This leads users to expect iPhone apps to launch in this orientation by default.
On iPad, the Home screen is displayed in all orientations, so users tend to expect iPad apps to launch in the device orientation they’re currently using.
Gesture:Action
1. Tap:
To press or select a control or item (analogous to a single mouse click).
2. Drag:
To scroll or pan (that is, move side to side).
To drag an element.
3. Flick:
To scroll or pan quickly.
4. Swipe:
With one finger, to reveal the Delete button in a table-view row or to reveal
Notification Center (from the top edge of the screen).
With four fingers, to switch between apps on iPad.
5. Double tap:
To zoom in and center a block of content or an image.
To zoom out (if already zoomed in).
6. Pinch:
Pinch open to zoom in.
Pinch close to zoom out.
7. Touch and hold:
In editable or selectable text, to display a magnified view for cursor positioning.
8. Shake:
To initiate an undo or redo action.
Aesthetic Integrity
Aesthetic integrity is not a measure of how beautiful an application is. It’s a measure of how well the appearance of the app integrates with its function.
Consistency
1. Is the application consistent with iOS standards? Does it use system-provided controls, views, and icons correctly? Does it incorporate device features in a reliable way?
2. Is the application consistent within itself? Does text use uniform terminology and style? Do the same icons always mean the same thing? Can people predict what will happen when they perform the same action in different places? Do custom UI elements look and behave the same throughout the app?
3. Within reason, is the application consistent with its earlier versions? Have the terms and meanings remained the same? Are the fundamental concepts essentially unchanged?
Direct Manipulation
1. Rotate or otherwise move the device to affect onscreen objects.
2. Use gestures to manipulate onscreen objects.
3. Can see that their actions have immediate, visible results.
Feedback
People expect
immediate feedback when they operate a control, and they appreciate status updates during lengthy operations.
Metaphors
● Tapping Music playback controls
● Dragging, flicking, or swiping objects in a game
● Sliding On/Off switches
● Flicking through pages of photos
● Spinning picker wheels to make choices
User Control
People, not applications, should initiate and control actions.
People expect to have ample opportunity to cancel an operation before it begins, and they expect to get a chance to confirm their intention to perform a potentially destructive action. Finally, people expect to be able to gracefully stop an operation that’s underway.
Consider how people use iOS-based devices:
● People use iOS-based devices very differently than they use desktop and laptop computers, and they have different expectations for the user experience. Transitioning software from a computer to an iOS-based device is rarely a straightforward port.
● People often use iOS-based devices while they’re on the go, and in environments filled with distractions. Part of your job is to create a responsive, compelling experience that pulls people in and gets them to the content they care about quickly and easily.
● Remember the 80-20 rule: In general, the largest percentage of users (at least 80 percent) use a very limited number of features in an app, while only a small percentage (no more than 20 percent) use all the features. iOS apps seldom need to provide all the features that only power users need.
iCloud:
Apps that use iCloud must be signed with special entitlements that grant them access to the document storage space in a user’s iCloud account. To set up these entitlements, you modify your project’s configuration and perform several steps in Xcode and the iOS Provisioning Portal.
The best way to manage a file in iCloud is to use a custom document object based on the UIDocument class. This class provides the basic behavior required for managing files both locally and in iCloud. To use the class, you must subclass it and override the methods responsible for reading and writing your app data.
In the Model-View-Controller architecture, document objects are model controllers—that is, their job is to act as a controller object for portions of your app’s data model. A document object typically facilitates interactions between your app’s data structures and the view controllers that present the associated data.
A document object writes a document’s contents to disk and reads those contents back in. Nearly all of the work needed to initiate read and write operations is handled automatically by the UIDocument class. But because the actual reading and writing of data is specific to your document class, you must write some custom code.
In the Simple Text Editor app, the document object’s data is an NSString object, but UIDocument does not allow you to write strings directly to disk. So instead, you must package the string in a form that the document object can handle, namely an NSData object. You do this in the contentsForType:error: method of your document subclass.
NSData *docData = [self.documentText
dataUsingEncoding:NSUTF8StringEncoding];
Using the built-in document infrastructure allows you to focus on your data instead of worrying about how to write that data to disk. When you return your data object, the document object creates a file coordinator object and uses it to write the data to disk. The use of a file coordinator ensures that your app has exclusive access to the file and is required when saving files to an iCloud container directory. If you did not use the UIDocument class, you would be responsible for creating the file coordinator object yourself.
The process for reading your document data is similar to the process for writing it. All you have to do is retrieve your document data from the data object passed to the loadFromContents:ofType:error: method. As with writing, you do not have to create a file coordinator or do anything other than read your data from the provided object.
self.documentText = [[NSString alloc]
initWithData:contents
encoding:NSUTF8StringEncoding];
When calling a delegate method, always check for the existence of the delegate object and make sure that the object responds to the given selector.
if (self.delegate && [self.delegate respondsToSelector:
@selector(documentContentsDidChange:)])
[self.delegate documentContentsDidChange:self];
Note: An initialization method is one of two places in which you should not use accessor methods to access properties (the other place is in a dealloc method). In the rest of your code, you should use accessor methods, such as self.name, to get or set an object’s properties.
So, Declare the list-creation method by adding an @interface statement before the @implementation statement. That is a class extension, it allows you to declare a method that is private to the class.
master view controller:
When you use a built-in cell style, the connections between these labels and the cell’s properties are made automatically. In a cell that uses the subtitle style, the textLabel property refers to the title and the detailTextLabel property refers to the subtitle.
An accessory is a standard user interface (UI) element that can appear in a table cell. The disclosure indicator accessory (which looks similar to “>”) tells users that tapping an item reveals related information in a new screen.
Typically, an app displays data in a table by implementing the table view data source methods in a table view controller class. At a minimum, the table view controller class implements the numberOfRowsInSection and cellForRowAtIndexPath methods.
A table view object invokes the cellForRowAtIndexPath method every time it needs to display a table row.
application delegate:
The main function of this didFinishLaunchingWithOptions method is to instantiate a data controller object and assign it to the dataController property of the master scene. But before it can make this assignment, the method must first get a reference to the master view controller.
To get a reference to the master scene’s view controller, the didFinishLaunchingWithOptions method uses its window property to retrieve the window’s root view controller object.
detail view controller:
The viewDidUnload method is the proper place to clean up any strong references the view might have.
add item view controller:
Embedding a scene in a navigation controller also has the following advantages:
1. It ensures that the navigation bar doesn’t scroll off the screen if the main content view scrolls.
2. It makes it easy to extend the current design to transition to additional scenes from the add scene.
Note: If Xcode does not automatically assign the instance variables to _variableName (that is, birdNameInput = _birdNameInput), you should do so.
if you want to creates a world, you must know what’s the basic element of that world.
最近一直在考虑，设计一个以中文，汉字为基础的计算机语言。看了一些书，有心得如下：
1. 语言本身。语法设计的时候，可以不断改进，从而提供更好的，更简单，方便的使用。例如 ruby 的 block。
2. 虚拟机。这代表了你希望该语言运行的平台。jvm是其中的代表作。
3. OS。实现虚拟机到真实机器的转变，这才是关键。
新语言：
1. 以中文为关键字。
2. 最小 语言 逻辑。
3. 需要一个假象的运行平台，所以需要一个虚拟机。其实，这主要是确定虚拟机的功能。
4. 只是作为一个脚本语言或者ANSI C的扩展，翻译成ANSI C即可。
虚拟机功能：
1. 计算…
2.
计算：
模拟算盘，建立算法。
