Hacker News Reader

Comment by eru | Hacker News Reader

Sure. But it seems silly from Apple to restrict all iPhone developers to a (very) short whitelist of languages.

Howso? They've spent the money and the time to create a great platform. It seems well within their rights to dictate a lot of the rules around what goes on the platform they created.

And as mentioned above, they dont have a monopoly in the market so, from Apple's perspective, 'if you don't like it, there are other opportunities' ... developing for the bberry :)

Oh, I never questioned their right to do so. My comment was meant literally: They look silly to me.

It doesn't look silly when taken in context with the rest of their strategy of controlling the entire toolchain to maintain consistency across apps. That strategy becomes harder when everyone goes off and uses different tools.

It's the same strategy that they've always used with their software/hardware combination, which has worked beautifully in the case of the mac.

Oh, I also don't want to question that it may be a good strategy.

"Apple responsible for 99.4% of mobile app sales in 2009"

http://arstechnica.com/apple/news/2010/01/apple-responsible-....

check the numbers - AppStore IS a monopole ...

Great platform it may be, but this rule is insane. Who cares how the compiled code was produced? What matters is how it runs on the platform.

OK. I come from a different background of programming than traditional consumer apps. In my "normal" job, I get a very small white list of programming languages. "C", "C++" (but no templates, multiple inheritance, no operator over-loading), "ADA", Assembly. Within each of these areas I am not allowed specific features. Recursion. OMG. I did that once and never again. Big nono. Even a simple things like:

   if (A && B)
   {
   }
   else if (A && !B)
   {
   }

is not legal as you can not fully test 1 of the four branches in the "else if()" case. Even "default" statements in "case" statements that can not be executed (because the switch statements cover 100% of the available options) can be an issue.

What I am getting at is, with programming there are rules. The rules Apple have are actually very minor and very easy to stay within. If you program to make political statements, choose Android or BB or Symbian. If you program to make money, pick the platform that will do that and follow the rules. If it stops making you money, move on. If you don't like the rules and don't want to abide by them, move on.

You can enjoy programming while still staying within the rules. Sometimes, it is part of the fun and challenge.

Programming isn't a game for many people, it's a profession. The time you spend on learning their platform and languages are sunk costs, and you need to recoup them through money-making products. By restricting developers to their APIs and languages, they are trying to lock in developers and users.

Apple is trying to accomplish the same kind of lock-in that Microsoft managed with Windows. And we better nip this thing in the bud, because Apple would screw us even worse than Microsoft has.

Learning another language is an overhead, an investment you make that increses your skills and broadens your abilities. If you want to write applications for iPhone OS and take advantage of the huge market that Apple has created, then learning Objective-C and Apple's IDE is an investment in time that you need to make. It's just what you need to do. Many developers from other backgrounds have already started programming for iPhone OS and met with great success. If you're experienced in object oriented program design, or C++, then the transition isn't that difficult.

As a long time Mac user, I've experienced a lot of Mac applications that have been straight ports from other platforms and they are, for the most part, pretty awful. I can understand from this why Apple wants its developers to code iApps natively.

This 'lock in' makes perfect sense for Apple in other ways too, ways in which end users and developers will benefit. Imagine that Apple allow apps to be ported from Flash. Developers would stop coding natively for iPhone OS as they would be able to create their apps in Flash and distribute them as web apps at the same time, reaching a greater audience. Then add in Android, Blackberry & other export options for Flash. Soon enough Flash would be the only IDE in use and platforms such as iPhone OS would be at the mercy of Adobe. If Apple were to introduce new features and efficiencies to their hardware and APIs, they would have to wait for Adobe to implement them in its Flash translation layer before the features would really become available to end users. Even the most willing and motivated of developers would not be able to get around that, they would have to wait for Adobe. So in the end, Apple would lose sales and credibility, and good developers would get screwed because they wouldn't be able to out pace their competitors in updating their apps to take advantage of new features. Everyone becomes 'locked in' to Adobe. Given Adobe's poor history when it comes to timely bug fixes and support of its OS X applications, I do not think that this 'lock in' would be a nice place to find yourself, whether you're Apple, a developer or an end user.

If you don't like Apple's stance then develop for other platforms and buy other products. But if you want to be in on the action, then accept the rules as they are not unreasonable and will ultimately benefit everyone.

> Within each of these areas I am not allowed specific features. Recursion. OMG. I did that once and never again. Big nono.

We tend to frown on loops and mutating variables.

"They've spent the money and the time to create a great platform."

They've spent some money and time, and they have taken a lot of other people's work: Mach, gcc, Smalltalk, BSD, etc.

"they dont have a monopoly in the market"

That's not so clear to me. I own an iPhone and an iPad even though I think they really suck technically. But there is content available for them that simply is not available for other platforms.

Reply on news.ycombinator.com