The sheet presentation style appears as a card that partially covers the underlying content and dims all uncovered areas to prevent interaction with them. The top edge of the parent view or a previous card is visible behind the current card to help people remember the task they suspended when they opened the card. People dismiss a card by:

* Swiping down from the top of the screen
* Swiping down from anywhere on the screen when card content is scrolled to the top
* Tapping a button

Use a sheet for nonimmersive modal content that doesn’t enable a complex task.

Sheet

The fullscreen presentation style covers the entire screen. The previous view is completely covered, minimizing visual distraction. People dismiss a full-screen modal view by tapping a button.

Use a full-screen modal view for immersive content — such as videos, photos, or camera views — or a complex task that benefits from a full-screen presentation, such as marking up a document or editing a photo.

Use modality when it makes sense. Create a modal experience only when it’s critical to focus people’s attention on making a choice or performing a task that’s different from their current task. A modal experience takes people out of their current context and requires an action to dismiss, so it’s essential to use it only when it provides a clear benefit.

Reserve alerts for delivering essential — and ideally actionable — information. Typically, an alert appears because something has gone wrong. Because an alert interrupts the experience and requires a tap to dismiss, it’s important for people to feel that the intrusion is warranted. For guidance, see Alerts.

Keep modal tasks simple, short, and narrowly focused. Avoid creating an app within your app. If a modal task is too complex, people can lose sight of the task they suspended when they entered the modal context. Be especially wary of creating modal tasks that involve a hierarchy of views because people can get lost and forget how to retrace their steps. If a modal task must contain subviews, provide a single path through the hierarchy and a clear path to completion. Avoid using a Done button for anything other than completing the task.

Always include a button that dismisses the modal view. For example, you might use Done or Cancel. Including a button ensures that the modal view is accessible to assistive technologies and provides an alternative to dismissal gestures.

When necessary, help people avoid data loss by getting confirmation before closing a modal view. Regardless of whether people use a dismiss gesture or a button to close the view, if the action could result in the loss of user-generated content, present an action sheet that explains the situation and gives people ways to resolve it.

Don’t display a card that appears on top of a popover. Although you can display a card within a popover, nothing should appear on top of a popover (except possibly an alert). In rare cases when you need to present a card after people take an action in a popover, close the popover before displaying the card.

In general, display a title that identifies the modal task. When people enter a modal task, they switch away from their previous context, so it’s a good idea to make the new context clear. You might also provide text in other parts of the view that more fully describes the task or provides guidance.

Coordinate the modal view appearance with your app. For example, when a modal view includes a navigation bar, it should use the same appearance as the navigation bar in your app.

Choose a modal transition style that makes sense in your app. Use a transition style that coordinates with your app and enhances the awareness of the temporary context shift. The default transition vertically slides the modal view up from the bottom of the screen and back down when it’s dismissed. Use consistent modal transition styles throughout your app.

Fullscreen

Modality is a design technique that presents content in a temporary mode that’s separate from the user's previous current context and requires an explicit action to exit. Presenting content modally can:

Help people focus on a self-contained task or set of closely related options
Ensure that people receive and, if necessary, act on critical information

iOS provides Alerts, Activity Views (or Share sheets), and Action Sheets that you use in specific situations in your app. To present custom modal content in your app, iOS 13 and later supports the following presentation styles.

University of Michigan - Ann Arbor

App Architecture

The launch experience has a significant impact on the way people feel about your app. Regardless of the device people are using or how long it's been since they last opened your app, the launch experience should be fast and seamless.

The guidelines below can help you design a delightful launch experience. For developer guidance, see Responding to the Launch of Your App.

Provide a launch screen. The system displays your launch screen the moment your app starts and quickly replaces it with your app's first screen. The function of a launch screen is to give people the impression that your app is fast and responsive, while allowing initial content to load. To ensure a seamless transition from your launch screen, design a plain screen that resembles your first app screen and doesn't draw attention to itself. For guidance, see Launch Screen.

Launch in the appropriate orientation. If your app supports both portrait and landscape modes, it should launch using the device’s current orientation. If your app only runs in one orientation, it should always launch in that orientation and let people rotate the device if necessary. Unless there’s a compelling reason not to, an app in landscape mode should orient itself correctly, regardless of whether the device was rotated left or right. For guidance, see Adaptivity and Layout.

Avoid asking for setup information up front. People expect apps to just work. Design your app for the majority of users and let the few that want a different configuration adjust settings to meet their needs. As much as possible, get setup information from device settings and defaults, or through a synchronization service, such as iCloud. If you must ask for setup information, prompt people to supply it the first time they open the app, and let them modify it later in your app’s settings.

Avoid showing in-app licensing agreements and disclaimers. Let the App Store display agreements and disclaimers so people can read them before downloading your app. If you must include these items within the app, integrate them in a balanced way that doesn’t disrupt the user experience.

Restore the previous state when your app restarts. Don't make people retrace steps to reach their previous location in your app. Preserve and restore your app’s state so they can continue where they left off.

Don’t encourage rebooting. Restarting takes time and makes your app seem unreliable and hard to use. If your app has memory or other issues that make it difficult to run unless the system has just booted, you need to address those issues.

Avoid asking people to rate your app too quickly or too often. Asking for a rating soon after first launch — or too frequently while people are using your app — is annoying and likely to decrease the amount of useful feedback you receive. To encourage well-considered feedback, give people time to form an opinion about your app before asking for a rating. Always provide a way to opt out of rating prompts and never force people to rate your app.

Launching

Onboarding lets you welcome new users and reconnect with returning ones. An optional onboarding experience that’s fast, fun, and educational can help people get the most from your app without getting in their way.

Provide onboarding that helps people enjoy your app, not just set it up. People can appreciate the opportunity to learn more about your app, but they also expect it to just work. Avoid including setup or licensing details in your onboarding experience. For guidance, see Launching.

Get to the action quickly. After the system replaces your launch screen with your initial app screen, let people dive right in and start enjoying your app. If you need to provide tutorials or intro sequences, give people a way to skip them and don't automatically show them to returning users.

Anticipate the need for help. Proactively look for times when people might be stuck. A game, for example, could casually show useful tips when paused or when a character isn’t advancing. Let people replay tutorials in case they miss something the first time.

Stick to the essentials in tutorials. It’s fine to provide guidance for beginners, but education isn’t a substitute for great app design. First and foremost, make your app intuitive. If too much guidance is needed, revisit the design of your app.

Make learning fun and discoverable. Learning by doing is a lot more fun and effective than reading a list of instructions. Use animation and interactivity to teach gradually and in context. Avoid displaying static screenshots that appear interactive.

Onboarding

When content is loading, a blank or static screen can make it seem like your app is frozen, resulting in confusion and frustration, and potentially causing people to leave your app.

Make it clear when loading is occurring. At minimum, show an activity spinner that communicates something is happening. Even better, display explicit progress so people can gauge how long they’ll be waiting.

Show content as soon as possible. Don’t make people wait for content to load before seeing the screen they're expecting. Show the screen immediately, and use placeholder text, graphics, or animations to identify where content isn't available yet. Replace these placeholder elements as the content loads. Whenever possible, preload upcoming content in the background, such as while an animation is playing or the user is navigating a level or menu.

Educate or entertain people to mask loading time. Consider showing hints about gameplay, entertaining video sequences, or interesting placeholder graphics.

Customize loading screens. Although standard progress indicators are usually OK, they can sometimes feel out of context. Consider designing a more immersive experience through custom animations and elements that match the style of your app or game.

Loading

Modality

Hierarchical Navigation
Make one choice per screen until you reach a destination. To go to another destination, you must retrace your steps or start over from the beginning and make different choices. Settings and Mail use this navigation style.

Flat Navigation
Switch between multiple content categories. Music and App Store use this navigation style.

Content-Driven or Experience-Driven Navigation
Move freely through content, or the content itself defines the navigation. Games, books, and other immersive apps generally use this navigation style.

Some apps combine multiple navigation styles. For example, an app that uses flat navigation may implement hierarchical navigation within each category.

Navigation

Request personal data only when your app clearly needs it. It’s natural to be suspicious of a request for personal information, especially if there’s no obvious need for it. Make sure permission requests occur only when people are using features that clearly need personal data. For example, an app might only request access to the current location when activating a location tracking feature.

Explain why your app needs the information. Provide custom text (known as a purpose string or usage description string) for display in the system’s permission request alert, and include an example. Keep the text short and specific, use sentence case, and be polite so people don’t feel pressured. There’s no need to include your app name — the system already identifies your app. For developer guidance, see Requesting Access to Protected Resources.

Request permission at launch only when necessary for your app to function. Users won’t be bothered by this request if it’s obvious that your app depends on their personal information to operate.

Don’t request location information unnecessarily. Before accessing location information, check the system to see whether Location Services is enabled. With this knowledge, you can delay the alert until a feature truly requires it, or perhaps avoid the alert altogether. For developer guidance, see Requesting Authorization for Location Services.

Use the system-provided alert. You can customize text in the standard permission alert, but avoid adding custom prompts that replicate the standard alert’s behavior or appearance.

Requesting permission

Some apps may need to provide a way to make setup or configuration choices, but most apps can avoid or delay doing so. Successful apps work well for most people right away, while also offering some convenient ways to adjust the experience. When you design your app to function the way most people expect, you decrease the need for settings.

Infer what you can from the system. If you need information about the user, device, or environment, query the system for it whenever possible instead of asking the user. For example, instead of asking someone to enter their zip code so you can present local options, ask permission to use their current location. Gracefully fall back to manual entry if the user denies access to their information.

Thoughtfully prioritize configuration options within your app. Your app’s main screen is a good place for options that are essential or that change frequently. Secondary screens are better for options that change only occasionally.

Expose infrequently changed configuration options in Settings. The Settings app is a central location for making configuration changes throughout the system, but people must leave your app to get there. It’s far more convenient to adjust settings directly within your app. If you must provide settings that rarely require change, see Implementing an iOS Settings Bundle in Preferences and Settings Programming Guide for developer guidance.

Provide shortcuts to Settings when appropriate. If your app includes text that directs users to Settings, such as “Go to Settings > MyApp > Privacy > Location Services,” provide a button that opens that location automatically. For developer guidance, see openSettingsURLString in UIApplication.

Learn Before

Related

Learn After