5 ms·

Always about the end user? Like when Apple said that all Apps needed to be originally written in their crappy language, and that you could not cross-compile to

Always about the end user? Like when Apple said that all Apps needed to be originally written in their crappy language, and that you could not cross-compile to it? That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly.

dave809 13y ago
I'm pretty sure the restriction to objective-c was due to performance concerns.
- alxeder 13y ago
  why? if the app performes badly they can just reject it, regardless of the programming language
- interpol_p 13y ago
  I believe it was also due to wanting developers to make use of the latest OS frameworks. Third party development frameworks often lagged behind in features (i.e, doesn't support new auto rotation features, doesn't support new camera features, and so on). The policy was changed and ultimately never enforced, but I always viewed it as a way to ensure that developers kept up-to-date.
  - fpgeek 13y ago
    It think the timing (days before the Adobe Flash CS5 launch, the first release that included iPhone application support, IIRC) and the eventual reversal makes it clear that this was about making life difficult for Adobe and Flash and not much else.
    - interpol_p 13y ago
      Good point. And after having a client deliver us an Adobe Air app to "fix", I am so glad it didn't become a popular way to develop iOS apps.
interpol_p 13y ago
Apple said that, but never enforced it. So that piece of policy was more a fallback (i.e., "something we can point at if an app happens to do something we didn't anticipate"). And it was eventually removed (hence my comment about Apple lessening some of their control over time). Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface. By the way, when that policy was put in place Apple had no "monopoly" to "enforce". So it simply makes no sense for you to say that. It had everything to do with maintaining control over their platform. Cross-compilation was not encouraged because it almost always means that the frameworks which cross compile maintain feature parity with older versions of the platform SDK. It means that end users don't see apps taking advantage of new features and frameworks. Look at where Apple is now and tell me that was a bad decision — developers scramble to update their apps to incorporate the newest OS features, this leads to huge competition in design and polish amongst the best apps on the App Store. Ultimately the decision benefited customers and developers. The policy was overturned largely because games became unexpectedly popular. And games don't need to use the latest OS features to deliver a quality experience. The rising popularity of Unity 3D also drove the decision. (You will recall that when the policy was publicised, there were hundreds of Unity developed games on the App Store. None were pulled and the policy was instead changed.)
- chinpokomon 13y ago
  Looking where Apple is now, that decision helped them, but I don't think you are making a case that it helped consumers. There are countless ways that Apple stifled competition when 3rd party applications compete directly with the applications Apple ships OOTB. The unified in-app purchase has benefits, but it also comes with strings attached. The 30% rake means that either users pay for the markup or developers must eat that overhead. By locking application developers out of rolling their own in-house solutions, consumers suffer. That decision may benefit consumers by presenting a unified interface, but it has everything to do with making Apple more money. If Apple really had it's users in mind, they could have simply created an API that provides the unified interface but allows developers to hook in their own back end processing. Better yet, allow in-app purchases that don't have the 30% markup. This will never happen because at the end of the day Apple is looking out for themselves, not the users of their devices.
coldtea 13y ago
>That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly. That word, monopoly. I don't think it means what you think it means. What they were trying to enforce was a common programming language for all apps that they could improve in tandem with the OS, so they wouldn't be held hostage in the future to be backwards compatible to some popular runtime (like Flash once threatened to be for the Web). P.S And "crappy language", really? As far as pragmatic languages lean on resources for native coding go, Objective-C is up there with the best of them. Not to mention the breadth and the maturity of the Cocoa libs.
- Touche 13y ago
  Objective C is so good that no one ever chooses to use it outside of Apple world.
  - austinz 13y ago
    Right, because the popularity of a programming language is always directly correlated to the quality of its design, and because when people choose languages to build a project in they only ever take technical considerations into account.
  - comex 13y ago
    This is the same as criticizing C# because nobody uses it outside of Microsoft world - or Java on mobile because nobody uses it outside of Android.
    - krisgenre 13y ago
      err.. I think there are lot of mono software written in c# that runs on Ubuntu .. and Java not used outside of Android? ROFL
      - coldtea 13y ago
        >I think there are lot of mono software written in c# that runs on Ubuntu Not as much as you think. Mono is a niche product too. >and Java not used outside of Android? ROFL He said "Java on mobile". Perhaps try to understand what you read before rolling on the floor? Java mobile (or "end user" apps in general) are Android, some crapplets, and that is mainly. If it weren't for development tools for Java devs (Eclipse, NetBeans, etc) and some internal enterprise monstrocities people are forced to use, there wouldn't be any Java desktop adoption either.

dave809 13y ago

I'm pretty sure the restriction to objective-c was due to performance concerns.

alxeder 13y ago
why? if the app performes badly they can just reject it, regardless of the programming language
interpol_p 13y ago
I believe it was also due to wanting developers to make use of the latest OS frameworks. Third party development frameworks often lagged behind in features (i.e, doesn't support new auto rotation features, doesn't support new camera features, and so on). The policy was changed and ultimately never enforced, but I always viewed it as a way to ensure that developers kept up-to-date.
- fpgeek 13y ago
  It think the timing (days before the Adobe Flash CS5 launch, the first release that included iPhone application support, IIRC) and the eventual reversal makes it clear that this was about making life difficult for Adobe and Flash and not much else.
  - interpol_p 13y ago
    Good point. And after having a client deliver us an Adobe Air app to "fix", I am so glad it didn't become a popular way to develop iOS apps.

interpol_p 13y ago

Apple said that, but never enforced it. So that piece of policy was more a fallback (i.e., "something we can point at if an app happens to do something we didn't anticipate"). And it was eventually removed (hence my comment about Apple lessening some of their control over time). Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface. By the way, when that policy was put in place Apple had no "monopoly" to "enforce". So it simply makes no sense for you to say that. It had everything to do with maintaining control over their platform. Cross-compilation was not encouraged because it almost always means that the frameworks which cross compile maintain feature parity with older versions of the platform SDK. It means that end users don't see apps taking advantage of new features and frameworks. Look at where Apple is now and tell me that was a bad decision — developers scramble to update their apps to incorporate the newest OS features, this leads to huge competition in design and polish amongst the best apps on the App Store. Ultimately the decision benefited customers and developers. The policy was overturned largely because games became unexpectedly popular. And games don't need to use the latest OS features to deliver a quality experience. The rising popularity of Unity 3D also drove the decision. (You will recall that when the policy was publicised, there were hundreds of Unity developed games on the App Store. None were pulled and the policy was instead changed.)

chinpokomon 13y ago
Looking where Apple is now, that decision helped them, but I don't think you are making a case that it helped consumers. There are countless ways that Apple stifled competition when 3rd party applications compete directly with the applications Apple ships OOTB. The unified in-app purchase has benefits, but it also comes with strings attached. The 30% rake means that either users pay for the markup or developers must eat that overhead. By locking application developers out of rolling their own in-house solutions, consumers suffer. That decision may benefit consumers by presenting a unified interface, but it has everything to do with making Apple more money. If Apple really had it's users in mind, they could have simply created an API that provides the unified interface but allows developers to hook in their own back end processing. Better yet, allow in-app purchases that don't have the 30% markup. This will never happen because at the end of the day Apple is looking out for themselves, not the users of their devices.

coldtea 13y ago

>That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly. That word, monopoly. I don't think it means what you think it means. What they were trying to enforce was a common programming language for all apps that they could improve in tandem with the OS, so they wouldn't be held hostage in the future to be backwards compatible to some popular runtime (like Flash once threatened to be for the Web). P.S And "crappy language", really? As far as pragmatic languages lean on resources for native coding go, Objective-C is up there with the best of them. Not to mention the breadth and the maturity of the Cocoa libs.

Touche 13y ago
Objective C is so good that no one ever chooses to use it outside of Apple world.
- austinz 13y ago
  Right, because the popularity of a programming language is always directly correlated to the quality of its design, and because when people choose languages to build a project in they only ever take technical considerations into account.
- comex 13y ago
  This is the same as criticizing C# because nobody uses it outside of Microsoft world - or Java on mobile because nobody uses it outside of Android.
  - krisgenre 13y ago
    err.. I think there are lot of mono software written in c# that runs on Ubuntu .. and Java not used outside of Android? ROFL
    - coldtea 13y ago
      >I think there are lot of mono software written in c# that runs on Ubuntu Not as much as you think. Mono is a niche product too. >and Java not used outside of Android? ROFL He said "Java on mobile". Perhaps try to understand what you read before rolling on the floor? Java mobile (or "end user" apps in general) are Android, some crapplets, and that is mainly. If it weren't for development tools for Java devs (Eclipse, NetBeans, etc) and some internal enterprise monstrocities people are forced to use, there wouldn't be any Java desktop adoption either.