How Long Does It Take To Develop An App?

It’s strange how similar things come along at the same time and this week it’s multiple people asking me how long it would take to develop an app when the details of what’s in the app haven’t even been defined yet!

At first its might seem surprising that people might want to know or even request this but if you think about it, it’s one of the first questions that might determine whether an app is worth developing or it might help drive how much functionality should be initially defined for an app.

So the question is really “How long does it take to develop a typical non-trivial app?”. I answered this previously in my Mobile Development Primer under the heading “Work out How Much It Will Cost”. The answer is about 6 to 8 weeks.

If your app is doing more than one main thing than you can factor up the time and cost. How do you determine this? Well, if your app could be split into two (or more) apps and still have significant functionality then you should obviously be budgeting for proportionately more time. An example might be including complex instant messaging into an app whose purpose is really to do something else.

Other common factors affecting timescales include the degree of testing, the degree of branding and the use of non-standard UI/idioms. For example, if you want your app to look more like an iOS app on Android which, strangely, some people still seem to want, then it will take longer and cost you more.

Windows Phone 24.3% Compound Annual Growth up to 2019?

IDC has some new research that roughly correlates with GfK in that smartphone shipments are expected to grow 11.3% in 2015.


IDC has predictions up to 2019 when it expects both iOS and Android to grow less, with iOS having the lesser year on year growth. They also predict, without substantiation, that Windows Phone will see a 24.3% compound annual growth.

GfK Smartphone Sales and Predictions

gfkGfK has research into Q1 smartphone shipments split by region. Smartphone sales are up 8% year on year driven by the continued growth of larger screen devices.


A new insight is that 4G is rapidly gaining share and surpassed 50% of the global handset market for the first time. GfK expect smartphone sales growth to be 10% over the next year.

Mobile Payments and Banking Market Map

firstpartnerFirstPartner have a new 2015 version of their free Mobile Payments & Banking Market Map. It shows consumer segments, mobile financial services, types of payment, the payment value chain, payment processors and providers, technology and system vendors, regulators, industry association and standards bodies. There are also some useful statistics, for example, there are forecast to be 195 billion mobile and tablet transactions per year by 2019, a factor of three more than there were for 2014.


Counterpoint Smartphone Market Share

counterpointCounterpoint has a new infographic based on their Q1-2015 Market Monitor report that tracks more than 75 top vendor shipments across countries that contribute to more than 95% of the total global smartphone volumes.


The infographic is particularly good if you need region specific data.

Design for Design’s Sake

wiredI have been reading an article in this month’s UK Wired magazine on ’41 Lessons from Uber’. One of the lessons is to “Keep it Simple”. Uber has only rolled out one major design change to its app. The lesson is:

“Don’t change your product unless you have to. Make it faster, better and more robust but don’t do design for design’s sake.”

I have seen many projects substantially re-design everything before the app is even released. This is usually relatively costly as it often involves iOS, Android and the server. It also causes the app to be late to market. So what causes a substantial change of design? I find it’s usually one or more of the following…

  • A new project UI designer, project manager or other staff trying to make their mark on the project
  • A sudden (arbitrary) change in company branding
  • A new UI paradigm provided by Apple or Google
  • A late realisation that the app doesn’t look right due to key people only becoming interested late on in the project lifecycle – this can happen even on Agile projects.

Pre-empting these scenarios might allow you to pre-empt unnecessary re-design. If you need to re-design prior to release, consider waiting for feedback from real users as you will most likely have to re-design at that point anyway.

Multiple App Publishers, One Company

trendmicroTrend Micro has an article on how companies should better ensure their (multiple) apps are published under the same account/name so that uses can better determine whether they are fake or not.

For example, how do users know all the Santander apps below are official?


Trend Micro previously published an alarmist article saying that “70% of top free apps have fake and mostly malicious versions in app stores” and that “80% of the top 50 free apps found in Google Play have bogus versions”. However, they later added the caveat that “Note that the fake apps samples we gathered are from third party sources and none was found in Google Play“.

So, if you only distribute via the Play Store (or App Store) should you care? I think so. If people download a bogus app from anywhere it can lead to loss of a user/customer, financial or information theft, fraud and loss of reputation/trust. You should direct end users to download from specific app stores, pre-declare your one publisher name and ask end-users to check this prior to downloading.

Pre-App Strategy

benedictevansBenedict Evans has two new excellent posts on Mobile First and App vs Web. However, what he writes about is very different to the usual mobile first and app vs web arguments.

In Mobile First, Benedict suggests that we think about the desktop as the more limited cut-down version of the Internet. The smartphone allows interaction with more things (e.g. iBeacons, notifications, Touch ID) and knows a lot more, via sensors and APIs, than the desktop ever did. He argues that while the screen might be smaller, the smartphone is more of the ‘whole internet’.

In Apps vs Web, Benedict asks the usual question whether publishers should do an app or a web site. However, instead of the discovery or functionality arguments he distils the answer down to:

“Do people want to put your icon on their home screen”.

He goes on to argue that even if you have an app, you should also have a web site that functions well on mobile. You should also shape your proposition so that it works for people who have chosen to interact only via mobile and might not even be mobile (e.g. using on WiFi at home).

In both these posts Benedict is thinking about the business decisions made pre-app. I believe this pre-phase of mobile strategy is one that publishers don’t spend long enough analysing. People often leave issues such as usage, discovery, the channel, PR, marketing and analytics until too late on when solutions are often more difficult and costly to retro-fit. You also need to think about feasibility, platforms, business models, OS and form factor variants and cost. See my Mobile Development Primer for more insights.