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.

This chart covers all phone sales, not just smartphones, and the whole world, not just the U.S.  This teaches a powerful lesson: more marketshare does not mean more money.  Not all customers are created equally.  Android’s marketshare looks impressive, but when you drill down into the details, you discover that one Apple customer can drive as much revenue as 5 or 10 Android customers.

This is just one more reason to focus on iOS as the primary platform for your application.

Most iOS users can upgrade

Unlike other platforms where software updates are provided for very limited windows, Apple’s updates run on devices up to two years old.

Apple works hard to make new versions of iOS available to an unprecedented number of users, even those users who may be running older devices.  The vast majority of your potential customers don’t need new hardware to run iOS 5.

Most iOS users have already upgraded

Within 5 days of launch, iOS 5 was in use by 33% of devices.  Marco reported in November that 48% of his customers were running iOS 5.  Bump reports that iOS 5 penetration is about 60%, (with the next-oldest OS, 4.3.3, being a paltry 9%).  Our internal statistics show that our customers are close to 70%-80% iOS 5 users.

And don’t underestimate the length of your development cycle.  New applications often take 90+ days to develop, and by the time your application actually ships, the numbers will be even higher.

Supporting iOS 4 is expensive

Supporting iOS 4 means double the test burden, means that everyone has to buy extra devices to test older configurations, and means that the cost to test your software triples.  These are the obvious costs.

Supporting iOS 4 has hidden costs too:  it means that great developer features introduced in the last 6 months can’t be used in your application.  This increases development time and cost significantly, as complex “workarounds” have to be created to avoid the use of these features.  These design choices can have long-lasting permanent effects on your software’s code base that will far outlive iOS 4.

But there’s another hidden cost:  supporting iOS 4 means using fewer iOS 5-specific features.  Apple users expect a high-value experience on their shiny new Apple device, and if your application fails to deliver the latest and greatest, you’ll get bad reviews.  If you have a competitor who produces a more highly-featured application, expect a large portion of your customer base to pass over your app in favor of the competing one with iCloud support and Notification Center integration, Twitter integration, and other iOS 5-only capabilities.

Supporting iOS 4 is bad for business

At this point, most of the iOS 4 holdouts are either people with very old devices (cheapskates unlikely to buy your product), or users who are technically incapable of performing a software update (and who will present a high technical support burden).  These are not the kind of customers you want to be burdened with.

Supporting iOS 4 can be attractive in a requirements list, but it can be a costly exercise that provides no real revenue to justify its cost.  Many developers make good money supporting iOS 4 at a markup, but in the best interests of our clients, we recommend that the vast majority of new applications be written to support a minimum of iOS 5, and that significant (non-bugfix) updates to existing apps seriously consider dropping support for older versions of the OS.  Focusing on iOS 5 provides the best value for most projects, and redirecting legacy costs into new feature development can be much more exciting for both you and your customers.

It’s not even a fair fight.  Even the least-owned iOS device, the iPhone 3GS, beats the pants off the most popular Android device.  If you’re targeting enterprise users or business users and you’re developing an Android version, you’re throwing money away.

Things get even worse for Android when you consider operating system fragmentation.  Here’s the same chart that overlays the latest supported operating system for each device:

Writing a universal iOS application targeting iOS 5.0.1 is hands-down the best value in the mobile development world.  Targeting the single iOS 5.0.1 version gives you access to the vast majority of customers.  Targeting Android means targeting many different versions of the Android OS to gain only a tiny amount of additional marketshare.

Here’s a combined chart:

Notice anything strage?  Android Tablets in business are competitive with Bigfoot sightings.  If you are developing business software for an Android tablet, you need to stop immediately.  You’re better off just shredding your money.

This person is making a better investment than developing an Android tablet application

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.

Higher Productivity and Lower Costs

According to VersionOne’s 2010 study, 66% of agile practitioners report faster time-to-completion for software projects.  More than half of all respondants report that agile has “Significantly Improved” or “Improved” their ability to respond to change, alignment with business objectives,   team morale, time-to-market, productivity, software quality, risk management, engineering disciple, and software maintainability.

But a significant feature of Agile is that developers are less likely to build software that is no longer needed.  When software development iterations are large or are done in a “big bang” fashion, the long lead times between specification and delivery can mean that the features requested are no longer relevant to users.  Shortening the feedback cycle means that engineering resources are spent on delivering features that are actually useful, instead of out-of-date by the time that they are delivered.

VersionOne found that 74% of those surveyed reported that morale was improved through the introduction of agile processes.  Improvement in developer morale not only means higher-quality productivity as developers are motivated to work harder to ship software, but also that the highly mobile top tier of technical talent can be more easily acquired by the organization.

Faster to Market

Rally Software’s in-depth study of agile development showed that Agile practices lead to a 37% faster time-to-market for software projects vs traditional methods.

Salesforce.com reports a +568% increase in features delivered to customers as a direct result of implementing agile methods.

Higher Quality

David Rico’s research on Agile development showed that Agile projects have a median quality improvement of 63% over traditional methods and a minimum quality improvement of 10% in the companies he surveyed.  84% of the VersionOne survey respondants felt that Agile methodologies had reduced the number of bugs by 10% or more.

Improved Client Satisfaction

With all of these improvements, it’s no wonder that these practices lead to higher satisfaction among iPhone project clients.  iPhone development is a fast-changing world that moves even more quickly than other types of web, desktop, or systems development.

Many potential clients make the common mistake of adapting a traditional software development process to the mobile development world, without a true understanding of the assumptions and underlying requirements of the development methodology.

The iOS software market is much  more competitive than the traditional software market, because there is only one primary sales channel–the Apple App Store.  As a result, millions of software products compete for the same real estate.  Even in a “niche” vertical, there are often many software vendors competing for customer dollars.  If a competitor is using a lower-cost development methodology, that competitor will be able to consistently deliver a higher-quality experience to its users, putting you out of business.

Even if you have no competitors, Apple itself dictates a rapid pace for the iPhone and iPad application market.  iOS, the iPhone and iPad operating system, is currently on a yearly release cycle.  Because of Apple’s highly secretive product roadmap, it is very difficult to predict the future in this market.  Apple’s rapid improvements to iOS can obsolete dozens of product lines from individual developers overnight.  Sudden announcements can cause an unforseen shift in development, due to added or removed functionality in the underlying operating system or new hardware capabilities.  In this challenging marketplace, it is more important than ever to adopt an agile software development process for your iPhone projects, both to stay current on the latest Apple development practices and to remain competitive in a marketplace of other agressive software developers.

It should come as no surprise that according to a study at Colorado University, an overwhelming 80% of respondents reported an increase in customer satisfaction after introducing Agile methods.  Agile development methodologies are an important ingredient in our overall strategy at DrewCrawfordApps to deliver the highest quality software at the fastest possible speed.  When selecting a development partner for your iPhone project, make sure you are working with a development team with an understanding of the unique challenges of the iOS marketplace and with a development strategy that will lead to success for your iPhone development project.

“We’re 100 people, but we have work for 130 people. We just don’t have those extra 30 bodies,” Michaels says. He adds that salaries for experienced iPhone developers “just keep going up. Our year-over-year salaries are up almost 20 percent.”

iOS development is a demand market right now. There simply aren’t enough qualified developers to meet the enormous business demand. Due to the high technical nature of iPhone and iPad development work, this is a situation unlikely to improve in the near future.

The high market demand is pushing unqualified and marginally-qualified developers into the market, who are unable to deliver on business objectives. This is why horror stories of bad hires and bad contractors on the iOS market keep getting published. TapTapTap, a market leader in iOS publishing, writes about their bad contractor experience:

We continued to sink a lot more money into the project, partly because we wanted to add some cool features that we came up with, but mainly because Daniel couldn’t deliver anything even close to being worthy of shipping. And even though we weren’t supposed to pay until completion of the project, we did so on good faith, mainly because of Daniel’s never ending sob-stories. literally months would go by without an ounce of work being done on the app. When he did actually come around to doing some work on it, subsequent builds improved slightly, but we never got the the point where someone would ask us about plasma and we’d be proud to show it to them… instead it was usually quite the opposite and more of an embarrassment for us.

MacWorld has this to say about overseas outsourcing:

“This is not a skill that goes well with outsourcing because the typical shops in India and the Ukraine are focused on wider-breadth technologies such as Windows, and there aren’t a lot of Mac developers there,” Michaels explained. “Most of the Mac developers have always been around Cupertino and San Francisco, where Apple is located, and there are some in Seattle, Portland and Vancouver.”

When you are looking for an iPhone or iPad developer for your project, make sure that you do the technical due diligence to hire a candidate with a track record of timely delivery of iOS projects that operate well, are written with best practices in software engineering, and meet technical and functional requirements. Your project is too important to leave to chance.

Some of the major improvements, from an app developer point of view:

• The new A5 chip will give mobile developers new opportunities for complex calculations. More than just the gaming examples Apple demonstrated in the keynote, productivity and business applications can also reap large benefits from the new chip.
• The new camera and photography software will place an increased focus on video and photography applications. We see photography and videography apps as a major growth area on iOS.
• Although Siri is still in beta, at the moment we are not aware of any opportunities for third-party developers to integrate with Siri and allow voice control of their applications.
• AirPlay Mirroring, introduced on the iPad 2, makes it easier to display iOS apps in presentations.

The iPhone 4S is largely an incremental improvement over its predecessor rather than a complete redesign. It has many new and exciting features, but at this point it does not represent as large of a shift in iOS app development as iOS 5.

We have been testing iOS5 for several months now, and we are very excited about many of the new features:

• Twitter Integration & Game Center improvements – Integrated properly, this can make apps more discoverable which translates directly into improved app rankings and sales
• Newsstand – this is an important new feature for magazine and subscription applications. We expect to see many print publishers produce apps incorporating these features.
• Notification Center – this will make notifications more useful in general. Since many applications send push notifications, this will make notifications less intrusive to users and will make it more likely for users to subscribe to push notifications knowing that they will be less invasive.
• iCloud – we believe the ease of integrating iCloud and cloud syncing will reduce the technical bar to creating applications that share user content across multiple devices. With many users purchasing second and third iOS devices, data synchronization is more important than ever.
• Automatic Reference Counting – while it’s not a user-visible feature, this important new technology helps reduce the cost and effort of writing iOS applications. We are working hard to get ARC technology baked into new applications and future updates.
]]> //volume-purchase-program-new-private-distribution-options/ Tue, 20 Sep 2011 06:51:28 +0000 //2.0/?p=595 Read More]]> Apple’s Volume Purchase Program opens new opportunities for certain types of distribution scenarios.  Originally designed for educational institutions, the Volume Purchase Program has recently been opened to all businesses.

How does the Volume Purchase Program work?

The Program allows one developer with a Standard Developer Account to sell applications directly to eligible purchasers without making the application publicly available in the app store.  The developer enters the e-mail address of the purchaser who is then authorized to purchase licenses of the application from the developer.

Do VPP apps need to be reviewed?

Yes, Volume Purchase Program applications need to be reviewed like all other app store applications.  The addition of the VPP program does not change the fact that all externally-distributed apps must pass app review.

What’s the difference between VPP and in-house deployment?

In-house deployment typically requires the enterprise to host the application on its own servers and/or distribute the application on its own infrastructure outside the app store.  VPP applications are distributed via the app store, but are only available to authorized purchasers.  With VPP applications, end users update applications in the familiar way using the app store on Apple’s infrastructure.  Purchased applications can be distributed to the actual end-users via promo code mechanism or through the enterprise’s MDM or over-the-air distribution tools.

VPP applications allow the developer to sell the same application to multiple authorized purchasers, whereas it typically requires extensive changes and deployment headaches to deploy an in-house application to multiple enterprises.

VPP applications are licensed per-seat through the App Store with Apple as an intermediary and payment is provided to Apple via credit card.  For traditional in-house development, the enterprise typically pays the contractor or in-house employees directly on a per-project basis or as otherwise negotiated.

With VPP, application updates and maintenance are generally under the control of the developer.  VPP applications do not generally come with source code, although this can be separately negotiated.

What’s the difference between VPP and traditional app store deployment?

VPP applications can be restricted to only authorized purchasers approved by the developer.  VPP applications are not available for purchase by the general public.

VPP applications have a minimum price point of $9.99/license, vs the typical minimum price point of Free or $0.99/license.

 Should I be using the Volume Purchase Program for my application?

If you are writing consumer software, you should not use the Volume Purchase Program.  Continue to use the standard App Store distribution model.

If you are creating an application for a specific company (which can be your own, but does not have to be), we recommend continuing to use in-house distribution, not the Volume Purchase Program.

If you are writing an application for multiple large companies, or an application that only requires minor changes to be used in multiple enterprises, licensing via the VPP program may be the right fit.  In addition, if you are looking for a whitelabel or custom version of an existing application for use in your business, the Volume Purchase Program may be an option to consider.

To see if the Volume Purchase Program is the right fit for your application, get in touch with an iPhone developer who can answer questions specific to your situation.

]]>