The guy filling up at the next pump asked what I did for a living. App and game development, I said. He said he wanted his own app. He was a carpenter. He didn’t know what he wanted it for, but he knew that he wanted one. It takes you back to the late 1990s when everyone wanted their own website. With hindsight, we know that websites are here to stay.
But how do you make a good app and why can’t you really write one in three days? Here is a story in four parts describing what a developer has to do to create an app.
Part 1 – chuck out 99.9% of what you think you need
The preparatory work takes a long time and is possibly the most important thing and the most difficult thing. Often you want to get in as many innovative features as possible. That’s rarely the best solution.
Good design is all about saying no to 1,000 things, not saying yes to 1,000 things. And not to 100 either, maybe not even to 10. One innovative feature, that’s what we want to end up with, if we can. It’s important to focus on the features that the app is all about and forget about the rest. Do that, and you’ll be free to focus on making the few features you have got as good as they can possibly be. Too many features and the quality will suffer and the app will be hard to use.
A good app should almost feel “too simple”. It really doesn’t need to be any more complicated.
Part 2 – design within the limits
Many people think that making an app is roughly the same thing as making a website. A website and an app are not the same thing at all. A mobile phone has a much smaller screen than a computer and it usually has a slower connection, a slower processor and less memory.
Due to the small screen, you have to design according to screen size from the start. That means you’ll have room for less stuff on the screen at the same time. Since users touch the screen with their thick and clumsy fingers, precision is seriously impaired, which doesn’t make things any easier.
Ideally, the most important function ought to be achievable just by pressing one button. Less is more. Navigating to the next page down counts as pressing a button, so that’s two things before you’ve even started. Ideally all you should need to do is 1) open the app, 2) press a button to do what you want to do and 3) close the app again.
If you combine these requirements, adapt to the small screen size, keep down the number of pages and keep down the number of buttons you need to press, you’ll soon realise that designing an app that is easy to use and contains everything you want it to is going to take you longer than 15 minutes. A day might not be enough either, maybe not even a week.
Part 3 – code, code, code!
Once the overall design is ready, it’s time to start with the technical part, the actual programming. Setting up a project is quite quick, and fixing the basics is often quite quick too.
But fairly soon, the technical limitations start to make themselves felt. Use too much of the very limited memory, and the app will simply be shut down by the system. Once most things are in place, you soon start to realise that everything is taking a little bit too long. It’s important that your app works instantly. Usually people use an app for less than a minute. Start the camera app, take a picture, close the app.
Once almost everything is in place, you’ll notice stuff starts taking too long. Speed is essential, considering how often people use an app for less than a minute at a time. Start the camera app, take a picture, close the app.
A good app should start quickly and be quick and easy to use to do the things you want to achieve, while looking great and being quick to download at the same time. Not exactly an equation you can solve in a day.
Part 4 – test, test, test!
A well tested app is an app that works well. There aren’t very many iPhone models. They don’t differ very much from each other. The screen size and the resolution are identical (apart from the iPhone 4, whose resolution is twice as high). This means it is relatively easy to write apps that work well on all models. In terms of time spent, it makes sense to buy all the models and test your app on every one, in other words that’s realistic and cost-effective. Programming only one model is obviously the simplest method, but four isn’t too bad. However, with Android it’s a different story.
Android phones can have different screen sizes, different resolutions and different amounts of memory, faster or slower processors, and behave differently depending on how the manufacturer chose to interpret the specifications, etc. All these variables make it difficult to develop for Android. How can you guarantee that the app will work on all phones? You can’t.
For users, whether or not they use Android is mostly a matter of taste. As a developer, I would always choose to develop for the iPhone over Android, if I have the choice. I don’t always.
What does an app cost, in other words how long does it take?
A simple app, such as Blocket, for example, would take an estimated four weeks for one person to write. A game, such as Angry Birds, for example could take maybe three to six months. At normal consultancy fees, you know roughly how much that would cost.
Try writing down every single function and button included in as much detail as possible. You can be sure it will be an impressive list. Analysing an app like that only shows the tip of the iceberg. 90% of all the coding usually lies under the surface.
And you can be sure that it will also take countless iterations of design and functionality before you get it right. Often you don’t know if it’s right until you’ve tested it. A good app takes time to develop.
These days people tend to expect that there will be an app for a certain purpose. All websites that provide services will soon be expected to have their own app too. Browsing the web on your mobile phone is tricky. If you have access to a computer, you will tend to choose that over your phone. As long as there isn’t a great app that’s better than its equivalent on the web, that is. An app that adapts the content to the phone.
Everybody wants an app.