An activity represents a system-provided or custom task—accessible through an activity view controller—that can work with the current content.
Is a customizable object representing a task that an app can perform while users are in the app
Is represented by an icon that looks similar to a bar button icon
Users initiate an activity by tapping its icon in the activity view controller. In response, the activity either performs the task immediately, or if the task is complicated, it can request more information before performing the task.
Use an activity to give users access to a custom service or task that your app can perform. Note that iOS provides several built-in activities and app extensions, such as Print, Twitter, Message, and AirPlay. You don’t need to create a custom activity that performs a built-in task.
Create a streamlined template image that represents your task. A template image is an image that iOS uses as a mask to create the final icon that users see. To create a template image that looks good in the final icon, follow these guidelines:
Use black or white with appropriate alpha transparency.
Don’t include a drop shadow.
An activity template image should be centered in an area that measures about 70 x 70 pixels (high resolution).
Craft an activity title that succinctly describes your task. The title is displayed below the activity’s icon in the activity view controller. A short title is best, because it looks better onscreen and it’s easier to localize. When a title is too long, iOS first shrinks the text and then—if the title is still too long—truncates it. In general, it’s a good idea to avoid including your company or product name in the activity title.
Activity View Controller
An activity view controller presents a transient view listing system-provided and custom tasks that can act on some specified content.
An activity view controller:
Displays a configurable list of tasks that users can perform on the specified content
Can appear in an action sheet or a popover, depending on the environment
Use an activity view controller to give people a list of tasks they can perform on content that is specified in some way. The tasks can be system-provided—such as Copy, Twitter, and Print—or custom. A common way to use an activity view controller is to allow users to post selected content to a social media account.
Don’t create a custom button that reveals an activity view controller. People are accustomed to accessing system-provided tasks when they tap the Action button. You want to take advantage of this learned behavior and avoid confusing users by providing an alternative way to do the same thing.
Ensure that the listed tasks are appropriate in the current context. You can change the tasks listed in an activity view controller by specifying system-provided tasks to exclude and by identifying custom tasks to include. For example, to prevent users from printing an image, you exclude the Print activity from the activity view controller.
A collection view manages an ordered collection of items and presents them in a customizable layout.
A collection view:
Can contain optional views that visually distinguish subsets of items or provide decorative items, such as custom backgrounds
Supports custom animated transitions between layouts (by default, a collection view provides animations when users insert, move, or delete items)
Supports the addition of gesture recognizers to perform custom actions. By default, a collection view recognizes tap (to select an item) and touch-and-hold (to edit an item).
Use a collection view to give users a way to view and manipulate a set of items that don’t need to be displayed in a list. Because a collection view doesn’t enforce a strictly linear layout, it’s particularly well suited to display items that differ in size.
A collection view supports extensive customization, so it’s essential to avoid becoming distracted by your ability to create radical new designs. You want a collection view to enhance the user’s task; you don’t want a collection view to become the focus of the user experience. The following guidelines can help you create collection views that people appreciate.
Don’t use a collection view when a table view is a better choice. Sometimes it’s easier for people to view and understand information when it’s presented in a list. For example, it can be simpler and more efficient for people to view and interact with textual information when it’s in a scrolling list.
Make it easy for people to select an item. If it’s hard for users to tap an item in your collection view, they’re less likely to enjoy using your app. As with all UI objects that users might want to tap, ensure that the minimum target area for each item in a collection view is 44 x 44 points.
Use caution if you make dynamic layout changes. A collection view allows you to change the layout of items while users are viewing and interacting with them. If you decide to dynamically adjust a collection view’s layout, be sure that the change makes sense and is easy for users to track. Changing a collection view’s layout without an obvious motivation can give people the impression that your app is unpredictable and hard to use. And if the current focus or context is lost during a dynamic layout change, users are likely to feel that they’re no longer in control of your app.
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 controllers, navigation view controllers, and split view controllers (you can learn more about these elements in Tab Bar, Navigation Bar, and Split View Controller).
A container view controller has no predefined appearance or behavior.
Use a container view controller to present content through which users navigate in a custom way.
Ask yourself whether a custom container view controller is really necessary. Users are comfortable with the appearance and behavior of standard container view controllers, such as split view controllers and tab bar view controllers. You need to be sure that the potential advantages of your custom container view outweigh the fact that users won’t recognize it or instantly know how it works.
Make sure that your custom container view controller works in both orientations. It’s important to design a container view controller that gives users a consistent experience in both portrait and landscape.
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 task and often decrease the aesthetic appeal of your app.
An image view displays one image or an animated series of images.
An image view:
Has no predefined appearance and it doesn’t enable user interaction by default
Examines properties of both the image and its parent view to determine whether the image should be stretched, scaled, sized to fit, or pinned to a specific location
In iOS 7 and later, an image view that contains a template image applies the current tint color to the image.
As much as possible, ensure that all images in an image view have the same size and use the same scale. If your images have different sizes, the image view will adjust them separately; if your images use different scale factors, they may render incorrectly.
A map view presents geographical data and supports most of the functionality provided by the built-in Maps app (shown below in Photos).
A map view:
Displays a geographical area using standard map data, satellite imagery, or a combination of both
Can display annotations (which mark single points) and overlays (which delineate paths or two-dimensional areas)
Supports both programmatic and user-controlled zooming and panning
Use a map view to give users an interactive view of a geographical area. If you’re developing a routing app, use a map view to display the user’s route (for more information about creating a routing app, see Routing).
In general, let users interact with the map. People are accustomed to interacting with the built-in Maps app, and they expect to be able to interact with your map in similar ways.
Use the standard pin colors in a consistent way. A map pin shows the location of a point of interest in your map. People are familiar with the pin colors in the built-in Maps app, so it’s best to avoid redefining the meaning of these colors in your app. When you use the standard pin colors, be sure to use them in the following ways:
Use red for a destination point
Use green for a starting point
Use purple for a user-specified point
Page View Controller
A page view controller uses one of two styles to manage transitions through multipage content—scrolling or page-curl. Here’s how a page curl looks in iOS Simulator:
A page view controller:
Has no default appearance for the scrolling style
For the page curl style, a page view controller can add the appearance of the inside of a book spine between pairs of pages
Animates the transition from one page to another, according to the specified style
For the scrolling style, the current page scrolls to the next page; for the page curl style, the current page appears to turn like a page in a book or a notepad.
Use a page view controller to present content that users access in a linear fashion (such as the text of a story) or content that naturally breaks into chunks (such as a calendar).
If necessary, create a custom way to let users access content in a nonlinear way. A page view controller lets users move from one page to the next or previous page; it doesn’t give users a way to jump among nonadjoining pages. If you want to use a page view controller to present content that users might access in a nonlinear fashion—such as a dictionary or a book’s table of contents—you must implement a custom way to let users move to different areas of the content.
A popover is a transient view that can be revealed when people tap a control or tap in an onscreen area.
Is a self-contained modal view
In a horizontally regular environment, displays an arrow that indicates the point from which it emerged
Has a translucent background that blurs content behind it
Can contain a wide variety of objects and views, such as:
Table, image, map, text, web, or custom views
Navigation bars, toolbars, or tab bars
Controls or objects that act upon objects in the current app view
(By default, table views, navigation bars, and toolbars in a popover use a transparent background to let the popover’s blurring show through.)
In a horizontally regular environment, an action sheet always appears inside a popover.
Use a popover to display additional information or a list of items related to the focused or selected object.
Avoid providing a “dismiss popover” button. A popover should close automatically when its presence is no longer necessary. To determine when a popover’s presence is no longer necessary, consider the following scenarios:
If a popover…
Provides options that affect the main view, but doesn’t implement an inspector
Close the popover as soon as people make a choice or when they tap anywhere outside its bounds, including the control that reveals the popover.
Implements an inspector
Close the popover when people tap anywhere outside its bounds, including the control that reveals the popover.
In this scenario, don’t close the popover as soon as people make a choice, because they might want to make an additional choice or change the attributes of the current choice.
Enables a task
Close the popover when people complete or cancel the task by tapping a button in the popover, such as Done or Cancel.
In this scenario, you may not want to close the popover when people tap outside its borders, because it might be important that people finish—or explicitly abandon—the task. Otherwise, save people’s input when they tap outside a popover’s borders, just as you would if they tapped Done.
In general, save users’ work when they tap outside a popover’s borders. Not every popover requires an explicit dismissal, so people might dismiss them mistakenly. Discard the work people do in a popover only if they tap a Cancel button.
Make the popover arrow point as directly as possible to the element that revealed it. Doing this helps people remember where the popover came from and what task or object it’s associated with.
Make sure people can use a popover without seeing the app content behind it. A popover obscures the content behind it, and people can’t drag a popover to another location.
Ensure that only one popover is visible onscreen at a time. You shouldn’t display more than one popover (or custom view designed to look and behave like a popover) at the same time. In particular, you should avoid displaying a cascade or hierarchy of popovers simultaneously, in which one popover emerges from another.
Don’t display a modal view on top of a popover. Except for an alert, nothing should be displayed on top of a popover.
When possible, allow people to close one popover and open a new one with one tap. This behavior is especially desirable when several different bar buttons each open a popover, because it prevents people from having to make extra taps.
Avoid making a popover too big. A popover shouldn’t appear to take over the entire screen. Instead, it should be just big enough to display its contents and still point to the place it came from. 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. Note that the system might adjust both the height and the width of a popover to ensure that it fits well on the screen.
Use standard UI controls and views within a popover. In general, popovers look best, and are easier for users to understand, when they contain standard controls and views.
Make sure a custom popover still looks like a popover. Although it’s easy to customize many of the visual aspects of a popover by using the
UIPopoverBackgroundView APIs, avoid creating a design that people might not recognize as a popover. If you change the appearance of a popover too much, users can’t rely on their prior experience to help them understand how to use it in your app.
Be cautious if you change a popover’s size while it remains visible. 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. When you adjust the size of a visible popover, it’s usually a good idea to animate the change because it avoids giving the impression that a new popover has replaced the old one.
A scroll view helps people see content that is larger than the scroll view’s boundaries (the image shown below is both taller and wider than the scroll view that contains it).
A scroll view:
Has no predefined appearance
Flashes transient scroll indicators when it first appears or when users interact with it
Responds to the speed and direction of gestures to reveal content in a way that feels natural to people
When users drag content in a scroll view, the content follows the touch; when users flick content, the scroll view reveals the content quickly and stops scrolling when the user touches the screen or when the end of the content is reached.
Can operate in paging mode, in which each drag or flick gesture reveals one app-defined page of content
Use a scroll view to give people access to large views—or to large numbers of views—in a constrained space.
Support zoom behavior appropriately. If it makes sense in your app, let users pinch or double-tap to zoom into and out of a scroll view. When you enable zoom, you should also set maximum and minimum scale values that make sense in the context of the user’s task. For example, letting users zoom in on text until one character fills the screen is unlikely to make it easier for them to read the content.
Consider using a page control with a paging-mode scroll view. When you want to display content that’s divided into pages, screenfuls, or other chunks, you can use a page control to show users how many chunks are available and which one they’re currently viewing.
When you use a page control with a paging-mode scroll view, it’s a good idea to disable the scroll indicator that’s on the same axis as the page control. Removing the scroll indicator focuses attention on the page control and gives people one unambiguous way to page through the content. For more information about using a page control in your app, see Page Control.
In general, display only one scroll view at a time. People often make large swipe gestures when they scroll, so it can be difficult for them to avoid interacting with a neighboring scroll view on the same screen. If you decide to put two scroll views on one screen, consider allowing them to scroll in different directions so that one gesture is less likely to scroll both views. For example, Stocks in portrait orientation on iPhone displays stock quotes in a vertically scrolling view above company-specific information, which is in a horizontally scrolling view.
Split View Controller
A split view controller is a full-screen view controller that manages the presentation of two child view controllers.
By default, a split view controller uses the current size class to decide how to arrange its child view controllers. For example, a split view controller:
Tries to display both panes side-by-side in a horizontally regular environment
Can display the primary pane layered on top of the secondary pane, or can hide the primary pane offscreen until it’s needed, typically in a horizontally compact environment
You can influence the arrangement of panes by asking the split view controller to pay attention to a preferred layout that you specify for a particular display environment.
A split view controller can contain a wide variety of objects and views, such as:
Table, image, map, text, web, or custom views
Navigation bars, toolbars, or tab bars
Use a split view controller to display persistent information in the primary pane and related details or subordinate information in the secondary pane. In this design pattern, when people select an item in the primary pane, the secondary pane should display the information related to that item. (You’re responsible for making this happen in code.)
Avoid creating a secondary pane that is narrower than the primary pane. If the secondary pane is narrower than the primary pane, the split view controller no longer fills the width of the screen and the overall appearance is unbalanced.
Avoid displaying a navigation bar in both panes at the same time. Doing this would make it very difficult for users to discern the relationship between the two panes.
In general, indicate the current selection in the primary pane in a persistent way. Even though the content of the secondary pane can change, it should always remain related to the item selected in the primary pane. This viewing experience helps people understand the relationship between the item in the primary pane and the contents of the secondary pane.
Give people alternative ways to access the primary pane, if appropriate. By default, only the secondary pane is displayed in a horizontally compact environment and you provide users with a button (typically located in a navigation bar) to reveal and hide the primary pane. The split view controller also supports the swipe gesture to perform the reveal/hide action. Unless your app uses the swipe gesture to perform other functions, you should let people swipe to access the primary pane.
A table view presents data in a scrolling single-column list of multiple rows.
A table view:
Displays data in rows that can be divided by section or separated into groups
Provides controls that let users add or remove rows, select multiple rows, see more information about a row item, or reveal another table view
iOS defines two styles of table view:
Plain. In the plain style, rows can be separated into labeled sections and an optional index can appear vertically along the right edge of the view. A header can appear before the first item in a section, and a footer can appear after the last item.
Grouped. In the grouped style, rows are displayed in groups, which can be preceded by a header and followed by a footer. A grouped table view always contains at least one group of list items—one list item per row—and each group always contains at least one item. A grouped table view doesn’t include an index.
In both styles, a table row becomes highlighted briefly when a user taps a selectable item. If a row selection results in navigation to a new screen, the selected row becomes highlighted briefly as the new screen slides into place. When the user navigates back to the previous screen, the originally selected row again becomes highlighted briefly to remind the user of the earlier selection (it doesn’t remain highlighted).
iOS includes some table view elements that can extend the functionality of table views. Unless noted otherwise, these elements are suitable for use with table views only.
Table view element
Indicates that the row is selected.
Displays another table associated with the row.
Detail Disclosure button
Displays additional details about the row in a new view (for information on how to use this element outside of a table, see Popover).
Indicates that the row can be dragged to another location in the table.
Adds a new row to the table.
Delete button control
In an editing context, reveals and hides the Delete button for a row.
Deletes the row.
In addition to the table-specific elements listed above, iOS defines the refresh control, which gives users the ability to refresh a table’s contents. To learn more about using a refresh control with a table in your app, see Refresh Control.
iOS defines four table cell styles that implement the most common layouts for table rows in both plain and grouped tables. Each cell style is best suited to display a different type of information.
UITableViewCellStyleDefault). The default cell style includes an optional image in the left end of the row, followed by a left-aligned title.
The default style is good for displaying a list of items that don’t need to be differentiated by supplementary information.
UITableViewCellStyleSubtitle). The subtitle style includes an optional image in the left end of the row, followed by a left-aligned title on one line and a left-aligned subtitle on the line below.
The left alignment of the text labels makes the list easy to scan. This table cell style works well when list items look similar, because users can use the additional information in the detail text labels to help distinguish items named in the text labels.
Value 1 (
UITableViewCellStyleValue1). The value 1 style displays a left-aligned title with, on the same line, a right-aligned subtitle in a lighter font.
Value 2 (
UITableViewCellStyleValue2). The value 2 style displays a right-aligned title in a blue font, followed on the same line by a left-aligned subtitle in a black font. Images don’t fit well in this style.
In the value 2 layout, the crisp vertical margin between the text and the detail text helps users focus on the first words of the detail text label.
Use a table view to display large or small amounts of information cleanly and efficiently. For example:
Provide a list of options from which users can select. You can use the checkmark to show users the currently selected options in the list.
Use either a plain or a grouped table view to display a list of choices that appears when users tap an item in a table row. Use a plain table view to display a list of choices that appears when users tap a button or other UI element that is not in a table row.
Display hierarchical information. The plain table style is well suited for displaying a hierarchy of information. Each list item can lead to a different subset of information displayed in another list. Users follow a path through the hierarchy by selecting one item in each successive list. The disclosure indicator tells users that tapping anywhere in the row reveals the subset of information in a new list.
Display conceptually grouped information. Both table view styles allow you to provide context by supplying header and footer views between sections of information.
You can also use a header-footer view—that is, an instance of
UITableViewHeaderFooterView—to display text or a custom view in a header or footer. To learn how to use a header-footer view in your code, see UITableViewHeaderFooterView Class Reference.
Follow these guidelines when you use table views:
Always provide feedback when users select a list item. Users expect a table row to become highlighted briefly when they tap a selectable item in it. After tapping, users expect a new view to appear (or the row to display a checkmark) to indicate that the item has been selected or enabled.
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. This technique gives users useful information right away and increases the perceived responsiveness of your app.
Consider displaying “stale” data while waiting for new data to arrive. Although this technique isn’t recommended for apps that handle frequently changing data, it can help more static apps give users something useful right away. Before you decide to do this, gauge how often the data changes and how much users depend on seeing fresh data quickly.
If the data is slow loading or complex, show users that processing is continuing. If a table contains only complex data, it may be difficult to display anything useful right away. In these rare cases, it's important to avoid displaying empty rows, because empty rows can imply that your app has stalled. Instead, the table should display a spinning activity indicator, along with an informative label (such as “Loading…”) centered in the screen. This behavior reassures users that processing is continuing.
If appropriate, use a custom title for the Delete button. If it helps users to better understand the way your app works, you can create a title to replace the system-provided Delete title.
As much as possible, use succinct text labels to avoid truncation. Truncated words and phrases can be difficult for users to scan and understand. Text truncation is automatic in all table cell styles, but it can present more or less of a problem, depending on which cell style you use and on where truncation occurs.
Avoid combining an index with table view elements that are displayed on the right edge of the table. Table view elements that are displayed on the right edge of the table—such as the disclosure indicator—interfere with the index.
Create a custom table cell style if you want to lay out your table rows in a nonstandard way. It’s better to create a custom table cell style than to significantly alter a standard one. To learn how to create your own cells, see Customizing Cells.
A text view accepts and displays multiple lines of attributed text.
A text view:
Is a rectangle of any height
Supports scrolling when the content is too large to fit inside its bounds
Supports custom fonts, colors, and alignments (by default, a text view displays left-aligned system font in black)
Can support editing, in which case a keyboard appears when the user taps inside the text view (the keyboard’s input method and layout are determined by the user’s language settings)
Always make sure the text is easy to read. Although you can use attributed strings to combine multiple fonts, colors, and alignments in creative ways, it’s essential to maintain the readability of the text. It’s a good idea to support Dynamic Type and use the
preferredFontForTextStyle to get the text for display in a text view. For some guidelines on supporting Dynamic Type, see Text Should Always Be Legible; for programmatic information, see Text Styles.
Specify different keyboard types to accommodate different types of content you expect users to enter. For example, you might want to make it easy for users to enter a URL, a PIN, or a phone number. Note, however, that you have no control over the keyboard’s input method and layout, which are determined by the user’s language settings.
iOS provides several keyboard types, each designed to facilitate a different type of input. To learn about the keyboard types that are available, see the documentation for
UIKeyboardType. To learn more about managing the keyboard in your app, read Managing the Keyboard.
A web view is a region that can display rich HTML content (shown here between the navigation bar and toolbar in Mail on iPhone).
A web view:
Displays web content
Performs some automatic processing on web content, such as converting a phone number to a phone link
If you have a webpage or web app, you might decide to use a web view to implement a simple iOS app that provides a wrapper for your webpage or web app. If you plan to use a web view to access web content that you control, be sure to read Safari Web Content Guide.
Avoid using a web view to create an app that looks and behaves like a mini web browser. People expect to use Safari on iOS to browse web content, so replicating this broad functionality within your app is not recommended.