An activity represents a system-provided or custom service—accessible through an activity view controller—that can act on some specified content.
Is a customizable object representing a service 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 a service by tapping its activity icon in the activity view controller. In response, the activity either performs the service immediately, or if the service is complicated, it can request more information before performing the service.
Use an activity to give users access to a custom service that your app can perform. Note that iOS provides several built-in services, such as Print, Twitter, Message, and AirPlay. You don’t need to create a custom activity that performs a built-in service.
Create a streamlined template image that represents your service. 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 service. 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 services that can act on some specified content.
An activity view controller:
Displays a configurable list of services that users can perform on the specified content
Appears in an action sheet on iPhone; on iPad, it appears in a popover
Use an activity view controller to give people a list of services they can perform on content that is specified in some way. The services 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 services when they tap the Share 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 services are appropriate in the current context. You can change the services listed in an activity view controller by specifying system-provided services to exclude and by identifying custom services 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 (iPad Only)).
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, 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 7 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.
Popover (iPad Only)
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 view that hovers above the contents of a screen
Always 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 iPad apps, 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.
Display an action sheet containing a short list of options that are closely related to something on the screen.
Display the contents of the left pane when a split-view–based app is in portrait. If you do this, you either provide an appropriately titled button that displays the popover—preferably in a navigation bar or toolbar at the top of the screen—or allow people to make the swipe gesture to hide and reveal it.
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.
Ideally, the width of a popover should be at least 320 points, but no greater than 600 points. The height of a popover is not constrained, so you can use it to display a long list of items. In general, though, you should try to avoid scrolling in a popover that enables a task or that presents an action sheet. 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.
If appropriate, 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 (iPad Only)
A split view controller is a full-screen view controller that manages the presentation of two side-by-side view controllers.
A split view controller:
Displays two panes (the width of the left pane is fixed at 320 points in all orientations; you can customize the width of the right pane)
Can optionally display the left pane in a popover when the device is in portrait orientation
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 left pane and related details or subordinate information in the right pane. In this design pattern, when people select an item in the left pane, the right pane should display the information related to that item. (You’re responsible for making this happen in code.)
Avoid creating a right pane that is narrower than the left pane. If the right pane is narrower than the left 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 left pane in a persistent way. Even though the content of the right pane can change, it should always remain related to the item selected in the left pane. This viewing experience helps people understand the relationship between the item in the left pane and the contents of the right pane.
Give people alternative ways to access the left pane, if appropriate. By default, only the right pane is displayed in portrait orientation and you provide users with a button (typically located in a navigation bar) to reveal and hide the left 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 left 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 (iPad Only)).
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.
In iOS 6.0 and later, you can 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” in Table View Programming Guide for iPhone OS.
A text view accepts and displays multiple lines of 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” in Text, Web, and Editing Programming Guide for iOS.
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” in iPhone Application Programming Guide.
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.