Speed promote confidence and immediate satisfaction. An app must be speedy, if not it will be forgotten, moved to the last screen and finally deleted. But as in all other aspects of life there are different types of speed regarding apps, for instance the time the app takes to respond to opening, updating and to touch gestures:
- Opening. What happens when you tap the icon? If the app doesn't immediate put up an splash screen and finish loading in 10 seconds I normally quit.
- Updating. When I've changed something I expect the app to save anything in 3 seconds.
- Responding to gestures. This has to be immediately. If you tap or swipe and nothing happens, well – that's it.
So immediate, or 50 ms, 3 seconds and 10 seconds are the timeframe we have to convince our users. And how do we do that? The following design choices are important:
- The app must do one thing and do it well. Apps aren't like PC applications which tend to solve everything. Minimalistic design promote a small memory footprint and thus speed.
- The app use asynchron operations. It must let you do other things when doing things that takes time. Using local storage and REST will help a lot. Cloud services like Azure SQL provides services up to ten times faster than on premise hosting.
- The app should not have to many layers. Layers that are supportive in helping to break down problems to solvable challenges, can also give problems. Abstraction cost is a term I've recently found. Framework and cross-platform tools take their tolls, and normally that's in speed. In iPhone, Objective-C does in fact operate nearly at machine code speed. It is also created to reduce the abstraction cost using dynamic linking to Apple's extensive frameworks.
Talking about speed there is also always the theme about perceived vs. actual speed, but this is another story.