Steve Jobs Weighs In On iPhone Programming Language Mandate 711
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.'"
And this is why I don't buy Apple (Score:2, Informative)
I honestly don't understand why Geeks put up with this and fall for the marketing propaganda. If all the world were Apple we'd not be able to hack a thing.
Transcompilers? (Score:3, Informative)
Re:None of this would've happened... (Score:4, Informative)
I read you post three times but I could see no facts, examples, anecdotes, anything. Just words.
Flash supports multitouch and has access to accelerometer data, GPS info and so on, so what "new features" don't fit well with the medium?
Semicomplex games not good? There are so many games in flash, some of them excellent, that isn't even funny. Quake has been ported to Flash, as well as Prince of Persia, just to name two classics, I could give many more examples.
HD Fullscreen video works great in Flash 10.1 RC
Re:Old trick (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)
What (Score:2, Informative)
intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
I find that intermediate layers such as Python tend to produce above-standard apps due to the developers (ie. me) not having to implement every little detail manually. Number of Bugs ~ k * Amount of Code, well known fact.
Comment removed (Score:5, Informative)
Re:None of this would've happened... (Score:5, Informative)
From http://theflashblog.com/?p=1641 [theflashblog.com]
Re:They want devs to choose (Score:1, Informative)
How's that anti-competitive?
It prevents competition for the sake of preventing competition. It's not just not helping a competitor, it's deliberately preventing them competing.
I have to buy a Windows PC to develop for the XBox too
No, you can write the code on any platform, and compile it on anything that supports compiling to xbox360 (As of writing this it happens that the only compiler+toolkit to do this is only available for windows, but there is nothing preventing me from reverse engineering the api's and releasing my own SDK)
It's just common sense that you have to have the platform your tools run on to use the tools.
By that logic you would need an Xbox not a windows PC, as neither the xbox nor the 360 are binary compatible with a windows PC, and while in practice you need an xbox for testing, there is nothing stopping you from writing a game for the xbox based on the SDK and hoping it works without ever seeing an xbox.
Common sense says that apple don't have to help adobe/microsoft/etc to write compilers for there platform, anti-competition laws say that if they have big enough market share they can't prevent them from doing so.
Re:Additional layers have nothing to do with this (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.
Re:They want devs to choose (Score:5, Informative)
They don't have to be a monopoly to break the law.
Re:Porting is a totally different issue. (Score:2, Informative)
Re:They want devs to choose (Score:3, Informative)
You couldn't seriously develop for the iPhone without a Mac. Assuming that you wanted to test the final output of your marvelous multi-platform compiler to make sure that it, y'know, actually worked on the platform you were targeting, you would need a Mac. As far as I know there's still no way to run iPhone Simulator, switch an iPhone to Development Mode, or create an AdHoc profile without one.
Obfuscation (Score:3, Informative)
It seems to me, this just means that Adobe et al. have to make it impossible to tell that their tools were used to create the app.
Re:They want devs to choose (Score:5, Informative)
You do have to be a monopoly in order for leveraging market share against competitors to be illegal.
What we're seeing here is Apple leveraging their App Store market in a way that reduces competition from Adobe and Google in the smart phone market. This is perfectly legal right up to the point that Apple acquires a monopoly market share in smart phones. They're nowhere near that point, so leveraging their tiny (10%?) share of the smart phone market to attempt to box out Google and Adobe is perfectly legal. This is exactly how competitors compete all the time. It is desirable that competitors differentiate themselves in these sorts of ways so that the market can make choices. (N.B. differentiation is desirable - I'm not saying that I think it's desirable that Apple do what they did - I don't.)
The choice here is this: will the market prefer a clearly more restrictive but also more selective platform, or will the market prefer a less restrictive but also less selective platform. This sort of decision can and should be made in the marketplace, not in a court of law. If anyone wants to influence this market decision, they have only to choose Android (or some other smart phone platform, Palm, Blackberry, etc.) rather than the iPhone.
Re:They want devs to choose (Score:3, Informative)
Also, it doesn't make devs choose. Someone will be working on an objective-C to Android-Java cross compiler as we speak
No such cross-compiler is necessary:
Cross compiling UI code would be fairly pointless since the two platforms don't have the same UI design.
Cross compiling app logic is unnecessary as well because even the disputed iPhoneOS 4.0 agreement allows devs to code in C and C++, and Android has a native dev kit that lets devs code in C and C++.
So just write your app logic in C/C++, your iPhone UI in objective-c (or C/C++), and your Android UI in either C, C++, or Dalvik-Java.
Re:They want devs to choose (Score:3, Informative)
It's just common sense that you have to have the platform your tools run on to use the tools.
By that logic you would need an Xbox not a windows PC
Hate to break it to you, but Visual Studio with Xbox SDK does not at all run on the xbox, it runs on Windows.
Just like xcode runs on osx and not the phone.
Re:They want devs to choose (Score:5, Informative)
I can write apps for android on ANY platform.
Re:They want devs to choose (Score:2, Informative)
I would say - ignore the iPhone and have Apple go figure out that their policy is crippling the user experience.
Apple shouldn't care if I choose to write the app in assembly or whatever language I choose - even Cobol for that matter as long as the application works.
Re:None of this would've happened... (Score:5, Informative)
And what's more, the way Adobe wants to do it is "in Flash". They could just use Apple's decoder, but the whole point is to keep all web video playing in Flash so that developers need to keep buying new versions of Flash.
What's more, if you read Adobe's on statements on the issue, you eventually realize that a lot of their performance problems come down to this: Apple has two APIs, Carbon and Cocoa. Carbon is basically a depreciated legacy API that exists in OSX to make it easier to allow developers to port OS9 applications to OSX, but Adobe didn't want to rewrite their applications so they kept using the depreciated API. Apple wasn't adding new features to Carbon and so it never got hardware acceleration support for video decoding, which meant that Adobe's applications didn't have access to hardware acceleration support.
Adobe is trying to blame Apple, but their real complaint against Apple is, "In the 10 years that OSX has been out, we never bothered to rewrite their plugin to stop using the depreciate OS9 APIs.
Re:why might apple be doing this (Score:3, Informative)
It's not. It still requires you to explicitly parallelize code and specify dependencies. It also does nothing to deal with the problem of memory sharing.
Re:Substandard apps? (Score:3, Informative)
Unity3D creates an Xcode project for the game engine. Since it's compiled natively, I see no reason why it would fall afoul of Apple's license.
It doesn't matter how it's compiled, anymore. What matters is how the code (written in C, C++ or Objective-C) that you're compiling was produced. If a "translator tool" was involved in the process, then you're violating your SDK license agreement.
Re:Irrelevant. (Score:4, Informative)
I don't see any technical reason for them to care what language you originally use to produce it.
There is a nice simple example right from Mac OS X itself: the application menu.
There are essentially two ways for applications to construct the menu: either by adding own items to whatever Cocoa creates automatically (that's official blessed way) or create one from scratch. If one goes with the official blessed way, then regardless of version of Mac OS X, application's menu would look integral to the rest of the OS. If one picks the latter option (many Carbon applications did it that way) then menu would look out of place for any Mac OS X version except the one application was created originally.
The nice thing about Cocoa framework is that it take over a lot of OS integration tasks. But the story doesn't end there. The way Cocoa takes over the tasks allows Apple to introduce the changes into it in a next Mac OS X versions and have all properly written applications still work, behave and look properly - in accordance with rest of the new OS.
Such practices are essentially taboo in Windows or Java. But Apple with Cocoa (and ObjC - it is the enabler of the magic) does them quite often.
Re:They want devs to choose (Score:3, Informative)
Re:None of this would've happened... (Score:3, Informative)
Carbon is basically a depreciated legacy API that exists in OSX to make it easier to allow developers to port OS9 applications to OSX, but Adobe didn't want to rewrite their applications so they kept using the depreciated API.
And this is also an interesting point, regarding Apple.
Way back in 1997, Apple told everyone that the future was "Rhapsody" and we were all going to rewrite our applications in Objective-C and everything would be wonderful. Developers, by and large, said, "So we're going to take decades of work and rewrite it in a 'weird' language just so we can work on your new operating system? Thanks, but if we're going to rewrite decades of work, we'll do it for Windows. Nice working with you."
So back in 1998, Apple told everyone that future was Mac OS X and that they'd meet us half-way or so. Drag your code up to at least System 7 standards and we'll do the rest. That was Carbon. Of course, developers rightly said, "Oh, but you're not going to be supporting Carbon beyond that." "No, no!" said Apple. "We understand your investment and we're going to keep supporting Carbon! That's why the Finder is in Carbon and will remain so! Trust us--Carbon applications will always be on equal footing with Cocoa applications!"
Yeah, right.
For example, Apple insisted that the future for Carbon apps doing UI was HIViews. "Use HIViews and we'll continue to support you!" They exclaimed. So Adobe rewrote all their stuff to use HIViews. And what happens? "Oh, HIViews aren't 64-bit compatible and they never will be. You have to rewrite all your UI code in Cocoa." So much for continuing to support you, huh?
Re:They want devs to choose (Score:3, Informative)
US federal courts don't treat the Merriam-Webster Dictionary as the last word on what a monopoly is under the law.
Tthey rely instead on the Sherman Antitrust Act [wikipedia.org] and its interpretation over the decades in previous federal court precedents as relates to the regulation of de facto monopolies [wikipedia.org] . Note that a de facto monopoly does not ever have 100% market share (i.e., it is not the sole firm in the relevant market)
A real world, de facto monopoly (as opposed to a dictionary monopoly, or a de jure monopoly) is a firm that has what is known as monopoly market power: they are able to set prices without any regard for the prices of the offerings of existing competitiors.
Microsoft was ruled to have a monopoly in PC operating systems because they could charge $200 retail and $50 OEM when their competitors were offering a product with equivalent functionality for nothing at all.