I'd disagree with the author. iPhone won't see very many large, high-risk applications developed as a result of Apple's approach. Apple screws over developers and partners too often. You will build a $1 application in a few man-months for iPhone, no questions.<p>Build a Google Voice? Build a Flash->iPhone compiler? You might get screwed and lose a really big wad of cash.<p>When business types decide what to build, they multiply out risks. You have technical risk (developers can't build it), market risk (people won't buy it), and a bunch of others. Typically, they're individually low-risk (say, 80% chance of success), but when you multiply them together, you get pretty low numbers.<p>If you toss in the additional risk of "Apple will cut me off if I'm successful and they want to compete with me" and "Apple will cut me off if they don't like me," it makes it a much less compelling platform.<p>The costs also go up if you can't share codebase. Requiring iPhone SDK is sort of sane -- you make an iPhone-specific front-end, and it looks better. Requiring Objective C or one of their other languages is kinda wacko -- you can't even share back-end logic. If I just spent millions on something complex (image processing engine, voice recognition system, or whatever), I don't want to spend another big portion of that for an iPhone port.<p>Worse, the same applies to custom business software, but even more so. If I have an enterprise app employees must use (think UPS guy or bus driver or anything like that), I care a lot about development time, not much about usability, and I can dictate platforms. If I can recompile to Android but rewrite for iPhone, guess what I'm gonna do?