Slashdot Mirror


Steve Jobs Weighs In On iPhone Programming Language Mandate

Dotnaught writes "Greg Slepak, founder of software company Tao Effect, wrote Apple CEO Steve Jobs to complain about Apple's mandate that iPhone applications be originally written in C/C++/Objective-C. Job's response was to endorse a post by John Gruber on the Daring Fireball blog. Jobs called it 'very insightful,' suggesting Gruber's prediction that third-party iPhone development tools are out might be right. Jobs sent a second reply that also doesn't bode well for third-party iPhone development tools: 'We've been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.'"

27 of 711 comments (clear)

  1. They want devs to choose by bcmm · · Score: 5, Insightful

    By restricting the use of abstraction layers, they want to make devs choose between writing their app for the iPhone or for Android, it would seem (or, of course, writing it twice).

    Of course, the real choice is "write for iPhone, or write for every other platform". I hope developers are bright enough to see where this is going.

    --
    # cat /dev/mem | strings | grep -i llama
    Damn, my RAM is full of llamas.
    1. Re:They want devs to choose by cfulmer · · Score: 5, Insightful

      It seems to me that this is anti-competitive. They're using the iPhone's market dominance to increase the costs of producing applications on other platforms. And, that's likely to raise an antitrust lawsuit. If Apple is so concerned about quality of software being produced, they already have a mechanism to deal with it -- the app store review process.

    2. Re:They want devs to choose by Goaway · · Score: 5, Insightful

      (or, of course, writing it twice)

      This is the one. He wants apps written for the iPhone, not apps that try to shoehorn some kind of cross-platform abstraction on top of the iPhone, because that usually sucks, and (at least in his eyes) it makes the iPhone look bad if the apps look bad.

      How many times do you hear gamers complain that a game is a crappy port because it is not properly written for the platform it is on, but instead tries squeeze in the functionality of some other platform? That is the exact thing he doesn't want on his platform.

    3. Re:They want devs to choose by Cryacin · · Score: 5, Funny

      they already have a mechanism to deal with it -- the app store review process.

      Magic 8 balls need a holiday every now and again too you know.

      --
      Science advances one funeral at a time- Max Planck
    4. Re:They want devs to choose by cbreak · · Score: 5, Insightful

      How's that anti-competitive? I have to buy a Windows PC to develop for the XBox too... It's just common sense that you have to have the platform your tools run on to use the tools.

    5. Re:They want devs to choose by digitalchinky · · Score: 5, Informative

      I'm guessing you are American, the IPhone is a tiny player in the rest of the world - a world that is dominated by Nokia, SE, LG, and Samsung for the most part, though there are many other manufacturers. In Asia the Chinese knock offs are extremely popular.

      Now that said, if you were to venture away from the self delusional 'free phone mentality' and just bought something outright, you would find even in America, a vast array of hardware to choose from. Hardware without all the draconian operator restrictions programmed in.

    6. Re:They want devs to choose by Nerdfest · · Score: 5, Insightful

      How about this ... they have an approval process, so use that to disallow sub-standard applications regardless of the language that they're written in.

    7. Re:They want devs to choose by LordVader717 · · Score: 5, Informative

      They don't have to be a monopoly to break the law.

    8. Re:They want devs to choose by TheRaven64 · · Score: 5, Interesting

      Not sure about Google, but we (GNUstep) have a project to implement UIKit. We already have pretty much all of the Foundation framework that the iPhone exposes, and our CoreGraphics implementation will hopefully to be finished as a result of this year's GSoC. A lot of UIKit is very similar to stuff we've already implemented for AppKit, so there's a lot of potential for code reuse. We've approached Nokia for funding the development of UIKit, with the N900 as a primary target, but if anyone at Google (or anywhere else) is interested in funding some of the work then please let me know.

      --
      I am TheRaven on Soylent News
    9. Re:They want devs to choose by boilednut · · Score: 5, Insightful

      He wants apps written for the iPhone, not apps that try to shoehorn some kind of cross-platform abstraction on top of the iPhone, because that usually sucks, and (at least in his eyes) it makes the iPhone look bad if the apps look bad.

      This is a patently ridiculous generalization. Adobe Flash CS5 is a translator with associated API libraries -- similar in kind to a C compiler and the C standard library. So, an analogous argument would be that all code built with GCC sucks; and, therefore, only assembly can be used.

      I wish I could view with indifference all of the people that drink the Apple Kool-Aid; but, I fear that little choice and freedom will remain in the wake of a tide of lemmings rushing off Apple's cliff of corporate lock-in.

    10. Re:They want devs to choose by dakameleon · · Score: 5, Insightful

      But what about apps that don't fully use iPhone's features because it is catering for the lowest common denominator across multiple platforms?

      What?! Don't "fully use" the iPhone's features?! What on earth are you on about? Does iFart "fully use iPhone's features"?

      So what if an app doesn't "fully use iPhone features", as long as it provides adequate functionality? Consistency across devices is also laudable for the ease of transition from one platform to another. But that assumption works only in a world where competition drives innovation rather than hostility.

      It is perfectly reasonable to want fewer high-quality apps on the platform, rather than wishing for more crap apps. This just aligns with the usual Apple approach.

      Who are you to determine what is "quality"? Or for that matter, who is Apple to determine what its users will be happy with? There's plenty of junk on the App Store already, so it's not like they're making value judgements on the functionality of the apps, but are far more interested in ensuring they control the end to end process. Too much control can choke off a platform, too.

      (disclaimer: current iPhone user, increasingly disillusioned)

      --
      Man who leaps off cliff jumps to conclusion.
    11. Re:They want devs to choose by nametaken · · Score: 5, Informative

      I can write apps for android on ANY platform.

  2. Re:Old trick by Anonymous Coward · · Score: 5, Informative

    Compile to C is banned. The policy is not a technical requirement, it's a contract. You can't get access to the Apple App Store without agreeing not to use intermediate layers. If your code is created in something other than Objective C, C or C++, you're in violation of that agreement, even if at some point all of it is represented in C code. Steve Jobs is a benevolent dictator and he has just extended his reach into your toolkit. (Captcha: soviet, how fitting)

  3. Re:None of this would've happened... by je+ne+sais+quoi · · Score: 5, Insightful
    well that's the crux of what Gruber sees as the benefit of Apple's policy for iphone users:

    iPhone users: I can see two arguments here. On the one side, this rule should be good for quality. Cross-platform software toolkits have never -- ever -- produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy. On the other hand, perhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won't now. I don't think iPhone OS users are going to miss the sort of apps these cross-platform toolkits produce, though.

    Speaking as someone who has to deal with 64 bit flash on linux and has had to deal with all manner of MS enforced formats on the the mac, I completely and utterly agree with this part. Apps running using native platform tools do fairly well, cross-platform apps suck a lot of the time. You windows users have seen this too -- itunes, quicktime and safari are dogs on windows because they had to import all their own libraries. On Apple machines these are lighweight apps that are fast. On windows it just doesn't work as well. And let's face it, as nice as open software is, working well is what sells units, ideology is secondary.

    --
    Gentlemen! You can't fight in here, this is the war room!
  4. Substandard apps? by shadowrat · · Score: 5, Insightful

    intermediate layers between the platform and the developer ultimately produces sub-standard apps

    Right. That's why all those games built with engines and level editors and scripting tools always suck. C'mon apple. You have to allow unity. You can't want games but require everyone to make them from scratch.

    Afraid that cool unity game will show up on pc, wii, xbox, android, Mac, myspace? It'll be just like the 90's when the pc was gaming heaven and mac users got to play marathon for 11 years.

  5. Additional layers have nothing to do with this by gaspyy · · Score: 5, Insightful

    Keep in mind that actual Flash apps written by CS5 beta testers have been approved in Apple's app store in the past as well as many games written with Unity3D, so it's not like performance is a problem.

    Since every app is checked against objective (and subjective) criterias, it would have been OK to just reject poorly written applications.

    Forcing me to use a specific programming language is insane. Imagine Microsoft demanding all windows apps to be written only in C# and compiled only with Visual Studio. It would be an outrage. But hey, it's Steve Jobs, the Big Brother himself, and he knows what's best for us, right?

    Also, the timing was devious - on Friday, just before the Monday's official release of Adobe's CS5, effectively giving them no time to react. I was never a big fan of Adobe (especially before the Macromedia acquisition - their corporate culture started to change afterwards) but this is simply Steve Jobs being a big dick.

    Finally, I know that many /.-ers are against Flash. Keep in mind however that this move goes well beyond Flash, affecting other tools and frameworks. If successful, this move will lead to more and more closed ecosystems (from other vendors as well). Today's Apple makes Microsoft look like saints.

    1. Re:Additional layers have nothing to do with this by Anonymous Coward · · Score: 5, Informative

      Forcing me to use a specific programming language is insane. Imagine Microsoft demanding all windows apps to be written only in C# and compiled only with Visual Studio. It would be an outrage. But hey, it's Steve Jobs, the Big Brother himself, and he knows what's best for us, right?

      Is this asinine? You are aware Microsoft is demanding all Windows Phone 7 apps be written in C#/Silverlight, right? I may not agree with their move, but to say it puts them alone on a pillar of evil seems to show your own bias more than any factual opinion.

      You are confusing platform with development tools. Apple is banning cross-platform development tools, even if they produce valid code for the platform. Microsoft is doing no such thing. If you have a development tool able of producing both Flash, Silverlight and iPhoneOS versions of your app. Microsoft will accept it, Apple will not.

  6. Blink on this issue? by Yvan256 · · Score: 5, Funny

    Don't Blink. Blink and you're dead. Don't turn your back. Don't look away. And don't Blink. Good Luck.

  7. Intermediate Layers by Grax · · Score: 5, Funny

    I don't understand why they keep sticking those damn intermediate layers in there. Real programmers write write in assembly language. If you want real performance that is what you need to be doing instead of using foofy object-oriented programming tools and junk like that. In my experience those other things just add more bugs and no real value. If you want information an old-fashioned text-only display can provide it. Remove all the layers please.

  8. Re:None of this would've happened... by Mr.+Spontaneous · · Score: 5, Informative

    But let's talk more about the Flash Player on the Mac. If it is not 100% on par with the Windows player people assume that it is all our fault. The facts show that this is simply not the case. Let's take for example the question of hardware acceleration for H.264 video that we released with Flash Player 10.1. Here you can see some published results for how much the situation has improved on Windows. Unfortunately we could not add this acceleration to the Mac player because Apple does not provide a public API to make this happen. You can easily verify that by asking Apple. I'm happy to say that we still made some improvements for the Mac player when it comes to video playback, but we simply could not implement the hardware acceleration. This is but one example of stumbling blocks we face when it comes to Apple.

    From http://theflashblog.com/?p=1641

    --
    Its all fun and games until someone loses an eye... then its just fun.
  9. iTunes for Windows is using non-native APIs by dotwhynot · · Score: 5, Interesting

    We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.” -- Apple

    Is Apple actually calling iTunes for Windows for a sub-standard app? That perhaps should be banned from the platform? Apple themselves are using non-native API intermediate layers such as CoreFoundation and CoreGraphics in their implementation of iTunes for Windows.

    1. Re:iTunes for Windows is using non-native APIs by khchung · · Score: 5, Insightful

      Is Apple actually calling iTunes for Windows for a sub-standard app? That perhaps should be banned from the platform? Apple themselves are using non-native API intermediate layers such as CoreFoundation and CoreGraphics in their implementation of iTunes for Windows.

      Yes, iTunes for Windows is a sub-standard app... for the Windows platform.

      Compared to other Windows apps (which are already not great feats of engineering), the iTunes app really sucks in many areas - slow startup, unresponsive UI whenever it is busy, non-standard UI elements, etc.

      Jobs understand very well these downsides are exactly what you get for putting an intermediate layer to help support multi-platforms - the apps will suck except possibly for the primary platform (if any) of the intermediate layer. And Apple doesn't want such apps on the iPhone, they would rather have the app not available than have a sucky one. You know, some might consider this quality control.

      As for banning, well, the platform is Windows, perhaps you should ask Microsoft if they care about sucky apps on their platform?

      --
      Oliver.
  10. Re:None of this would've happened... by TheRaven64 · · Score: 5, Insightful

    Except that Apple ships a highly optimised H.264 CODEC as part of OS X. If they used that, instead of shipping their own, then it would be much faster. If you grab an H.264 movie and play it in QuickTime on a Mac, the CPU load is under half that of playing it in Flash. It's not that Apple doesn't provide APIs for doing it, it's that Apple doesn't provide APIs for doing it the way Adobe wants to do it, which is an entirely different complaint.

    --
    I am TheRaven on Soylent News
  11. Re:why might apple be doing this by salesgeek · · Score: 5, Insightful

    Basically, hogwash. Having one language and one tool chain leads to fewer methods of being able to solve problems, and reduces the utility of your computer system. Now instead of being able to use a .5mm slot head screwdriver, all I have a big ol' sledge hammer. There really is no "computer science" basis for Apple's decision. There is a marketing reason or two, though:

    1. Eliminate cross platform development tools and lock in developers and users to your platform.
    2. Ensure you can always put out better stuff than independent software vendors by pulling a Microsoft and adding new (undocumented or unreleased) libraries to the OS and then using the libraries to produce more functional, better integrated software than ISVs can.
    3. It's easy to kill off competition or those doing things you don't like with the platform by introducing incompatibilities in system libraries.

    The rest of your post, while interesting is basically speculating that Apple will create some whiz-bang complier that will solve all of the remaining big problems in computer science. I wish Apple luck, and I hope they solve at least two or three of the big challenges.

    A note on languages: Objective-C does not make for instant parallelism as you still have to fix the giant game of whack-a-mole that goes on with shared memory and have a more effective way of communication between processes/threads/whatever you want to call 'em. Providing some metadata might help, but it's no magic bullet.

    --
    -- $G
  12. Irrelevant. by SanityInAnarchy · · Score: 5, Insightful

    Does a single thing you said explain why they won't allow frameworks which compile to Objective-C?

    That's where I'm having trouble. I can see a technical reason to force people to use a single language, or at least a single runtime representation, in the same way that, say, the new Windows Mobile forces you to use .NET. I don't see any technical reason for them to care what language you originally use to produce it.

    --
    Don't thank God, thank a doctor!
  13. Re:why might apple be doing this by mog007 · · Score: 5, Insightful

    Having one language, so long as it's turing-complete, shouldn't give you fewer methods to solve a problem. Now, if you're locked into a single language it would probably make it difficult to find a pre-existing library that might assist you.

    I agree that there's no computer science basis for Apple's decision, but then again, Apple doesn't make their decisions based on computer science, they base them on business.

  14. Rationalisation by Dogtanian · · Score: 5, Insightful

    Now what might be the resource use case improvement here? I'll start the speculation with this thought and leave it to others to fill in more.

    No offence, but this does smack being the thin end of a typical wedge of rationalisation that ends up justifying and "explaining" Apple's behaviour in the absense of any explanation from them.

    While I'm not accusing you (specifically) of being a fanboy necessarily, Apple's secretive nature generally benefits them when combined with their rather partisan fanbase. Say nothing concrete that can be seized upon, and let people speculate, rationalise and justify your marketing decisions.

    It's up to Apple to explain- or not- the reasoning behind what they do; if the latter, that's their choice, but we're not obliged to give them the benefit of the doubt. Sorry, but I don't believe the reasons behind the decision were technical, and I'm not going to buy a third-party's speculation masquerading as explanation.

    --
    "Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).