I'm starting to dread Steve Jobs' keynote speeches, because they more or less guarantee a new iProduct. To which I'm mostly indifferent, except that this inevitably (and immediately) precipitates another food-fight between the platform/language fanboys & fangirls. Case in point: Should my gentle reader feel that her/his opinion of the human race is running too high of late, Tim O'Reilly (@timoreilly) helpfully supplies the following two links. (Hint: Read comments for full effect.)
- iPhone 4 Is Nice, But It's Not Enough to Slow Android
- Words Apple Won't Hear (Right Now) - Code for Android First
Perhaps it's just that I don't have enough fortitude to follow such...ahem...dialectics...in their entirety, but I have yet to see one factor addressed. That factor is style, by which I mean the ethos of the programmer and/or code-shop itself.
A bit of background for my readers working outside the software trade: The two styles I'm talking about are loosely defined as "waterfall method" and "agile." Using broad-brush sketches, "waterfall" attempts an assembly-line process of design, build, test, and release. Agile, by contrast, iterates through these steps multiple times--as quickly as possible--until customers are satisfied with the final version. There's merits to both methologies, of course. Using the agile mind-set for the software that runs nuclear power plants is a Very Bad Idea for obvious reasons. Similarly, insisting on waterfall methods in a bleeding-edge web start-up is the short road to insolvency.
In the context of smartphone applications, I think that the difference is fairly obvious. Apple prides itself on--and enforces--polish and fit; Android's application market has gained a reputation--unfairly or not--of trading finesse for freedom. In other words, releasing a minimum viable iProduct will likely defeat the purpose; over-thinking an Android application will seriously--perhaps fatally--impact its time-to-market.
That's not to say that an iPhone/iPad software shack can't run on agile principles, nor even that Android applications can't be born of the waterfall school of development. But, overall, my best guess is that the platform will to some extent work with or against the process. That's not a consideration to be taken lightly. Changing the modus operendi for a one-person code-shop is a big deal. (In a nutshell, you're turning vices into virtues and vice-versa.) When additional people are involved, my gut-level math is that you don't multiply the difficulty by the number of people; you take the difficulty to the power of the number of people involved.
So, as tempting as the jump into a new market seems, the ultimate "price" isn't necessarily a matter of training, new development environments, and some language manuals. You just might have to decide whether the changes wreaked upon style are also worth the benefits.
