Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Mobile Application Startup Process

From Wiki
Jump to: navigation, search
Article Metadata
Created: User:Aadhar14b (31 Oct 2009)
Last edited: hamishwillee (07 May 2012)

Original article published at Little Spring Design under Attribution 3.0



The aim of the article is to help developers understand the importance of the Application Startup Process with the help of some guidelines.

Application Startup, may it be a computer or mobile application, is a very important design factor. Some startups are just to display some information and others act as indicator for the initial startup processes.

Most of the developers overlook the start up process efficiency/usability, thinking that users are more bothered about the application usability than the startup process. Such an approach some times becomes the root for poor startup process for application in terms of usability/performance.

The simple act of start up or launching of an application is often mishandled, causing the user extra delay and sometimes launch failures.

Design Guidelines/Best practices

  • Check license status only when necessary. If the application is licensed for a month, check license status a few days before the old license expires.
  • If frequent license checking is necessary, consider allowing a certain number of runs when no network connection is available. This allows application use in the basement and other low signal areas.
  • Avoid setup questions except the first time the application is run. For example, if your application supports a "game lobby" and the user has declined joining it, avoid asking the same question each time the application launches.
  • When possible, break the application into modules. Load only the base module upon launch; load other modules in the background while the user interacts with the basic module.
  • Maintain password information as long as reasonable given the security needs of the application.
  • Certify the application, so the user does not have to handle queries about potentially unsafe content on a phone.
  • Intelligently save context, so the user does not have to find her place again. Some applications need to start at a home screen; most applications are better off starting where the user left off.
  • Provide frequent task actions on the main page. For applications with very frequent main tasks or views, the primary task or view should be the main screen. So-called "main menu" items can go in a softkey menu or similar.
  • Avoid lengthier task at startup, but if at all necessary then show a progress bar as an indication of work in progress. If some startup task can be made optional by asking user then its better.

When Used

All downloaded applications need to be optimized for fast launch.


  • Users tend to want to get their content, including download and purchase if relevant, within 20 seconds; some data suggests that the impatience limit is actually below 10 seconds.
  • On many devices, if the user has launched an application, she can do nothing else with the device until the application has exited. Only one application can be running. Thus the 30 seconds that many applications take just to launch leaves less than no time available for fetching information before the user's patience has been tested.
  • The promise of mobile data and applications is information and entertainment on the fly. This realization will never happen with long launch processes.

This page was last modified on 7 May 2012, at 05:14.
112 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.