We, and other mobile development shops that I’ve spoken to, can tell stories of clients who are stunned by the time and cost needed to build a quality mobile app. We’ve gotten to the point on the web where creating a simple website can be done by a large number of people (and therefore at relatively low cost), and while YMMV as far as quality, it can be done.

On the mobile platform, things get complicated (and expensive) pretty quickly. Here is a rundown of some of the things that make mobile hard. Note that each of these could be a topic unto itself, and perhaps will be in a future post.

Andoird vs. iPhone vs. Multi vs. Mobile Web
Before you even get started, there is a critical choice of which of the two major platforms you need to support, and if there’s a case to be made for using some of the tools that let you write once and compile to android or iphone. Or perhaps a mobile-optimized website might be enough for your needs (a post for another time).

Design
Design for the iPhone is different from design for Android. Android users have the buttons at the bottom for back / settings, which iPhone users are lacking. Each has its own modalities that the user base is accustomed to. Additionally, physical factors come into play in a way they don’t on the web, such as accounting for the size of a person’s thumb when designing a button, or figuring out where to put navigation or other controls (top/bottom, sides, etc.).

Additionally, mobile devices come in a staggering number of screen sizes, form factors, and resolutions. Android is especially problematic here, but even iOS with the release of the iPhone 5 can be “regular”, retina, iPad, iPad retina, or the taller iPhone 5 display. Each of these needs to be accounted for if not designed for, and then tested.

High Expectations
This ties into design as well as implementation — but people expect an app to be snazzy, fast, cool, interesting, engaging. And it should be all these things on a wide range of hardware and operating systems, some of it years old and past its prime. So an early decision needs to be made as to what to support, just so that these promises (explicit or implicit) can be fulfilled.

Evolving APIs
Even an experienced iPhone developer needs to constantly be upgrading skills and learning about new technologies and techniques. Not too long ago, Grand Central Dispatch wasn’t widely available for threading, Interface Builder was a separate app, and CoreData was just getting started. As recently as 6 months ago, retain/release was still critical, storyboards were brand new if they even existed, etc. And now with iOS6 there are a host of new conventions, techniques, etc. to learn. So even a senior developer faces a learning curve on just about every project.

Even if you are building for the cutting edge, there are backward compatibility issues for users with older devices and older operating systems.

Testing
I had the occasion today to add a developer to TestFlight, a great platform that actually makes sharing deployments easier. To do this, I had to get the user’s UDID (buried deep in iTunes), include the UDID in the provisioning portal, DOWNLOAD the profile, recompile the binary with that profile, re-upload to testflight, reissue the invitation, and finally get confirmation that it worked. And that’s the EASY way. Some of that might have been avoidable with some better TestFlight-fu, but the point is that it wasn’t easy or direct.

Once a bug is found, there’s no rapid cycle of “hey, did that fix the problem? How about that?” that folks have gotten used to when reporting bugs on the web. In short…

Mobile is Shrink-Wrap
With formal builds being pushed out to centralized app stores, mobile apps resemble shrink-wrap software more than web development. Got a bug on a website? Call the developer and within minutes / hours it can be fixed. Similar bug on mobile? It needs to be fixed, tested, packaged, sent (possibly for approval), and then it finally goes live. This process takes days if not longer.

Uncertain Business Model
Once the app is built and out there, how is it paying for itself? You can hope/pray for the home run, but short of having a million people downloading it at $0.99/pop, how will it make money for the company, directly or indirectly? These questions need to be answered early on in the process and affect design up front, but can also come back around later in the process if the environment changes or if new factors surface.

Got other challenges on the mobile front? Comments welcome…