3 ms·

My takeaway? Using Xcode and Objective-C are not surefire ways to build decent iPhone apps, and using "meta-platforms" and other languages are not surefire way

My takeaway? Using Xcode and Objective-C are not surefire ways to build decent iPhone apps, and using "meta-platforms" and other languages are not surefire ways to build crappy, non-Apple-like iPhone apps. Are they indicators about how much passion someone has for the iPhone platform and building quality iPhone user experiences? In my experience the answer is yes. I think we've already demonstrated here that this is patently false. There's plenty of "shit" in the App store that's written in Objective-C, C and C++. What Jobs should have done then was not ban apps by language, but ban "shitty" apps. The rational for this move is well understood, it's a strategic business decision designed to force developers from writing cross platform apps. Like it or not, the Android store is growing in size. But it lacks quality apps, if a developer can write for both stores at basically no additional cost, then they can offer apps on the Android as well. Eventually, if enough developers do that, it'll be a real competitor to the iPhone. Jobs simply wants to prevent that.

rbanffy 17y ago
> if a developer can write for both stores at basically no additional cost, then they can offer apps on the Android as well The simple, obvious, solution is to build an iPhone to Android translation layer. Replicate the APIs that exist on the Apple side and/or compile Obj-C to Java or Java bytecode flagging whatever does not exist on either side, making it easy to write code that is compatible with both platforms while maximizing shared code between both implementations.
- DrJokepu 17y ago
  (Obligatory nerdy nitpicking) Of course, Android doesn't execute Java bytecode. It runs Dalvik bytecode.
  - rbanffy 17y ago
    OK. You win. Dalvik bytecode it is, whatever the difference ;-)
- wvenable 17y ago
  Apple still wins because their platform is the first class platform.
  - rbanffy 17y ago
    Not at all. It cannot impose interface changes that break old code and cannot force developers that develop for both platforms to use the newest interfaces that are not supported on the other side. They have to continuously bloat the platform in order to keep it a moving target. Apple is playing an impossible hand. Android doesn't need to defend ground to win. Making Apple lose ground suffices for them - Google thrives on fragmentation. Besides that, Android could be made as language-agnostic as Google wants it to be. I see no reason to prevent keeping the core logic in Obj-C and Android-specific elements in Java. The semantics are very similar. I would love to see not only this, but also a Wine-like compatibility layer for OSX developers to deploy their apps on other environments. Some parts of it are production-ready in the form of GNUStep.
csmeder 17y ago
This argument is flawed. Given that there are already bad apps in the app store doesn't mean restricting the language of use to C based languages is a bad way of minimizing the number of future bad apps. I am not saying I have proved the oposite: "That restricting the language will improve the quality of the new stream of apps submitted." I am simply saying the above argument is flawed. I believe the author of the this article is correct. If you allow people to use flash, .net and other methods the quality of apps submitted will be largely lower in quality. How do I feel about this strategy? Thats a different story. If I was Steve Jobs, I don't know if I would do it, I am still undecided. On one hand I feel this lights a fire underneath developers to compete with the iPhone using Android. Competition is good for everyone in the long run. On the other hand I want to be able to use Lisp on the iPhone and I want apple to encourage "think different"...
- wvenable 17y ago
  > If you allow people to use flash, .net and other methods the quality of apps submitted will be largely lower in quality. There was a statistic posted early that 10 of top 100 applications in the store were written in .NET (MonoTouch). If that's true, a significant number of users are extremely satisfied with these products. The fact is, your assuming that apps written in Flash or .NET are automatically lower in quality -- that it's a given from the start. You haven't proved that assumption. (Now, I'll accept that for Flash it's probably would have been true -- but we were never even given the chance to know for sure).
- elblanco 17y ago
  You would have to demonstrate that C* apps are qualitatively better than non-C apps (or apps that use some other language for runtime scripting like Lua). I don't think that has been done yet.
Lazlo_Nibble 17y ago
> What Jobs should have done then was not ban apps by language, but ban "shitty" apps. Whatever you think of the app store rules, you can't seriously be suggesting that a rule as subjective as "don't be shitty" would make life for developers any easier.
- elblanco 17y ago
  No, not at all. I think the point I'm trying to make is that what lots of people are thinking is that the rule change was to prevent apps of low quality in the store while what Apple was probably actually thinking with the rule was "let's make it hard to put apps on competing platforms". In other words, the argument that it to improve the app quality is a red herring -- it has nothing to do with that. And as you rightly pointed out, the new rule is not even a sane proxy for a policy of "no shitty apps" (which is even more absurd). The only rational business reason is to raise the level of effort of cross platform development such that it's not worth it to spend the same effort to write an Android app with that platform's much smaller user base and lower average cost of purchase.

rbanffy 17y ago

> if a developer can write for both stores at basically no additional cost, then they can offer apps on the Android as well The simple, obvious, solution is to build an iPhone to Android translation layer. Replicate the APIs that exist on the Apple side and/or compile Obj-C to Java or Java bytecode flagging whatever does not exist on either side, making it easy to write code that is compatible with both platforms while maximizing shared code between both implementations.

DrJokepu 17y ago
(Obligatory nerdy nitpicking) Of course, Android doesn't execute Java bytecode. It runs Dalvik bytecode.
- rbanffy 17y ago
  OK. You win. Dalvik bytecode it is, whatever the difference ;-)
wvenable 17y ago
Apple still wins because their platform is the first class platform.
- rbanffy 17y ago
  Not at all. It cannot impose interface changes that break old code and cannot force developers that develop for both platforms to use the newest interfaces that are not supported on the other side. They have to continuously bloat the platform in order to keep it a moving target. Apple is playing an impossible hand. Android doesn't need to defend ground to win. Making Apple lose ground suffices for them - Google thrives on fragmentation. Besides that, Android could be made as language-agnostic as Google wants it to be. I see no reason to prevent keeping the core logic in Obj-C and Android-specific elements in Java. The semantics are very similar. I would love to see not only this, but also a Wine-like compatibility layer for OSX developers to deploy their apps on other environments. Some parts of it are production-ready in the form of GNUStep.

csmeder 17y ago

This argument is flawed. Given that there are already bad apps in the app store doesn't mean restricting the language of use to C based languages is a bad way of minimizing the number of future bad apps. I am not saying I have proved the oposite: "That restricting the language will improve the quality of the new stream of apps submitted." I am simply saying the above argument is flawed. I believe the author of the this article is correct. If you allow people to use flash, .net and other methods the quality of apps submitted will be largely lower in quality. How do I feel about this strategy? Thats a different story. If I was Steve Jobs, I don't know if I would do it, I am still undecided. On one hand I feel this lights a fire underneath developers to compete with the iPhone using Android. Competition is good for everyone in the long run. On the other hand I want to be able to use Lisp on the iPhone and I want apple to encourage "think different"...

wvenable 17y ago
> If you allow people to use flash, .net and other methods the quality of apps submitted will be largely lower in quality. There was a statistic posted early that 10 of top 100 applications in the store were written in .NET (MonoTouch). If that's true, a significant number of users are extremely satisfied with these products. The fact is, your assuming that apps written in Flash or .NET are automatically lower in quality -- that it's a given from the start. You haven't proved that assumption. (Now, I'll accept that for Flash it's probably would have been true -- but we were never even given the chance to know for sure).
elblanco 17y ago
You would have to demonstrate that C* apps are qualitatively better than non-C apps (or apps that use some other language for runtime scripting like Lua). I don't think that has been done yet.

Lazlo_Nibble 17y ago

> What Jobs should have done then was not ban apps by language, but ban "shitty" apps. Whatever you think of the app store rules, you can't seriously be suggesting that a rule as subjective as "don't be shitty" would make life for developers any easier.

elblanco 17y ago
No, not at all. I think the point I'm trying to make is that what lots of people are thinking is that the rule change was to prevent apps of low quality in the store while what Apple was probably actually thinking with the rule was "let's make it hard to put apps on competing platforms". In other words, the argument that it to improve the app quality is a red herring -- it has nothing to do with that. And as you rightly pointed out, the new rule is not even a sane proxy for a policy of "no shitty apps" (which is even more absurd). The only rational business reason is to raise the level of effort of cross platform development such that it's not worth it to spend the same effort to write an Android app with that platform's much smaller user base and lower average cost of purchase.