When Your Baby Is The Ugly One

When Your Baby Is The Ugly One

This scenario plays itself out repeatedly:

Company A releases a great new mobile app. Initially, it runs on only mobile OS X.

Users of mobile OS Y decry how epic this FAIL is on the part of Company A, how clueless they are, and how they are totally missing the boat and losing their business.

Wash. Rinse. Repeat.

Trust me – companies don’t go out of their way to NOT service their customers and consumers.

These decisions are based upon market share, money on hand, time to market, and availability of manpower to build product.

In short, it’s business.

For the most part, this script usually translates as: Company A releases an iPhone app, initially. Users of Android, Blackberry, Palm, etc. are unhappy that they are being slighted. They think the company doesn’t value them.

In fact, the company is probably coping with a small set of developers, looking to get the biggest initial bang for their constrained development resources, and has every intention of getting their product on these other platforms, as time, resources, and money permit.

Apple’s ability to allow consumers to discover new applications is superior to what Android and Blackberry offer. I’m sorry. It just is. You can’t browse the Android Market or the Blackberry App World from your laptop to discover apps. You can with the App Store. Therefore, the chances for new consumers to discover, disseminate, and advertise your new app are greatly multiplied by releasing an iOS version, first.

Again, this is a business decision, not a straight-up fan boy love affair.

Yeah – it totally blows to have to wait for something the other cool kids are playing with now (hear that Twitter? Still waiting on “new” Twitter. Le sigh).

This is how I, as a cross platform developer, look at these platforms when trying to design and develop a new commercial product. I’m keeping “religion” (i.e., the relative merits of open source vs. closed source) out of this discussion in the main, aside from mentioning availability of sample code:


Pros: Has maximum reach, best application discovery, best user experience with regard to UI and overall integration, highest quality store; customers spend actual money here. Best UI design tool of any of the mobile smartphone environments (Interface Builder) . Easiest to system test code, because you only have 3 basic iPhone models.

Cons: Strict curation can be an impediment to delivery. Wait times for approval have gotten better, but definitely adds friction to the process.


Pros: Easiest to ship, fastest growing smartphone OS. Lots of open source examples. No curation to get your app in the market, which means revisions and bug fixes happen in “internet time.” The ability to customize AVMs for creating device simulator configurations is the most flexible across all OS SDKs.

Cons: Horrible UI design tool. No application discovery, aside from third party websites. No curation in Android Market means anything goes. System testing is a nightmare, because you have a cross product of dozens of combinations of hardware and OSes that realistically won’t be fully exercised by small developers. The user experience across carriers is inconsistent – anyone who have ever implemented an application on Android that has to use the camera can attest to the variability in operation, quality, and performance. Fragmentation really doesn’t capture how fast this is getting worse rather than better (see: Verizon and Amazon creating their own market, see: carriers installing root kits to frustrate rooting, see: application filtering by carrier).


Pros: Huge installed base of devices. Market leader in penetration inside of enterprises. Secure. Dozens of software simulators available for testing.

Cons: Worst SDK of any smartphone OS. SDK runs only on Windows (technology release now available for Mac OS X, but no simulators and it works only for directly attached OS 6 devices, which is one: the 9800 Torch). No UI tools, periodWorst developer community of any smartphone OS (no disrespect to the many fine BB developers I have met the past couple of years. But in the main, most of these guys – and they are guys – are usually company drones that I for the life of me can’t seem to find any actual apps that they have written. Prolly cause there’s only 9,000 apps in Blackberry App World, and unless you have a Blackberry Phone with a data plan, you’d never see ’em anyway). Multiple OSes, hardware form factors make unit and system testing impractical for rapid releases. Browser – with the exception of the latest OS 6 release – is the absolute worst of any smartphone. Research in Motion also doesn’t seem to really care about software, except for only the sense that it is needed to operate the hardware. They’re a hardware company first and foremost, and it shows in spades.

Your mileage may vary.

But since the majority of application release scenarios we see play out in the marketplace are iPhone First, Android Second, Blackberry when we get around to it, I don’t think my take differs from those actually doing cross platform development, rather than those opining about it.

Nobody likes to have their baby called ugly.

But when it is, it is.

When One-Size-Fits-All, It Never Fits Best

When One-Size-Fits-All, It Never Fits Best

Back in the late 80’s – mid 90’s, I was a director for a company that wrote a point-of-sale package for convenience stores. It was called POS-Plus (whether it was “piece of shit” plus or “point of sale” plus probably depended upon which way the wind blew – but I digress).

Anyway, one of our great ideas at the time was this: we were tasked with being able to “talk” to any type of gas pump at any convenience store across this great nation and integrate the operation into the workings of our cash register software.

Our “bright idea” was to partner with a third-party company that was a titular “universal access box” that could communicate with any pump manufacturer (at the time the big three were Tokheim, Dresser-Wayne / Schlumberger, and Gilbarco). The reasoning was that by using a universal, write once, run anywhere solution we would save ourselves time and money and abstract ourselves from the chore of having to learn the workings of each of the models of every manufacturer.

Sorta like trying to discover the Northwest Passage of universal market coverage.

Does this ring a bell? ** cough ** java ** cough ** mobile flash ** cough ** flex **.

Anyway, the “universal” solution never worked 100% of the time, and it didn’t really save us any money because when it broke we ultimate spent our spare time in front of a serial data stream datascope seeing what the pumps were really sending back to our software.

In the end, we discovered that in order to deliver the best product we could, we had to be experts in every device we purported to support.

And eventually, rather than writing a single universal controller we wound up writing three or four manufacturer specific controllers.

Eventually, we DID become experts in practically any type of gasoline pump being used, though we thought we could bypass that step and still have a great product.

We were wrong. You gotta pay your dues.

It was scary for a time that I could practically name – on sight – the make and model of any gas pump at any gas station I passed for many years, even after the company I worked for folded. Not to mention being able to read, by sight, real-time stream data between pumps and controller.

And you thought YOUR life sucked.

Long story longer, in order to provide the best user experience / product possible, in any given market, there is no commercially kick-ass development shortcut to 100% market penetration AND still have a great product that is best of breed.

You gotta pay you dues, and understand, completely, your target audience and market.

There is no universal, wonder bread solution that is going to allow you to write your world beating chinese checkers app in Flash, one time, and have it take every handset by storm.  There’s no miracle cross-compiler that is going to allow you to meta program your way into cross platform compatibility Nirvana.

You want to write a killer iPhone app? You have to do it in Objective-C and stop cry-babying about Apple not letting you do it in Flash. Want to write your app once in Java and then nominally translate minor differences between Android and Blackberry? It will never happen in your lifetime.

Immerse yourself in the Android SDK, and write a killer Android App. Devote yourself to knowing everything about RIM and the Blackberry SDK of choice – Java or Widget – and wow the world.

But stop looking for the Northwest Passage. It doesn’t exist.