Android tablets and the tablets of other manufacturers (e.g. BlackBerry Playbook) are selling at rates comprable to failed video game systems from the 80s.

In other words, you are likely not to get a single new customer by developing a tablet app for a non-iPad platform.  Even if the cost to add support for the BlackBerry Playbook was ten minutes, it wouldn’t be worth it.

If you are writing tablet software for anything other than an iPad, you’re throwing money away.

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.

It’s easy to forget in the marketshare battle that Apple’s dominance is much larger than phones.  iOS software runs on three platforms: iPhone, iPad, and iPod Touch, with a combined install base of over 200 million units.  Not to mention Apple’s 11% North America market share in the computer world, which has its own app store.

That’s why we’re focused on delivering native software for Apple platforms.  While we see room for growth in the Android market, we believe that the iPhone and iPad will continue to be the #1 mobile development platforms for the forseeable future.  The iPad is growing so quickly that it’s eclipsing the need for PCs in many situations, but only at the rate that important software can be written and adapted, an important bottleneck.

We’ve written many iPad applications for companies large and small.  Contact us to learn about how the iPad can work for your business today.

To discover this, we need to look back all the way to C, the original “universal” programming language.  Many forget that the original goal was to create a standards-based, cross-platform development environment.  C/C++ is still in wide use today, but everyone will tell you there is no such thing as true cross-platform C/C++.

To rectify this situation, Java was created, the next savior of cross-platform code.  While Java is still widely used (particularly in the enterprise and a strangely Java-yet-not-Java implementation on Android), Java has also failed to live up to its name as a truly cross-platform application development framework, and it was recently deprecated for the Mac and is being largely abandoned as a desktop platform as well, apart from continued use in special niche open-source software and enterprise software.

The new siren song is cross-platform mobile development, the ability to write the code once and have it work on many platforms: Android, iOS, Windows, Blackberry, and more.  Unfortunately this is even more of a pipe dream than cross-platform desktop development, which has seen botched “solutions” dozens of times over its history.  Let’s examine some of today’s mobile cross-platform contenders.

HTML5

HTML5 is a standards-based loose collection of web technologies that let you build applications that run in a web browser.  HTML5 is mature enough that tool and platform support is pretty good, at least relative to the stability of some of the proprietary platforms.

Performance

Like any high-level language, HTML5’s JavaScript suffers from performance problems.  Mobile technology is still at the stage (unlike desktop development) where performance matters substantially.  Technologies we take for granted like garbage collection, while making the programmers’ lives much easier, suffer unacceptable performance penalties that make graphics, animations, and transitions sluggish and the UI appear unresponsive.  Even if you’re not doing complex calculations, basic UI suffers to the point where your users will notice.

We’re still at the infancy stage in mobile performance.  The computing power of an iPhone is, quite literally, the size of a postage stamp (the device is all screen and battery, very little horsepower).  Software advances like the Nitro Javascript Engine are interesting only because the engine they replace is so terrible, not because the new engine is particularly good.  Without an enormous breakthrough in battery life design, HTML5 development will likely continue to have poor performance for the foreseeable future.

Features

HTML5 offers only very limited visibility into device capabilities.  If you want to send push notifications, use CoreAudio, perform advanced GPS or location-based tasks, run in the background, record or edit video, audio, access the users’ Photos or Contacts library, do any sort of data visualization, responsive UI drawing, leverage existing frameworks, do any kind of number crunching or performance-sensitive calculation, display maps, utilize the contacts database, or store much data on the device, you will need to use native code instead of an HTML5 application.  If you don’t need any of those things, an HTML5 app might have enough power to do what you want–but in that case your app isn’t really very exciting to begin with.

Distribution

If you’re interested in distributing your app through the Apple App Store, you need to write native code.  If you want to leverage the iTunes billing system to do in-app purchasing, subscriptions, etc., you need to write native code.  While it is possible to wrap an HTML5 app in a thin layer of native code for this express purpose–unless you already have invested in an existing HTML5 app, it’s almost always cheaper to go the native route to begin with.

PhoneGap

PhoneGap is a small set of libraries that essentially offer a little bit of native glue to access native features while still basically writing an HTML5 application.

Tool Support

Because PhoneGap is so new, the tool support is terrible.  The state of PhoneGap debugging is absolutely awful. There is no debugger, and as good as you will get is printing debug statements to a log somewhere and/or trying to debug in a desktop web browser that behaves differently.  The debugging burden for a system like PhoneGap is enormous, which translates into huge productivity losses.

Performance

Because PhoneGap uses underlying web technologies, performance is the same as HTML5, i.e. not ready for even the most basic applications, at least according to the standards of most iOS users.

Features

PhoneGap adds a lot of native features to HTML5, but is still missing key features  like Contacts access, maps, any kind of fine-controlled media playback, calendar APIs, messaging APIs, access to native UI controls, and many more.

Distribution

Historically, PhoneGap users have had problems getting their apps approved for distribution, although it’s not clear whether or not this is still the case.  The official wiki describes how to hide PhoneGap from Apple and then states “This is not a guarentee, [sic] many users have been reporting rejections after removing all phonegap references.”

Titanium

Appcelerator’s Titanium is a purportedly cross-platform development solution covering desktop and mobile development for iOS, Android, perhaps Blackberry, Windows, Mac, and Linux.

Tool Support

The free tools do not have debugging support.  To get debugging and other basic developer comforts, you need to spend $500/developer/year.  Unfortunately I was not able to find anyone who had paid for the subscription to evaluate the effectiveness of the premium tools.

Performance

Titanium bills itself as a “native” app development environment.  Unfortunately, this is simply not true, at least not by any meaningful definition of the term.  It is only accurate to say that Titanium uses proportionally more native code than other platforms and exposes native controls, meaning faster UI response times in many common cases.  It does not mean that your entire app runs at native speed, since it still relies on the same JavaScript that powers HTML5 web apps, which suffer terrible performance problems.

Distribution

We’re aware of no problems related to distributing Titanium-based apps on the App Store.

Cross-Platform Compatibility

Because Titanium tries to be a “more-native” platform, it has many cross-compatibility problems, as native UI controls simply work differently on Android vs. iOS, and there’s no one-to-one mapping that will work perfectly, in spite of Appcelerator’s best efforts.

The problem that you then end up with the situation where I developed for iOS but didn’t test it on Android. I had faith that if it worked properly on iOS then it would still work fine on Android presuming I didn’t use any “platform specific” functionality. The problem is that it very quickly gets to a situation where everything doesn’t work properly on Android and it requires lots of time to fix the issue. Cross-platform? Not really.

If you’re technical, I would highly recommend reading Sam Moffatt’s entire review, as he does an excellent job relating the dozens and dozens of little snags in developing the most simple application in Titanium.  He documents inconsistent behavior between platforms, documentation that is completely missing or (worse) misleading, etc.  Titanium ends up being a passable development platform for certain situations, but completely fails in its effort for cross-platform compatibility.

So What’s the Right Way?

The right way is to write a separate native application for each platform.  This requires high time, effort, and expense, but it is the only way to provide a high-quality experience (i.e. one worth paying for) to your users.

If a platform is worth supporting at all, it’s worth supporting right.  Bad app experiences damage your brand and cost you valuable reputation with your customers.  Unfortunately we see many potential clients led astray by the lure of cross-platform development, only to end up with buggy software that runs poorly on any platform.  For many applications, true Objective-C-based native development is the clear best choice.

If you’re interested in letting us develop your native iPhone or iPad project, get in touch today.

Apple’s market is more profitable

Don’t believe the sensationalist articles proclaiming that Apple’s declining marketshare translates into lower revenue.  It doesn’t.  Market share doesn’t matter.  Apple controls 76% of the apps download market.  When comparing actual revenue dollars, Apple’s App Store has an 83% market share.  If you’re looking to make money from mobile in 2011, Apple’s App Store makes the lions share of the money and beats Android hands-down.

Apple has more reach

When you develop for the iPhone platform, you also reach iPod Touches and iPads, two enormously overlooked markets that simply don’t exist on other platforms.  Tablet devices for WP7 are nonexistant, and Android and Blackberry tablets have so few units that they’re usually not worth reaching.  No market has a low-cost popular device like the iPod Touch, which has over 60 million units.

Reduced cost

Many clients ask us “how difficult is it to port applications from iOS to Android?”  Almost without exception, the application has to be rewritten from scratch when porting from one platform to the next.  The technologies underneath mobile platforms are as different as night from day.  User interface idioms should be preserved so that the application has the distinct UI characteristics of the operating system, so often artwork and even screen layout cannot be preserved effectively.  Multiplatform development almost always adds double or triple the development cost of single-platform development.  We encourage our clients to release first on iOS, and use the revenue numbers to evaluate pros and cons of adding another platform.

Focus & Experience

Mastering mobile development for iOS or Android takes many years of experience.  Mobile development is much harder than other types of development, such as web development or desktop development, since tight performance, battery life, networking, memory and other constraints are imposed upon the application code.

Many of our competitors who advertise multiplatform development either outsource  one or more platforms to other (sometimes questionable) companies or hire unqualified generalists who use point-and-click tools but do not have the in-depth engineering knowledge required to make your application shine.  At DrewCrawfordApps, we focus on the iOS platform so that we have a deep understanding of the challenges in creating iPhone, iPod Touch, and iPad apps.  Our strong focus and specialization is part of what makes us the best in the app market and gives us the unique insight and engineering skill that other firms can’t match.  We’re not distracted by “mastering” every new platform that comes out, but instead we’re focused on continuing to develop an extremely deep expertise in iOS.

If you’re looking for an Austin-based iPhone or iPad Developer, contact us today!