Starting and Stopping
It’s often said that people spend no more than a minute or two evaluating a new app. When you make the most of this brief period by presenting useful content immediately, you pique the interest of new users and give all users a superior experience.
As much as possible, avoid displaying a splash screen or other startup experience. It’s best when users can begin using your app immediately.
Avoid asking people to supply setup information. Instead:
Focus on the needs of 80 percent of your users. When you do this, most people won’t have to supply any settings, because the app is already set up to behave the way they expect. If there is functionality that only a few users might want—or that most users might want only once—leave it out.
Get as much information as possible from other sources. If you can use any of the information people supply in built-in app or device settings, query the system for these values; don’t ask people to enter them again.
If you must ask for setup information, prompt people to enter it within your app. Then, store this information as soon as possible (potentially, in your app’s settings). This way, people aren’t forced to switch to Settings before they get the chance to enjoy your app. If people need to make changes to this information later, they can go to the app’s settings at any time.
Delay a login requirement for as long as possible. It’s best when users can navigate through much of your app and use some of its functionality without logging in. Users often abandon apps that force them to log in before they can do anything useful.
In general, launch in the device’s default orientation. On iPhone, the default orientation is portrait; on iPad, it’s the current device orientation. If your app runs only in landscape orientation, you should always launch in landscape and let users rotate the device if necessary.
Supply a launch image that closely resembles the first screen of the app. iOS displays the launch image the moment your app starts—giving users the impression that your app is fast and giving your app enough time to load content. Learn how to create a launch image in Launch Images.
If possible, avoid requiring users to read a disclaimer or agree to an end-user license agreement when they first start your app. Instead, you can let the App Store display your disclaimer or end-user license agreement (EULA) so that people can access it before they get your app. If you must provide these items within your app, be sure to integrate them in a way that harmonizes with your UI and balances business requirements with user experience needs.
When your app restarts, restore its state so users can continue where they left off. People shouldn’t have to remember the steps they took to reach their previous location in your app. To learn more about efficient ways to preserve and restore your app’s state, see “State Preservation and Restoration”.
Always Be Prepared to Stop
An iOS app never displays a Close or Quit option. People stop using an app when they switch to another app, return to the Home screen, or put their devices in sleep mode.
When people switch away from your app, iOS multitasking transitions it to the background and replaces its UI with the UI of the new app. To prepare for this situation, your app should:
Save user data as soon as possible and as often as reasonable. Do this because an app in the background can be told to exit or terminate at any time.
Save the current state when stopping at the finest level of detail possible. In this way, people don’t lose their context when they switch back to your app. For example, if your app displays scrolling data, save the current scroll position. You can learn more about efficient ways to preserve and restore your app’s state in “State Preservation and Restoration”.
Some apps may need to keep running in the background while users run another app in the foreground. For example, users might want to keep listening to the song that’s playing in one app while they’re using a different app to check their to-do list or play a game. Learn how to handle multitasking correctly and gracefully in Multitasking.
Never quit an iOS app programmatically. People tend to interpret this as a crash. If something prevents your app from functioning as intended, you need to tell users about the situation and explain what they can do about it. Here are two good ways to do this:
If all app features are unavailable, display a screen that describes the situation and suggests a correction. The information gives feedback to users and reassures them that there’s nothing wrong with your app. It also puts users in control, letting them decide whether they want to take corrective action and continue using your app or switch to another app.
If only some app features are unavailable, display either a screen or an alert when people try to use the feature. Otherwise, people should be able to use the rest of the app. If you decide to use an alert, be sure to display it only when people try to access the feature that isn’t functioning.