No.  By far the bigger risk is supporting old version of the OS like iOS 5.  For the vast majority of new software development, it’s a critical strategy failure to target old versions of iOS.  For new software projects, you should be targeting the shipping version or even preproduction versions.

Why is this?  Let me sketch it out on my whiteboard for you:

(I hope you will forgive me for not including many units in my rough sketches.  When I show this to clients, I’m usually talking about their specific project and using actual projections.  It’s pretty hard to come up with numbers that are accurate for every reader of this blog!)

Let’s take a look at your typical adoption curve.  What most people want to know is, “How many customers do I reach if I target iOS 6?”  And you will get various answers depending on when the figure was reported: within 48 hours of its release, adoption was 25-35%.  30 days following its release, it was about 60%.  Our own figures indicate that today adoption is in the 70-80% range.

But the dirty secret is that your app isn’t going to be released today–it’s going to be released (at least) several months from now, when the adoption statistics are even higher.  Perhaps the development time for a “typical” app is 90 days, and during those 90 days, an OS can go from 0% to 70% marketshare.  So there is literally nothing useful marketshare numbers will tell you that will still be accurate when your application is released.

Even worse, supporting older OSes takes additional time, which contributes to your ship date.  It is impossible to quantify exactly the cost of targeting older OSes, as for some applications it may present itself as test and debugging overhead, whereas for others it may present as months spent backporting new Apple technologies to previous devices.  Still in others, it may present as simply not having certain new features, like Passkit, not supporting the new 4″ screen of the iPhone 5, and so on.  However, let’s suppose you are doing something “average” and call it an additional 20% time to support iOS 5:

First, we see that adoption statistics are worse than useless, because the needle will move quite a bit over the course of development.  Second, we see that even as we have spent additional time trying to capture iOS 5 users, those users have continued to migrate to iOS 6.  Just doing nothing would have captured that marketshare.  The number of actual customers that we capture with an iOS 5 strategy is extremely small:

Just think: we have gone to all this time and effort, and extended our development schedule by 20 days, just to capture this very tiny sliver of the market.  Just for reference, contrast this with the size of the iOS 6 marketshare that we get “for free”:

So what you see here is that the Cost-To-Acquire (CTA) an iOS 5 customer is vastly, vastly more expensive than acquiring an iOS 6 customer.  It is 10x or 100x the cost per customer.  For the vast majority of applications, the cost to acquire iOS 5 users exceeds the licensing fees they would pay by a high multiplier.  (One of our client discovered that it was cheaper to buy a new device and mail it to each obsolete user than it was to continue supporting iOS 5!)  This is even before considering questions like how, if they are seemingly unaware of the software released by Apple, a multibillion dollar corporation, customers are going to hear about your software.  Or how, if they cannot afford to upgrade a 2-year-old device, they are going to afford your software.

Let’s look at our growth trajectory with two different release dates.  Obviously the trajectory for every application is different–some are linear, some have viral growth, many fail to sell at all.  Some enterprise applications have a fixed customer base. Still other software has a subscription model.  But the value of many kinds of applications (whether in licensing fees, in subscriptions, in business value, etc.) can be modeled with linear growth, so let’s take a look at linear growth after our app’s release:

We could have released our application for iOS 6 only after 90 days, and we would have achieved the growth shaded in green.  Alternately, we could have released our application for iOS 5 and 6 after 110 days, and we would have achieved the growth in red.  The difference between them is our revenue gap, and it is very, very difficult to close.  If conditions are ideal for a very long period of time, the right application may be able to close the gap.  But due to competitive and seasonal reasons there is no such thing as ideal conditions for long periods of time, so the gap is, for all practical purposes, uncloseable.    Not only has our iOS 5+6 app been more costly to produce; but it has also led to decreased revenue at any particular point in time due to a delayed launch.

But even that’s not the full story: the choice is not between the development team working 110 days vs just working for the first 90.  We have to consider the opportunity cost: what the development team could have done instead during those 20 days.  For example, they could have quickly shipped an update adding new functionality, or they could have watched customers use the application and released a quick update making the core app experience better and driving revenues even further.  Let’s take a look at what happens if our development team directs their energy into new features to attract even more customers:

If our revenue gap was uncloseable before, it’s definitely uncloseable now.  What started out as a perfectly innocuous question: “Should we target iOS 5 or iOS 6?” turns out to have implications that will probably save or sink your project.

Unfortunately, many people in charge of mobile projects are still stuck in a pre-iOS mindset where customers are always years behind.  This has been the reality in the desktop world, in the browser world, in the embedded world, and so on for many decades.  It is even still true on some mobile platforms, like Android.

But as we’ve seen, it’s quite dangerously wrong for iOS development.  This is one of the many reasons why, if iOS is an important component of your mobile strategy, it is vitally important to have a mobile strategist who truly understands iOS.  Your competitors have.

If you need a strategist to help you make sense of the iOS market, look no further!  Contact us today and get actionable insight to bring your products to market faster and more effectively.

Adding more people to a late software project makes it later.  – Fred Brooks

In fact, large software teams lead to project stagnation.  Doug Putnam published research from 491 software projects.  His research demonstrates that as a team gets smaller, its overall productivity increases:

And the effort to deliver a software project rises exponentially with the size of the development team:

This seems to be a very nonintuitive result.  How can it be that adding more people to a project makes it worse?

The answer is that software development requires tight communication between all members of the team.  A team of 2 requires only a single communication channel.  But for a team of 7 people, 21 different communication channels are required.  Each member of the team must sync with each other member so that everyone stays on the same page.  As new developers are brought on board, they must be caught up to speed by existing developers who are taking time away from new work to educate others.  Pretty soon, everyone is in meetings, writing documentation, managing wikis, sending e-mails, and trying to communicate with everyone else instead of moving the project forward.  It is not uncommon for members of large teams to spend 80-90% of their time on communicative tasks.  As a result, progress stagnates, and the schedule slips.

A team of just 2 or 3 developers, on the other hand, is a productive team.  With only a few communication channels, each member can spend most of his or her time working on the project instead of answering the questions of other team members.  Meetings can be reduced to just an hour or two per week, and extensive documentation can be replaced with lightweight communication tools.  Small teams appear less impressive, but they ultimately get more done.

At DrewCrawfordApps we deploy small teams on our development projects to deliver quality software quickly and reliably at a pace that outstrips large teams with dozens of developers.  The next time you are thinking about using a large team for a project, consider whether that team will be as productive as a lightweight and agile team without the additional communication overhead.