But it’s not enough just to have the idea of producing a simple phone.  Everyone knew that phones were too complicated.  It was a different matter to actually build one.  This is what was so hard.  Simple to use and simple to build are two very different things.

When RIM ( the creator of the Blackberry and the market leader) saw Steve Jobs’ simple demo, their reaction was not to copy the “great idea” of building a simpler device.  Their reaction was to laugh it off as impossible.  It couldn’t be done.  It was too difficult to build.

Apple was effectively accused of lying as it was supposedly impossible that a device could have such a large touchscreen but still get a usable lifespan away from a power outlet.  [RIM believed] the iPhone “couldn’t do what [Apple was] demonstrating…”

RIM is not a stupid company.  Their assessment of the iPhone as virtually impossible to build was completely accurate.  Their only miscalculation was just how many tens of billions Apple was willing to spend to bring this “simple device” to market.  Over 200 patents.  Billions of dollars in acquisitions.  Nearly 5 billion in R&D.  Thousands of full-time hardware and software engineers.  Investing billions in chip design at a time when every other computer manufacturer has outsourced all design overseas.  All to build a simple phone.

Like the iPhone itself, looking at an app project from a consumer’s point of view is like looking at the tip of the iceberg.  “Simple” applications are always the most difficult kind to build, because they require all of the complexity to be carefully hidden from the user.  Simple, well-designed applications have so much hidden below the surface.

Complex applications, in contrast, can sometimes be the easiest applications to build.  The easiest app to build is the one that does nothing–that requires the user to do all the work.  The less work the user has to do, the more work the programmer has to do, and the more complicated the project will be to build.

This is why it is so important to have a software developer on your team from the start.  A good developer will instinctively know what is “below the surface” for any proposed feature and will be able to guide the design to stay within budget and focus on those features which can be implemented within time and schedule constraints.

If you don’t have a software developer on your team from the start, you are doomed to making terrible decisions about designing any app, big or small.  You can only see what is “above the surface”, and you have know way of knowing if the “simple” menu you asked for is a few hours of effort or it really has a few months of costs submerged below the surface.

Misunderstanding this “iceberg principle” is perhaps the most common source of software project failure.  In the industry, it’s called the 90-90 rule:  the first 90% of the code takes the first 90% of the time, but the last 10% of the code takes the other 90% of the time.  In other words, the time and cost to implement a feature often has no determinable relationship to the user-visible part of the feature.

From our vantage point in the iOS development market, the unfortunate design procedure is usually something like this:  the client comes with a laundry-list of features without any technical guidance in creating the list, a list full of iceberg-features.  The client is tight-lipped about the budget because they want to shop the project to many different firms.  None of the contractors are sure whether they should cut a few of the pricey features to fit inside a budget, so everybody guesses what number the client wants to hear.  The company that wins is the one that says the lowest number–the company that failed to see most of the submerged complexity–usually the least competent firm.  Then the project runs over-budget and fails.

In reality, software development is a conversation.  Here’s what can be done for $20k, here’s what can be done for $50k, here’s what can be done for $100k.  If you  haven’t had that kind of conversation directly with a senior developer (not a sales rep), your project is doomed before you’ve written the first line of code.

This is a little oversimplified; some of these issues can actually be overcome through Herculean engineering efforts.  For instance, although there is no officially-supported way to record phone calls, we engineered a custom solution to make it work.  But those sorts of endeavors are very high-budget projects, if they can be done at all.

Accessing user data.

Applications have strong restrictions on accessing user data.

• An application cannot read or access a user’s e-mails or SMS messages.
• An application cannot automatically determine a user’s e-mail address or phone number.
• An application cannot read data from other applications or send data to other applications without the explicit cooperation of the developer of the other application.
• An application cannot access a user’s call logs, call history, or listen in on phone conversations.
• An application cannot look at a user’s browsing history.
• An application cannot find out what other apps a user has installed.
• Even if user data can technically be collected, there may still be restrictions on its use.  You cannot just mine user data.

It should cost much less!

Sometimes it does.  Certain applications may simply not need certain components.  Coke or McDonalds may not need a PR campaign to launch an app–their existing brand recognition may be enough.  Highly technical apps designed for engineers may not require much in the way of design work–accurate technical bits may be enough.  Apps that rely heavily on off-the-shelf components may not require much QA.  And so on.

You may elect to learn some of the disciplines and do them yourself.  We’ve had professional graphic designers, marketers, and even other developers as clients, and so in these situations it’s not uncommon for a development firm to back off and have the client take more responsibility for the project–reducing the cost.  But if you’re not a professional, taking on responsibility can be a costly move when measured in terms of lost sales.

Another tactic is to aggressively cut scope to reduce costs.  It may be possible to cut features to get a Client/Server Application into the Standalone category, or to significantly reduce the complexity of the server tier by cutting features.  By reducing an application to a mere prototype, it may be possible to produce something tangible that can be used to acquire funds to develop it further.

There is also a certain amount of variation in developer costs.  For instance, we have no sales team to pay, and since we rely primarily on the strength of our work for business, our marketing budget is close to zero.  So our costs tend to be lower than shops with an army of sales staff and billboards on both sides of the street.  On the other hand, our estimates tend to be more accurate than the competition, and since projects are universally underestimated, sometimes realistic numbers can be higher than what others quote.  These effects can cancel each other out.

But far too often, instead of responsible scope cuts and other cost-cutting measures, corners are cut instead.  Software may be outsourced and developed poorly, QA may be forgotten entirely, design may be sent to the back of the bus, and so on.  In the rush to ship some product, it’s easy to lose track of what the value of that product is.

Suppose you are trying to build a strip mall in a populated area.  You find a plot of land that is next to a high-traffic road, do some research to determine that a strip mall could be reasonably successful, and start talking to architects and contractors.  They tell you that a typical strip mall is constructed for in the neighborhood of $5M.  Unfortunately, you only have $20,000 for the project.  Undeterred, you start trying to cobble together a team of temporarily-unemployed electricians on Craigslist, some freelance architects in India, and since the budget for materials is tight, you decide to construct it from corrugated cardboard.  It does not take a genius to work out that this will not be a successful project.

In fact, there are many successful avenues open to you–with $20,000 you could build a furnished treehouse or shed, you can give your home a new room or a remodel–these are realistic construction projects within your budget.  These projects have the advantage that you are not simply throwing your $20,000 away.

The same common sense does not seem to extend to iOS projects.  Undeterred by the true cost of building that strip mall, many people are trying to piece their apps together out of corrugated cardboard.  But unlike the construction industry, where there may be building codes, inspections, city ordinances, standards of practice, and professional organizations to protect people from scams and swindlers, there is unfortunately no equivalent for software development.  It’s the closest thing there is to a completely deregulated market.  And it’s the perfect condition for a lot of companies to come out of the woodwork to say what people want to hear–that with this industrial strength corrugated cardboard, you too can own a strip mall!  It’s a sales pitch older than Amway.

With good advice from the right developer, you can figure out what is possible within your budget and execute a sensible plan instead of an insensible one.

Wrapping Things Up

I hope this series has shed some light into the time, effort, and cost it takes to launch a successful iPhone or iPad app.  I’ve barely scratched the surface of what goes into project costs, even in a massive three-part blog post!

There are many factors to consider when thinking about any software development project, and every situation is unique.  If you’re interested in talking to a real developer about a realistic way forward for your project, get in touch.

App Types

iPhone or iPad apps are not all alike.  You have several different kinds of applications.

Each of these application types may require a slightly different skill set, have a different time and cost profile, and require developers with different expertise.  Counterintuitively, it can sometimes be a mistake to try to find developers with experience building applications very similar to yours.  Generally speaking, developers with experience writing very complicated application types will be more effective at simple applications than those that have only developed simple products (Just as mathematicians are generally better at Algebra than high school graduates).  And so it’s important to identify the type of application you’re building in order to assemble the right construction team.

Standalone applications

Standalone applications are self-contained.  These applications can do data processing, display static content that doesn’t change, manipulate documents, and do other types of basic tasks.  Development time and effort varies primarily based on the type of processing required (file format support, etc.) and the complexity of the user interface to design and implement.

P2P applications

Peer-to-peer applications do some light app-to-app networking, like a multiplayer mode for a game.  They generally involve connecting with nearby users over Bluetooth.  This type of networking requires additional debugging and testing involving multiple phones or devices.

Pre-existing API or integration applications

The next tier of complexity are applications that talk to pre-built servers.  For instance, your company may have a database of information to be queried by the app, or you may be accessing data from a third-party data source.  Time must be allocated to learn the quirks of the API or server, to debug problems with communication, and to handle unusual error conditions.

Client/Server applications

Certain applications requires a server for off-phone storage and processing.  For instance, if your application allows users to save reviews, share status updates, search for nearby users, display content that updates on a regular basis, or other nontrivial tasks, a server is required to store and distribute this data to all devices.  Client/Server applications are one of the most common types of applications that people want to build.  Unfortunately, because Client/Server applications require both complete application development and complete development of server software, plus hosting and other ongoing costs, they tend to be both one of the most complicated and most expensive project types.

Multi-platform development

Apps that run well on more than one platform must typically be rewritten largely from scratch for each platform.  So if you are looking for an app that supports iPhone, iPad, Blackberry, Desktop Web, Android, and Windows Phone 7, you are looking at approximately 6x the cost of what that app would be on one platform.  If the platforms communicate in a networked manner, care has to be taken to define standards in an interoperable way.  In addition, most cross-platform projects engage different development teams for each platform, as most developers of quality only know one or two platforms well.  Doing cross-platform development correctly often requires the engagement of multiple firms as well as a “master” firm that writes the general specification.

Specialized technology, research

Some applications, like Augmented Reality applications, indoor location systems, or other technical challenges may require the development of novel methods or intellectual property.  Like any kind of invention, the time required to develop new technology is unbounded.  Many different approaches may need to be tried and combined to achieve the desired result, or the result may not even be achievable within the limitations of the current generation of technology.

Impossible applications

We sometimes get request for applications that are not possible on iOS, at least in the App Store.  These include things like affecting the behavior of other applications, modifying system settings, disabling features of the phone, accessing restricted data such as user e-mails, etc.  Apple has limited what App Store apps can do in order to prevent malicious apps from stealing user data, breaking a phone, or other matters of poor user experience.  If it’s a simple idea that doesn’t already exist in the store, it’s probably because technical or legal restrictions are in place that prevent it from being easy to execute.

Now that we’ve identified the type of application and learned something about the required skillset, it’s time for Part II: assembling the team.

Adding AirPlay to your app could make it that much more useful and give it an edge against similar apps. It can help to clear up clutter around a home, can give presentations some flare, and can even aid in important planning processes.

Around the house, users will find that having just one device for all of their media will help to clear up clutter. Entertainment becomes simple and costs drop as the need for extraneous devices such as DVD players dissipates. As a result of fewer devices, the number of wires needed drops. All these advantages can also be useful if a user wished to throw any sort of party. Music and videos become easy to maintain and accidents caused by wires lying around no longer are a problem. Having so many benefits and few restrictions means that any app that included AirPlay support would appeal more to users interested in convenience around the house.

Many schools and businesses like to have support for apple devices as they help to simplify many processes. Presentations are made easier with AirPlay since users can simply stream whatever media is necessary whenever they wish and with a high degree of control. In a school for example, students or teachers can whip out their ipod or ipad, begin streaming media and have a smooth, seamless presentation, improving quality of learning, classroom atmosphere, and student grades. Another possible situation where an AirPlay feature would be useful in a presentation is in a business setting. Presenting products to potential customers can be made more effective by including some form of visual aid; this is where AirPlay comes in. AirPlay can make it simple for the presenter by giving him or her more control directly from an iPod Touch or iPad and can make it more pleasing and interesting for potential customers. Clearly, any app with AirPlay support can be an asset to large businesses and schools.

Diagrams are used in many cases in industry; architects use them to represent plans, manufacturers decipher them to get specifications for products, and even doctors use them in the form of X-rays and the like. In many cases, the diagrams are quite voluminous and clutter workspace. What if all of the jumble could be removed? If one could get all of the diagrams into digital format, then users could use AirPlay to display diagrams on large screens or even on projector screens. Disorder would be minimized and more power would be given to the user(s); the power to expand diagrams or focus on specific parts. This would improve productivity and so make the app more appealing to large corporations and other industrial work settings.

Urban Apps is the owner of an app known as Ambiance. Ambiance is a highly rated and popular app even to the extent that Apple included it in every demo iPhone in the Apple Store and also in the app store. It has been set on several lists such as the “Staff Favorites” list and the “What’s Hot” list. Urban Apps has announced that their newest release (v 3.1) of Ambiance will have AirPlay support.

The Frontier Design Group is the proud owner of the iShred app. iShred has been given high ratings by several different groups such as MacWorld, TouchMyApps, and Sizzilla. In a review MacWorld says, “Of all the guitar apps available on the App Store, Frontier Design’s iShred is my favorite.” Included in the release of iShred 1.3 is AirPlay functionality.

Having AirPlay functionality in an app means that more users will find convenience and simplicity in using it. This will help to increase sales as convenience and simplicity greatly increase the appeal of marketed items to the general public. People will find that the app tremendously simplifies their lives and will spread the news, increasing the attractiveness of the app.

DrewCrawfordApps is in a great position to help you out with integrating AirPlay into your app. Our specialized developers have the technical savvy and ingenuity to do this. Being on the cutting edge of iOS development, we have helped countless others and are willing to help you improve your app by adding AirPlay functionality to it. Get in touch today so that we can help to make your app a booming success.