iOS 9 Human Interface Guidelines: UI Design Basics

1.1 Designing for iOS

iOS embodies the following three design principles:

• Deference: The UI should help users better understand and interact with the content, and not distract from the content itself.
• Clarity: Text of all sizes should be clear and easy to read; icons should be precise and eye-catching, remove unnecessary decorations, highlight the key points, and drive the design with function.
• Depth: Visual layering and vivid interactive animations give the UI new vitality, helping users better understand and making them feel happy during use.

Whether you are redesigning an existing app or developing a new one from scratch, consider the following approaches when designing:

• First, remove UI elements to highlight the core functions of the application and clarify the dependencies between them.
• Then, use the iOS theme to define the UI and perform user experience design. Improve the details and make appropriate modifications.
• Finally, make sure that the UI you design can adapt to various devices and various operating modes so that users can enjoy your application in different scenarios.

Throughout the design process, be prepared to overturn precedents, question assumptions, and focus on content and function to drive every detail.

1.1.1 Defer to Content

Although the fresh and beautiful UI and smooth dynamic effects are the highlights of the iOS experience, content is always the core of iOS.

Here are some ways to ensure your design both enhances the functional experience and keeps the focus on the content.

Make full use of the entire screen. The system weather app is a great example of this approach: a beautiful full-screen weather picture presents the current weather, which directly conveys the most important information to the user, while also leaving space to present weather data for each time period.

Reconsider (minimize) the use of skeuomorphic design. Masks, gradients, and shadows can sometimes make UI elements look heavy, distracting from the content. Instead, focus on the content and let the user interface support the content.

Use translucent UI element styles to hint at the content behind. Translucent control elements (such as the control center) can provide contextual usage scenarios, help users see more available content, and serve as a short prompt. In iOS, translucent control elements only blur the area they cover - it looks like a layer of rice paper - it does not cover the rest of the screen.

1.1.2 Provide Clarity

Another way to ensure your app remains centered around content is to ensure clarity. Here are a few ways to make the most important content and functionality visible and easy to interact with.

Use plenty of white space. White space can make important content and features more eye-catching and easier to understand. White space can also convey a psychological feeling of calm and tranquility, which can make an app look more focused and efficient.

Let color simplify the UI. Use a theme color—such as yellow in Notes—to highlight important blocks of information and subtly use style to imply interactivity. At the same time, it also gives the application a consistent visual theme. Built-in applications use the same series of system colors, so that they look clean and pure on dark or light backgrounds.

Ensure legibility by using system fonts. The iOS system font (San Francisco) uses Dynamic Type to automatically adjust letter and line spacing to make text legible at any size. Whether you use a system font or a custom font, be sure to use Dynamic Type so that your app can respond when the user selects a different font size.

#p#

Use borderless buttons. By default, all buttons on the bar are borderless. In the content area, use copy, color, and operation guide titles to indicate the interactivity of the borderless button. When it is activated, the button can display a narrow border or a light background as an operation response.

1.1.3 Use Depth to Communicate

iOS often presents content in different view levels to express hierarchy and position, which helps users understand the relationships between objects on the screen.

For devices that support 3D touch, Peek, Pop, and Quick Actions allow users to preview other important content without leaving the current interface.

By using a semi-transparent background overlay above the home screen, folders can clearly distinguish their contents from other content on the screen.

As shown in the figure, Reminders displays content items in different levels. When the user uses an item in the Reminders, the other items will be folded together at the bottom of the screen.

The calendar has a deeper hierarchy, and when users flip through the year, month, and day, the enhanced transition animation effect gives users a sense of depth. When scrolling the year view, users can instantly see today's date and other calendar tasks.

When the user selects a month, the year view partially zooms in on that month and transitions to the month view. Today’s date remains highlighted, and the year is displayed where the back button is, so the user knows exactly where they are, where they came from, and how to get back.

Similar transition animations also appear when the user selects a date: the month view separates from the selected position, pushes the weekday to the top of the content area, and displays the timeline view of the day in hours. These interactive animations enhance the hierarchical relationship between year, month, and day and the user's perception.

#p#

1.2 iOS App Anatomy

Almost all iOS apps use components defined in the UIKit framework. Understanding the names, roles, and functions of these basic components can help you make better decisions during the app interface design process.

The UI components provided by UIKit can be roughly divided into the following four types:

• Bars: Contain contextual information to guide users where they are, and controls to help users navigate or perform actions.
• Content Views: Contains the specific content of the application and certain operating behaviors, such as scrolling, inserting, deleting, sorting, etc.
• Controls: Used to perform actions or display information.
• Temporary Views: They appear briefly to give users important information or provide more options and functions.

In addition to defining UI component elements, UIKit also defines how objects implement functions, such as gesture recognition, drawing, accessibility, and printing support.

From a programming perspective, UI component elements are actually subclasses of views because they inherit UIView. Views can draw screen content and know when the user touches the screen within their boundaries. All types of views are: controls (such as buttons and sliders), content views (such as collection views and table views), and temporary views (such as alerts and action menus).

To manage a group or series of views in an application, you usually need to use a view controller. It coordinates the display of the view content, implements the functions of interacting with the user, and switches between different screen contents. For example, "Settings" uses a navigation controller to display its view hierarchy.

Here’s an example of how views and view controllers combine to present the UI of an iOS app, as shown in the figure.

Although developers think that what really matters are views and view controllers, the average user perceives an iOS app as a collection of different screen contents. From this perspective, in an app, screen content generally corresponds to a unique visual state or mode.

Note: An iOS application consists of one window. However, unlike windows in computer programs, iOS windows have no visible parts and cannot be moved to another location on the screen. Many iOS applications have only one window; applications that can support external display devices can have more than one window.

In iOS Human Interface Guidelines, the word screen is the same as what most users understand. As a developer, you may need to read other chapters related to UIscreen so that you can better understand how to relate to external screens.

1.3 Adaptivity and Layout

1.3.1 Build In Adaptivity

People often want to use their favorite apps on all their devices and in multiple contexts, such as in different device orientations and split-screen on an iPad. Size classes and Auto Layout can help you do this by defining how the layout of screens, view controllers, and views should adapt when the environment changes. (The concept of a display environment refers to the entire device screen or a portion of it, such as the area of ​​a popup or one side of an iPad split-screen view.)

iOS includes the concept of display environments in the definition of trait collections, which include size classes, display scales, and user interface idioms. You can use a trait collection to make your views and view controllers respond to changes in the display environment.

iOS defines two size classes, regular and compact. Regular sizes are closely related to extended space, while compact sizes are related to constrained space. To define a display environment, you need to define a landscape size class and a portrait size class. As you might expect, an iOS device can use one set of classes in portrait mode and another set of classes in landscape mode.

iOS can automatically generate different layouts as the size class and display environment change. For example, when the vertical size changes from compressed to regular, the navigation bar and toolbar will automatically grow taller.

When you rely on size classes to drive layout changes, your app looks great on any display environment. For more information on how to best use size classes in Interface Builder, see Size Classes Design Help.

Note: Within a size class, consistently use Auto Layout to make small layout adjustments, such as stretching or compressing content. For more information about Auto Layout, see Auto Layout Guide.

The following examples can help you visualize how size types adapt to the display environment of different devices. For example, iPad (including iPad Pro) uses regular size types in both length and width and landscape and portrait orientations. In other words, the iPad display environment is always in a normal vertical and horizontal state.

Note: Qualified iPad models support multitasking, and your app may need to share the same screen with other apps. Make sure to use Auto Layout so that you can respond to users when they use multitasking features, such as Split View and Slide Over.

In addition to using Auto Layout, when you’re displaying readable content on an iPad Pro, it’s important to rely on the readableContentGuide property of UIView so that you have margins that are comfortable for the reader.

The iPhone's display environment can change depending on the device and the different holding orientations.

When in portrait orientation, the iPhone 6 Plus uses a compressed width and regular height type.

When in landscape orientation, the iPhone 6 Plus uses the regular width and compressed height type.

Other iPhone models, including the iPhone 6, use the same size type settings.

In portrait orientation, iPhone 6, iPhone 5, and iPhone 4S use a compressed width and regular height.

When in landscape orientation, these devices use compressed classes for both width and height.

1.3.2 Provide a Great Experience in Each Environment

When you develop your UI using responsiveness, you can ensure that your UI responds appropriately to changes in the display environment. By following these guidelines, you can give your users a good device responsiveness experience.

Maintaining focus on the main content in all circumstances is a top priority. When people use an app, they browse and interact with content that interests them. Shifting focus as the environment changes can make users feel disoriented and make them feel like they have lost control of the app.

Avoid unnecessary changes in layout. Maintaining a consistent experience in all environments allows people to maintain stable usage patterns when they rotate their device or run your app on different devices. For example, if you use a grid to display images in horizontal regular mode, there is no need to use a list to display the same content in compact mode, even if you might adjust the size of the grid.

If your app only works in one orientation, be direct. People expect your app to work in all kinds of holding styles, and it’s best to meet that expectation. However, if your app only works in one orientation, you should be aware of:

• Avoid UI elements that prompt people to rotate their device. Make it clear that your app works in supported orientations, and don’t add unnecessary clutter to your UI if you need to rotate the device.
• Support changes in the same direction. For example, if an app can only run in landscape mode, the user can reach the home button whether holding the app with the left or right hand. If the user rotates the device 180 degrees while using the app, it is best if the app content can also respond and rotate 180 degrees in time.

If your app treats a device orientation flip as user input, respond to the device flip as programmatically. For example, if a game lets users flip the device to move game pieces, the game app itself shouldn't respond to flipping the screen. In this case, you must associate the two orientations that need to change and allow people to switch between them until they start the main task of the app. Once people start to perform the main task, start responding to the device's actions as programmatically.

1.3.3 Use Layout to Communicate

Layout encompasses more than just the appearance of UI elements on an app screen. Your layout should tell users what’s most important, what their options are, and how things relate to each other.

Emphasize important content or functions, so that users can easily focus on the main task. There are several good ways to place the main content in the upper half of the screen - follow the left-to-right habit - starting from the left side of the screen:

Use different visual weights and balance to communicate the importance of the elements on the screen. Large controls draw the eye and are more likely to be noticed than smaller controls when they appear. Large controls are also easier for users to tap, making them particularly useful in apps — like the phone and clock (buttons above) — that keep users engaged despite distracting environments.

Use alignment to make reading easier and to create order between groups and hierarchies. Alignment makes the app look neat and organized, and makes it easier for users to locate and focus on important information as they scroll through the entire screen. Indenting and aligning different groups of information makes the connections between them clearer and makes it easier for users to find a control.

Make sure that the main content and meaning of the content are clear to users at the default size. For example, users should be able to see important text without scrolling horizontally, or see a main image without zooming in.

#p#

Be prepared for font size changes. Users expect most apps to respond to the font size they set in iOS settings. You may need to adjust your layout to accommodate some text size changes; for more information on text display, see "Colors and Fonts" below.

Try to avoid inconsistent UI. In general, controls with similar functionality should look similar. Users often assume that there is a reason for the differences they see, and they tend to spend time trying.

Give each interactive element ample space so that users can easily operate these contents and controls. The commonly used size of tap-type controls is 44 x 44 points.

1.4 Starting and Stopping

1.4.1 Start Instantly

We generally assume that users won’t spend more than a minute or two evaluating a new app. When you can maximize this short time by presenting helpful content to users in real time, you can spark interest among new users and provide a great experience for all users.

Important: Do not tell the user that they need to reboot their device after the installation process. Rebooting takes time and makes your app seem unreliable and difficult to use.

If your app has memory usage or other issues that prevent it from running smoothly without restarting, you must declare these issues. For information about how to develop an app with good performance, see Use Memory Efficiently.

Avoid using splash screens or other startup experiences as much as possible. It’s best if users can start using your app immediately after launching it.

As much as possible, avoid asking users to do too much configuration. Instead:

• Focus on the needs of 80% of your target users. This way, most users don't need to set various options, because your app is already in the state they want by default. If some functions are only wanted by a small number of users, or most users only need to use them once, then forget it.
• Whenever possible, try to obtain as much user information as possible through other means. If you can obtain information provided by the user in built-in applications or hardware settings, obtain it directly from the system and do not require the user to enter it again.
• If you must ask users to set user information, prompt them directly in your app. Then save these settings as soon as possible (generally, save them to your app's settings module). This way, users don't have to jump out of your app and go to the system settings page. If users need to change their settings, they can go to the app's settings module to modify them at any time.

Allow users to log in as late as possible. Ideally, users should be able to browse as much content and use some features as possible without logging in. For example, the App Store will only ask users to log in when they decide to purchase something. For apps that force users to log in before they can perform any useful operations, users often give up directly.

If your app requires a login before use, you should have some brief text on the login page to describe why you must log in first and what benefits doing so will bring to the user.

Use onboarding (introducing the app's features and how to use them) with caution. Before considering onboarding, you should work hard to improve your app and make its features as intuitive and easy to find as possible. In fact, good apps don't need onboarding. If you do feel that you need an onboarding, please refer to the following suggestions to design an onboarding that is concise, targeted, and does not hinder users.

• Provide only the information necessary to start using your app. A good onboarding guide should tell users what to do first, or briefly demonstrate some features that most users are interested in. If you show users too much information before they can explore your app, and ask them to remember content that is not currently necessary, it will make them feel that your app is difficult to use. If additional help is really needed in some specific scenarios, it should only be provided after the user is in this scenario.
• Use animation and interactive methods to attract users and let them learn how to use it through actual operations. Be cautious when adding text content, and only do so when adding text is beneficial to improving the experience. Don't expect users to read long paragraphs of text. For example, you can use animation instead of text to describe how to perform a simple task. When guiding users to understand more complex tasks, you can use some guide floaters to briefly explain what users need to do in each step. Avoid showing screenshots of the app as much as possible, because screenshots are not interactive and users may confuse screenshots with the actual interface of the app.
• Allow users to easily cancel or skip the onboarding. Some users don’t want to watch the onboarding again after watching it, and some don’t even want to watch it at all. Remember the user’s choice and don’t force the user to choose it again every time they open your app.

Don't ask users to rate your app too early. Asking users to rate too early can backfire. If you want to get valuable feedback and reviews, give users some time to use your app and form an impression of it before asking them to review. For example, you can wait until users have visited a certain number of pages or completed a certain number of tasks before asking them to review.

It is generally recommended to launch your app in the default orientation of the screen. However, if your app has only one screen orientation, always launch it in that orientation and let the user change the device orientation when they need to. For example, a game or media viewing app that only runs in landscape mode should be launched in landscape mode, even if the device is currently in portrait mode. That way, if the user opens the app in portrait mode, they know to turn the device to landscape mode to use it.

Note: It is best to make landscape apps support both landscape orientations, that is, the home button on the left or the right. If the device is already in landscape mode, launch the app in that state unless you have a good reason not to do so. Otherwise, consider launching the app with the home button on the right. (For more information about supporting different device orientations, see the Adaptivity and Layout section above.)

Provide a splash screen that looks the same as the homepage of your app. iOS will call this image when launching your app, which can make users feel that the startup speed is very fast, and at the same time, it can also give your app enough time to load content. For details on how to make a splash screen, please refer to Launch Files.

If possible, don’t ask users to read a disclaimer or confirm a user agreement when they first launch your app. You can display these contents directly on the App Store so that users know about them before downloading. If you must display these contents in some cases, make sure they are consistent with the interface and strike a balance between product functionality and user experience.

After your app is relaunched, you need to restore it to the state that the user left in, allowing them to continue where they left off. There’s no need for the user to remember how to get back to that state. For more information on effective ways to preserve and restore your app’s state, see Preserving Your App’s Visual Appearance Across Launches.

1.4.2 Always Be Prepared to Stop

There is no option to close or exit an iOS app. When a user switches to another app, returns to the home screen, or puts the device to sleep, they are actually stopping the current app.
When the user switches apps, iOS's multitasking system puts them in the background and replaces the new app's UI. In this case, you must do the following:

Save user information at any time and as soon as possible, because the application in the background may be terminated or exited at any time.

Save as many details about the current state as possible when your app is stopped. This allows users to continue working with your app right where they left off when they return to it. For example, if you are using a scrollable list of data, save the position of the list after exiting. For more information on effective ways to preserve and restore your app's state, see Preserving Your App's Visual Appearance Across Launches.

Some apps may need to run in the background all the time. For example, a user may want to be able to use one app while listening to music, and then want to use another app to check a to-do list or play a game. For more information on how to handle multitasking correctly, see Multitasking.

Don't force the app to quit. This will make the user think the system crashed. If a problem occurs, you need to tell the user what happened and how to fix it. Here are two suggestions, depending on how serious the problem is:

If all the features in your app are currently unavailable, you should display some content to explain the current situation and suggest how the user should proceed. This part of the content gives users feedback and reassures them that your app is now OK. It can also calm users and allow them to decide whether to take corrective action, continue using the app, or switch to another app.

If only some features are unavailable, then you only need to display a prompt when the user wants to use those features. Otherwise, the user should be able to use the rest of the app normally. If you decide to use an alert box to prompt, make sure to only display it when the user tries to use the unavailable features.

1.5 Navigation

Unless the navigation design is unreasonable, users should not be able to notice the navigation experience in your app. The navigation design should support your app's structure and purpose without distracting users.
Broadly speaking, there are several types of navigation, each with its own application structure:

• Layering
• Flat
• Content or experience driven

In a hierarchical application, users have to select an item in each level until they reach the destination level. If they want to switch to another destination level, users must go back some levels or return to the initial level to select again. System Settings and Mailbox applications are good examples in this regard, you can refer to them.

Translator’s note: The above are screenshots of the video. Click here to watch the full video.

In an app with a flat information architecture, users can switch directly from one home category to another because all categories are directly accessible from the home screen. Music and App Store are two good examples of apps that use a flat structure.

Translator’s note: The above are screenshots of the video. Click here to watch the full video.

In a content- or experience-driven information architecture application, navigation is also designed based on the content or experience. For example, when reading an e-book, users read page by page, or directly select a specific page from the table of contents; similarly, navigation in a game is also an important part of the experience.

Translator’s note: The above are screenshots of the video. Click here to watch the full video.

In some cases, it can be useful to combine multiple navigation types in one app. For example, a flat information structure might be better displayed as a layered navigation.

Users should always know where they are in the app and how to get to their destination. No matter which navigation is suitable for your app structure, the most important thing is that the path users take to access content is logical, predictable, and easy to trace.

UIKit defines some standard UI elements to easily build hierarchical or flat navigation, and some elements to build content-centric navigation, such as e-books or media viewing applications. Games or other experience-driven applications usually require some custom elements and behaviors.

Use a navigation bar to help users easily navigate hierarchical content. The title of the navigation bar can show the current level of the hierarchy, and the back button can return to the previous level. For more information, see Navigation Bar.

Use a tab bar to display similar content or features. Tab bars are ideal for flat information structures, allowing users to switch between categories without worrying about their current location. For more information, see Tab Bar.

In an application, if each screen displays items or pages of the same type, you can use a page control. The advantage of a page control is that it can intuitively tell the user how many items or pages there are, and where they are currently. For more information, see Page Control.

Generally speaking, it is best to provide users with a unique path to each screen. If users need to view a screen in different scenarios, consider using a temporary view, such as a modal view, action menu, or alert box. For more information, see Modal View, Action Sheet, and Alert.

UIKit also provides the following related controls:

• Segmented Control: Segmented Control allows users to find content of different categories on one screen without switching to other screens.
• Toolbar. Although similar to a navigation bar or tab bar, a toolbar does not have a navigation function. Instead, it provides users with controls that allow them to manipulate the current screen content.

(Translator's note: The Navigation Bar, Tab Bar, Page Control, Modal View, Action Sheet, Alert, Segmented Control and Toolbar mentioned above are all in Chapter 4, UI Elements of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently.)

#p#

1.6 Modal Contexts

Modal is a mode that carries some coherent operations or content with both advantages and disadvantages. It can provide users with a way to complete a task or obtain information without leaving the main task, but it can also temporarily prevent users from interacting with other parts of the application.

Ideally, users can have a non-linear interaction with iOS applications, so it is best to reduce the modal experience in your application as much as possible. Generally, you can only consider using modals in the following situations:

• When you need to attract user attention
• A separate task needs to be completed or clearly needs to be abandoned, in order to avoid missing user information in an ambiguous state

Keep modal tasks simple, short, and focused. You don’t want users to feel like they are using a mini-app within your app when using a modal view. If subtasks are too complex, users may lose sight of the main task when entering the modal context. This is especially important when designing a modal task that involves visual hierarchy, because users may get lost and forget how to get back to the previous action. If a modal task must include subtasks in different views, make sure to give users a separate, clear navigation path and avoid detours. For more information about modal views, see Modal View.

Always provide an obvious, safe way to exit a modal task. Make sure users can anticipate the outcome of their actions when exiting a modal view.

When a task requires multiple levels of modal views, make sure users understand the consequences of clicking a Done button in a lower-level view. Does clicking a Done button on a lower-level view complete part of the task in that view, or the entire task? Because of the potential for this confusion, avoid adding Done buttons in lower-level views whenever possible.

Make sure the content of the alert dialog box is necessary and actionable. Alert dialog boxes interrupt the user experience and will not disappear until clicked, so make the user feel that the alert information is useful and the interruption is valuable. For more information, please refer to Alert.

(Translator's note: The Modal View and Alert mentioned above are both in Chapter 4, UI Elements, of the iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently.)

Respect the user's preferences for receiving notifications. Users will set the form in which they receive notifications from your app. Make sure to respect the user's preferences. Otherwise, you may annoy the user and cause him to turn off all push notifications from your app.

1.7 Interactivity and Feedback

1.7.1 Interactive Elements Invite Touch

To hint at interactivity, many clues are used in design, including click feedback, color, position, context, clear icons and labels, etc. It is not necessary to over-embellish elements to show users interactivity.

On devices that support 3D Touch, when users press an icon on the home screen, the background blurs to suggest that more functions can be selected.

A key color can provide a strong visual cue for users, especially when there are no redundant other colors. Use blue to mark interactive elements for contrast while providing a unified, recognizable visual style.

The back button uses multiple cues to indicate that it is interactive and communicate its function: it appears in the navigation, displays an icon pointing backward, uses a key color, and displays the title of the previous page.

An icon or title provides a clear name to guide users to click it. For example, the title "Flyover Tour" and "Directions to Here" in the map clearly explain the actions that users can take. Combined with the key color, you can omit the button border or other unnecessary decorations.

In the content area, you can add borders or backgrounds to buttons when necessary. Buttons in bars, action sheets, and alerts do not need borders because users know that most options in such areas are interactive. But in the content area, it is necessary to use borders or backgrounds to distinguish buttons from other content. For example, music, clock, photos, and App Store use such buttons in some special scenarios.

A border is added to the sharing button in photo management, which is distinguished from other explanatory texts.

The clock adds background to the buttons in the stopwatch and timing pages to emphasize the start and pause buttons and makes the buttons easier to click in distracting content.

The application store uses bordered buttons to distinguish the button from the entire content bar, click the entire content to view the detailed information, and click the button to download and install.

#p#

1.7.2 Users Know the Standard Gestures

Users use gestures such as click, drag, and pinch to interact with applications and their IOS devices. Using gestures brings the distance between users and devices closer and enhances direct manipulation. Users usually expect gestures to be universal between different applications.

Users do not need to learn additional gestures when using 3D Touch. When users tap the screen and get feedback, it is easy to discover the additional interaction methods provided by 3D Touch.

In addition to standard gestures that users are familiar with, iOS also defines some system-wide operations, such as the Control Center or the Notification Center. Users can use these gestures under any application.

Don't give standard gestures different behaviors. Unless your app is a game, redefining standard gestures will confuse users and increase the difficulty of using them.

Do not create gesture operations similar to standard gesture functions. Users are used to the behavior of standard gestures, and there is no need to let the user learn different gestures to achieve the same operation results.

Complex gestures can be used as a shortcut to complete a task, but not the only way to reach it. It is best to provide users with some simple and direct way to complete an operation, even if this method requires them to click one or two extra times. Simple gestures can allow users to focus on the current experience and content rather than the interaction itself.

Unless it is a game, avoid defining new gestures. In games or other immersive applications, operating gestures are also part of the fun experience. However, in ordinary applications, helping users achieve goals is much more important than the operation itself, so it is best to use standard gestures to avoid letting users discover and remember new actions.

In a specific environment, you can consider using multi-finger operations. Although complex operations are not necessarily suitable for all applications, it can enrich the experience for applications that users spend a lot of time using, such as gaming or content creation environments. However, because non-standard gestures are poorly discovered, try to use as little as possible and don't let these gestures be the only way to complete tasks.

1.7.3 Feedback Aids Understanding

Feedback helps users understand what the app is doing, discover what can be done next, and understand the results of their actions. UIKit's actions and views provide a lot of feedback types.

Integrate status or other feedback information into the UI as much as possible. It is best for users to get the information they need without performing operations or jumping out of the current content. For example, the mailbox displays the current status on a toolbar that does not affect the current content.

Avoid displaying unnecessary reminder dialogs. Dialogs are a strong feedback mechanism and only need to use them when passing very important and actionable information. If users often see many dialog boxes without important information, they will quickly ignore all dialog reminders. For more information, please refer to Alert. (Translator's note: Alert is in the UI Elements section of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please be patient.)

1.7.4 The method of inputting information should be simple (Inputting Information Should Be Easy)

Whether the user clicks on controls or uses the keyboard, it takes time and effort to enter information. Having the user enters a large amount of information before it is effective will weaken the user's desire to continue using it.

Make it easier for users to make choices. For example, use selectors or tables instead of plain text, because most users find it easier to choose from a list than to type.

Get information from iOS in time. A large amount of user information is stored on the device. If so, don't let users provide information you can easily find, such as contact or calendar information.

Provides useful feedback to balance user input. The concepts of giving and reward can help users feel that the process is being advanced during use.

1.8 Animation

Subtle, exquisite animations are spread throughout the iOS user interface, and they make the app experience more attractive and dynamic. The appropriate animation can:

• Communicate status and provide feedback
• Enhance direct manipulation
• Visualize user operations

(Translator's note: The above is a video screenshot. Please click to watch the complete video)

Add animation carefully, especially in applications that do not provide an immersive experience. Too much and unreasonable animation can hinder the smoothness of the application, reduce performance, and distract the user from the operation.

In particular, you must use animation and dynamic controls in UIKit in a purposeful manner and ensure that the results are tested. Using animation rationally can improve the user's understanding and pleasure; applying excessive use of animation will bring confusion and uncontrollable feeling to users.

If possible, keep the consistency of custom animations and built-in animations. Users are used to fine animations used by built-in iOS apps. In fact, users tend to smoothly switch between views, smooth corresponding changes in device orientation and physically based scrolling effects as part of the iOS experience. Unless your app wants to provide users with an immersive experience similar to game applications, custom animations can be distinguished from built-in animations.

Use animations with consistent styles. Consistency is also required between custom animations, so that users can base their experiences on their previous experiences when using the app.

Generally speaking, custom animations take into account the reality and credibility of the animation. People are willing to accept free artistic creation, but users will be confused when the animation is unreasonable or violates physics. For example, when you slide down from the top of the screen, you also need to slide up and put it away, because doing so can help the user remember where the view comes from. If you slide down to the bottom of the screen to close the view, the user's mental model about the call from the top of the screen will be broken.

1.9 Branding

Successful branding involves not just adding brand elements to the app. Excellent apps should provide users with a pleasant and memorable experience by creating a unique look and feel.

It is easy to use custom icons, colors and fonts to create UIs that differ from other applications under iOS. When you design these elements, keep the following two points in mind:

• Each custom element itself needs to have a good look and functionality, but it should also be consistent with other elements in the application, whether other elements in the application are custom or standard.
• To feel comfortable in iOS, your app doesn't have to look like it's built-in, but it needs to be integrated with compliance, clarity, and depth (see 1 Design for iOS for more). Take the time to figure out what compliance, clarity, and depth in your app means and express them in your custom elements.

When you need to make your users aware of your brand, you should follow the following points:

Insert brand elements in a refined and elegant way. Users use your app to complete business or entertain themselves, and they do not want to be forced to watch ads. To get the best user experience, you can subtly remind users of your brand identity through the design of fonts, colors and images.

Avoid staying away from content that users care about. Instead of keeping brand-specific content on the secondary bar at the top of the screen like the counterexample in the picture above, so that the text content space is compressed, consider displaying the brand everywhere in other low-invasive ways, such as using custom colors, fonts, or cleverly customizing the background of the screen.

Resist the temptation and don't run your logo throughout the app. Most of the screens on mobile devices are quite small, and every time the logo appears, it takes up space, thereby isolating users from what they want to see. Moreover, displaying logos in apps does not achieve the same purpose as displaying logos in web pages: it is usually easy for users to access a web page without knowing which web page belongs, but very few users will open it without looking at an app icon in iOS system at all.

1.10 Color and Typography

1.10.1 Color Enhances Communication

In iOS, colors are used to indicate interaction, deliver activity, and provide visual continuity. The built-in application chooses to use pure, clean colors that look more personal, supplemented by a combination of light or dark backgrounds.

If you are creating a variety of custom colors, make sure they coexist harmoniously. For example, if your app's basic style is soft tones, you should create a coordinated soft tones color palette for the entire app.

Pay attention to color contrast in different situations. For example, if there is not enough contrast between the background of the navigation bar and the bar button title, the button will be hard to see by the user. A quick but not rigorous approach is to test whether the colors on the device have sufficient contrast by placing the device in different lighting environments, including a clear outdoor.

Although viewing your application on the device can help you find some of the adjustments, it still cannot replace a more scientific and objective method that produces reliable results. This method involves determining whether the brightness values ​​of the foreground and background colors meet a certain ratio. This ratio value can be calculated by the online contrast calculator or by the formula provided in the WCAG2.0 standard. The ideal color contrast in your application should be 4.5:1 or higher.

When you use custom bar colors, focus on translucent bars and app content. When you need to create bar colors that match special colors (such as colors in an existing brand), you may need to experiment with various colors before you get the results you want. The display of bars will be affected by the rendering of translucent bars provided by iOS and the app content hidden behind the bar.

API Note: Use the attribute value of the light color (tintColor) to give the color of the column button, and use the attribute value of the light color (barTintColor) to give the color of the column itself. For more information about the column properties, see UINavigationBar Class Reference, UITabBar Class Reference, UIToolbar Class Reference, and UISearchBar Class Reference.

Pay attention to the blind spots of colors. Most people with color blindness have difficulty distinguishing between red and green. You need to test your application to ensure that you do not use red and green as the only way to distinguish two different states or values. Some image editing software or tools can effectively help you verify the blind spots of colors. In general, it is very good to use multiple ways to characterize the interactivity of primary colors (for more information on characterizing interactivity in iOS, see Interactive Elements Invite Touch).

Consider choosing a base color to characterize interactivity and state. The built-in base color includes yellow in memos, red in calendar, etc. If you define a base color to characterize interaction and state, make sure that other colors in your application do not conflict with it.

Avoid using the same color for interactive and non-interactive elements. Color is one way to indicate the interactive properties of UI elements. If interactive and non-interactive elements use the same color, it will be difficult for users to determine which areas are pointable.

Colors can convey information to users, but they may not necessarily be the way you want them to. The colors in everyone's eyes are different, and different cultures give different meanings to colors. Take the time to study how to use colors to be accepted by other countries or cultures. You should determine as much as possible the colors used in the application conveys the appropriate information to users.

In most cases, colors cannot be distracted by the users. Unless colors are the purpose and essence of the application, colors should usually be used to improve the user experience from the details.

1.10.2 Great Typography Enables Clear Communication

Apple has designed San Francisco fonts for the entire platform to provide an elegant and consistent layout and reading experience. In iOS 9 and future versions, San Francisco is a system font.

San Francisco paired with Dynamic Type can provide you with:

• A range of font sizes, with excellent clarity and an excellent reading experience in any user settings, including accessibility settings.
• The ability to automatically adjust the thickness of the text, the spacing of letters and the height of the line.
• Specify different text styles for semantically different text modules, such as body, footnote, or title.
• The ability of text to respond appropriately to changes in font sizes specified in the font size settings and accessibility settings

Download San Francisco to access https://developer.apple.com/fonts/. (Note: The San Francisco font in iOS9 is named SF-UI). When you use San Francisco in your app, you can adjust the values ​​in the Simulator > Settings to test the text of your app at different sizes.

Note: If you are using custom fonts, you can still use Dynamic Type or plan the font range according to the system's font size settings. When users change settings, your application must also be responsive. To learn how to use text styles and ensure that your application can get notifications when users change text model settings, please refer to Text Styles.

San Francisco has two types of sizes: Text mode and Display mode. Text mode is suitable for sizes less than 20 points, and Display mode is suitable for sizes greater than 20 points. When you use San Francisco in your app, iOS will automatically switch between text mode and display mode at the appropriate time.

Note: If you use an application such as Sketch or Photoshop to generate your design, then when the font you set is no less than 20 points, you need to switch to display mode. iOS will automatically adjust the word spacing according to the font size. (The word spacing is used to modify the text spacing). Tables 10-1 and 10-2 are the spacing values ​​for text mode (Text) and display mode (Display) under different font sizes, respectively.

To highlight certain texts or to create visual associations between content blocks, you can rely on semantic styles supported by Dynamic Type, such as titles and texts, and you can also specify font weights, such as fine or semi-coarse. Use Dynamic Type styles to make your content better express meaning, but if you want to have better control over your design, you can set specific weights for specific texts. (For more on adjusting font weights, see UIFont Class Reference.)

For example, you may want to increase the weight of certain texts to help users visualize the hierarchy of your content, or to attract users' attention to specific words or phrases. In addition, you can create visual cohesion in multiple adjacent labels of different font sizes by increasing the weight of smaller texts and reducing the weight of larger texts. Font weights have an important influence on the overall style and expression of the content, so you can choose specific weights to achieve design purposes.

Responsive changes in text size need to prioritize content. Not all content is equally important to users. When users choose larger text sizes, they want to make the content they focus on easier to read; they don’t always want every word on the screen to be larger.

For example, when a user selects a text size that has greater ease of use, the email will display the subject and content of the email in a larger size, while for less important information—such as time and recipients—are smaller.

Make sure that all types of a custom font are readable in different sizes. One way to achieve this is to emulate some ways in which iOS systems render font styles at different text sizes. For example:

• Text should never be smaller than 11 points, even if the user chooses a very small text size. In comparison, the content style uses a 17-point font size as the large size, which is also the default text font size.
• Generally speaking, the font size and line spacing value differ by 1 point in the text size setting for each stitch. The only exception is the two styles of titles, which use the same font size, line spacing, and kerning in the small, small and medium size settings.
• Among the smallest three text sizes, the word spacing is relatively large; among the largest three text sizes, the word spacing is relatively compact.
• The styles of the title and content use the same font size, and at the same time, to distinguish the title from the content style, the title style uses a heavier value.
• The text in the navigation control bar uses the same font size, while the style of the content text uses a large size setting (value of 17 points).
• Text is always used in regular or moderate heavy, and generally not suitable for light or bold.

Typically, the application should use a single font as a whole. The mix of multiple fonts will make your application look fragmented and sloppy. Instead, use one font and a few styles. Depending on the semantic purpose, use the UIFont class API to define styles for different text areas, such as body or title.

1.11 Icons and Graphics

1.11.1 The App Icon

Each application needs a beautiful icon. Users often establish a first impression of the application when they see the application icon and use it to judge the quality, function and reliability of the application.

The following points should be remembered when designing app icons. When you are sure to start designing, please refer to App Icon for more detailed design specifications and guidance. (Translator's note: App Icon is in the Icon and Image Design section of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently.)

• App icons are an important part of the entire app brand. Use icon design as an opportunity to tell the story behind the app and establish an emotional connection with users.
• The best app icons are unique, neat, touching and impressive.
• A good application icon should be equally beautiful in different backgrounds and specifications. The details added to enrich the texture of large-size icons may make the icons unclear when they are small.

#p#

1.11.2 Small Icons

iOS provides a series of small icons to represent various common tasks and operations, which are commonly used in the Tab Bar, Toolbars, and Navigation Bar. Users usually already understand the meaning of these built-in icons, so they can use as many of them as possible.

If you need custom actions or content, you can also design custom icons. Designing these small linear icons is very different from designing application icons. Please refer to Bar Button Icons for more information. (Translator's note: The Bar Button Icons chapter is in the Icon and Image Design section of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently)

Please note that sometimes you can use text instead of icons in the toolbar and navigation bar. Just like in the iOS calendar, the toolbar uses "Today", "Calendar" and "Inbox" to replace icons for meaning.

To decide whether to use icons or text in the toolbar and navigation bar, you can prioritize how many icons will appear at most in a screen at the same time. Too many icons in the same screen may make the entire application difficult to understand. Using icons or text also depends on whether the screen is in a horizontal view, because there is usually more space to carry more text.

1.11.3 Graphics

Most iOS apps are rich in graphics. Whether you need to show your user's photos or create custom images, the following requirements should be followed:

• Supports Retina displays. Make sure all image resources in your app provide high resolution specifications. It is particularly important to note that the iPhone 6 Plus needs to provide @3x-specification images, while all other high resolution iOS devices need to provide @2x-specification images.
• Use the original size when displaying a photo or picture and do not stretch it to more than 100%. You won't want to see stretched and deformed pictures in your app. You can let users choose whether they want to scale the picture.

Do not use graphics copied from Apple's range of products. These graphics are copyrighted and the design of the product may change frequently.

Do not use Apple's app icons, images, or screenshots for your design. All Apple's designs are copyrighted and are not allowed to appear in your UI unless they are provided directly by the system.

1.12 Terminology and Wording

Every word you present in the app is part of a conversation with the user. Seize such conversation opportunities to provide your users with a clear expression and pleasant experience.

Settings is a basic application for all users, so it uses concise language to describe the operations that users can do. For example, Settings → Do Not Disturb does not use complex technical terms that are difficult to understand, but uses simple language to describe a series of operations to the user.

Make sure that the terms you use are understandable to the user. Decide what kind of vocabulary to use in the application based on your understanding of the user base. For example, it is inappropriate to use technical terms in an application for novices, but it is natural for high-end users to use technical terms.

Use an informal friendly tone, but don't need to be too humble. Avoid being too formal, too rigid, or too hilarious, arrogant and rude. Remember that users may read these texts repeatedly, so some sentences that may seem playful at first can appear annoying after reading them a few more times.

Make words and sentences like news editors, avoid unnecessary redundant sentences. When your copy is concise enough, users can read and understand it easily. Identify the most important information, refine it and highlight it so that users don’t need to read a large paragraph of text to understand what they are looking for and what they are going to do next.

Add short labels or easy-to-understand icons to the control. Let users know what the control is for just a glance.

Pay attention to accuracy when describing time. The words today and tomorrow do seem friendly, but sometimes it can be puzzled by the user because you may not be able to determine the current time zone and time of the user. For example, if an activity starts before 12 o'clock in the evening, for users in the same time zone, the activity starts today, but for those users in the earlier time zone, the activity started yesterday.

Write a beautiful App Store description for your application and seize this great opportunity to communicate with potential users. In addition to accurately describing your application and emphasizing the quality and highlights of your application, you also need to:

• Fix all spelling, grammar and punctuation errors. These minor errors may not affect users’ normal use, but may give them a negative impression of the overall quality of the application.
• Try to use all-capsular words as little as possible. Although capital words can sometimes attract attention, all-capsular paragraphs are not suitable for reading and will give a feeling of yelling at the user's throat.
• You can describe bug fixes. If your new version of your app contains bug fixes that users have been expecting, it is a good idea to mention this in your software description.

1.13 Integrating with iOS

Integration with iOS refers to providing users with a comfortable and home-like experience on the current platform. Of course, this does not mean that we have to make every application exactly the same as the built-in application.

The best way to integrate with iOS is to have a deep understanding of the theme and core of iOS – this section is described in detail in the Designing for iOS section above and find out how to integrate and express this theme in your app. When you do this, following the guidelines in this chapter can help you provide your users with the experience they want.

1.13.1 Use Standard UI Elements Correctly

It is a good idea to use standard UI elements provided by UIkit whenever possible. Using standard elements instead of custom elements will benefit you and your users:

• Standard UI elements will be automatically updated according to official iOS updates - while custom elements will not.
• Standard UI elements have excellent scalability for your custom appearance and behavior. For example, all views in iOS (Views, objects inherited from UIView) can be defined using the TintColor attribute, which makes applying color matching very simple.
• Users are more familiar with and accustomed to standard elements because they can immediately understand the purpose of these elements in your application.

To make full use of the advantages of standard UI elements, there are some key points that need special attention:

Strictly follow the design specifications for each UI element. When the appearance and functionality of the UI elements in your application are familiar to the users, they can easily use them based on previous experience to better use your application. You can find the design specifications for various UI elements in these chapters: Bars, Content Views, Controls, Temporary Views.

(Translator's note: All the chapters mentioned above are in Chapter 4 of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently.)

Don't mix UI elements in different versions of iOS. You must not let users feel that your UI elements come from a different iOS system than the current user's device version.

Generally speaking, avoid creating custom UI elements to represent standard interactive behavior. First, ask yourself why you must create a custom element that is exactly the same as the standard UI element. If you just want to change the appearance of a standard UI element, consider using the UIKit appearance customization API (UIKit appearance customization APIs), or fill the element with another color. If you need to define a behavior that is slightly different from the standard control, make sure that after you change the properties and behavior of the UI element, the element can still do what you want. If you need to completely customize a behavior, it is best to design a custom element that is completely different from the standard element.

Tip: Interface Builder makes it easy to get standard UI elements, use the appearance customization APIs, obtain properties, and use customization and system-owned icons in your application. For more information about Interface Builder, see Xcode Overview.

Do not use the system's own buttons and icons to express other meanings. iOS provides a variety of available buttons and icons. Please make sure you understand their exact meanings; do not interpret and use them simply by guessing and understanding of these icon styles. (You can learn about the exact meanings of these buttons and icons in Toolbar and Navigation Bar Buttons and Tab Bar Icons.)

If the functions you need cannot be expressed by the buttons and icons provided by the system, you can also design custom buttons. For the design of custom buttons, please refer to Bar Button Icons.

(Translator's note: All the chapters mentioned above are in Chapter 4 of iOS Human Interface Guidelines. The translation will be released in subsequent updates. Please wait patiently.)

If your app is an immersive experience, it is reasonable to create a new custom UI. Because you are creating a unified experience environment where users can expect and explore how to control the app.

1.13.2 Downplay File and Document Handing

iOS apps can help users create and process files, but this does not mean that users need to overthink how the file system of iOS devices works.

If your application supports users to create and edit documents, it is a good practice to provide a clear document library view that allows users to easily open or create new documents. Ideally, such a graphics library view has the following characteristics:

• Highly graphic. Users can quickly find the files they want through the thumbnails on the screen.
• Let the user complete his/her tasks with minimal movement. For example, the user can quickly scroll the file list horizontally and then tap the file he/she wants to open it.
• Contains the function of creating a new document. A graphical library view should support users to click on a placeholder for a new document to complete the new document, rather than allowing users to create a new document by visiting other places.

For example, the graphics library view of Pages not only displays the existing documents of the user, but also adds convenient new document operations.

Tip: You can use the Quick Look Preview feature to let users preview files in your app, even if your app cannot open them. To learn how to provide this feature in your app, see Quick Look.

If your application allows users to use documents created in other applications, you can help users reach them by modal document picker view controller. This controller can extract users' documents in iCloud, and can also extract files created and stored in other applications through Document Provider extensions. To learn more about document provider extensions, please refer to Document Provider Extensions; To learn more about document extraction view controllers, please refer to Document Picker Programming Guide.

Give users enough confidence that their results will be properly saved at any time unless they are actively cancelled or deleted. If your app helps users create documents in management, they cannot be required to save them in time every time. Whether it is opening another document or switching applications, iOS apps should assume the responsibility of helping users save input content.

If the main function of your application is not to create content, but allows users to view or edit information, in this case you need to ask the user whether to save the modification. In this scenario, it is better to provide the "Edit" button, click it and enter the editing state, and the editing button becomes the "Save" and "Cancel" buttons. This change can prompt the user to be in editing mode. "Save" can retain the modified content, and "Cancel" will exit the editing mode.

1.13.3 Provide configurable options if necessary (Be Configurable If Necessary)

Some applications require manual installation or setting options for users, but most applications do not need this. A good application can enable most users to get started quickly and provide users with a convenient way to adjust their experience through the main interface.

When your app can meet the expectations of most users by default, users' needs for settings will be reduced. If you need to store basic information about users, you can prioritize requesting and pulling relevant information from the system instead of letting the user fill it out by yourself. If you must provide settings that users rarely use, please refer to the App Programming Guide for iOS The Setting Bundle section to understand how to define them in your code.

Provide settings options in the main UI as much as possible. If this setting item represents a basic task for the user, or if the user may change the settings frequently while performing the main task, it is convenient to place the settings item in the main UI. If the user only uses the settings item occasionally, then it can be placed in a separate view.

If the relevant settings in the application need to be changed in the system settings, help users directly access the system settings. In particular, if you want to use a paragraph of text to describe how to change this setting, such as "Settings>Privacy>Location Service", it is better to directly place a button and click to reach the positioning service in the settings. To learn how to implement it, please refer to the Settings Launch URL.

1.13.4 Take Advantage of iOS Technologies

iOS provides a wealth of technical ways to support users in completing various tasks and scenarios they expect. This means that in most cases, integrating the technology provided by the system into your application is often more reliable than customizing a new technology.

某些iOS技术，比如多任务并行（Multitasking）与语音向导（VoiceOver）等等，是所有应用都应该包含的系统级特性。而另外一些技术是否整合到应用中，则取决于应用本身的功能性。比如处理门票和礼品卡的应用（Wallet）支持用户在应用内内购（In-App Purchase），展示应用内置广告（iAd Rich Media Ads）则可以整合 Game Center，同时支持iCloud.