That's right. Apple is the big boy on the block now, so that makes the right by default. While one does have the right to complain, you really shouldn't. Only if you have the resources to develop an entire platform on your own do your complaints have any merit. And in that case, you are then a competitor to Apple, so that invalidates your complaints as well. Best to just keep quiet and assume Apple cannot be wrong. Success==right.
Notice how the post you're replying to understands the issue to be a two-way street, whist you promptly ignore it and pretend anyone agreeing with Apple's point of view is shutting down the debate. You build your own imaginary gulag, and lock your own chains, and create your own sense of repression in this situation. Maybe you're confusing that with being trumped. Keep on torturing yourself with imaginary monsters if you like.
I still don't understand why people are so upset that a vendor would ask that things written for their devices conform to a standard they feel is best for their device. Do you want to insist that radios also carry TV? That my Honda use Ford parts? That a creator can specify what goes into and on their device?
No. But I do want to insist that TVs play video shot by any camera as long as it's in the correct format. I don't want Ford or Honda to dictate what brand of wrench can be used to work on their car.
I have no problem--indeed I agree with--Apple requiring the use of their APIs on their platform. If you have to use their buttons and their toolbars and their dialogs--great! I totally support that. But saying that I have to do so using only their choice of programming language is where they stop dictating the end result and start deciding what kind of wrench you can use to get to that end result. It's like Apple requiring that a socket wrench be used when you really need a flare nut wrench. That kind of decision hurts users because they end up with a shoddier product than they would get if they used the proper tool.
What would happen if Microsoft suddenly released an update that prevented iTunes from running? Think of the chaos that would ensue. Microsoft could take a big cut out of Apple's sales by doing just that. Could they get away with it? Probably not. Lawyers would be swarming everywhere.
It would be Microsoft's right to do, but after weighing all the costs and benefits to users and developers. If iTunes or its software underpinnings got, say, buggy/slow and started to hog system resources, made programs crash, etc (as Apple claims what some of this stuff does) and it was seriously detracting from user experience of the company's product, then it would not just be right, but prudent for Microsoft to do so.
But decency would require that the offending company be given enough notice/chances. My sense is Apple has done that with Adobe, in particular, but there has been little give from Adobe's side.
Bottom line: It's a legitimate call from Apple's standpoint.
Nice to hear that Mr. Jobs is responding on this topic but there is something wrong with this approach. I think it the best interest of Apple to have a public figure when dealing with iPhone developer issues as there has been so many of them since the beginning and developers are a passionate and vocal bunch. The CEO should not be the public figure for these matters and ultimately receive the blame by unhappy developers. How about an iPhone Evangelist? Every software company has one.
Personally, as an iPhone developer I really could care less about Adobe, Flash and this specific change to the agreement. Adobe makes tools for the web, they have no entitlement to be on the iPhone. However, I can understand how some people are upset since they were brainwashed into thinking that open is good and also because they were probably making good money using this shortcut.
Apple needs to be more transparent and consistent with their developer agreement. They need to communicate better. A few weeks back there was an issue with adult apps and now this debacle. You can't allow something then ban it later on. Apple should seriously find a better way to manage this. Having the CEO respond to emails directly and occasionally is not the way to go. Microsoft won the PC battle because they catered much better to developers. Google's Android is has a great reputation with developers because they are seen as being open. Apple needs to improve its propaganda machine.
Currently, Apple risks alienating the very same folks who are behind the success of iPhone. At this crucial time when their biggest rival (Google) as gaining momentum, I hope they will improve on this aspect because at the first sign of Android overtaking the iPhone, you can bet the developers will follow.
... Rather than it being a move about software quality (which was the reason given for the centralized App Store), it's more about profit and control. If Opera goes through, it starts to eat away at their mobile Safari smartphone share. If Flash apps can be authored, it means there's no need to buy a Mac to build apps and no need to use XCode.
People say this all the time (about it just being about the money), but I've yet to see anything that indicates it's true. It's just a flip comment to toss out that can't be disproven in any substantive way.
I bet you can't give a single concrete example that would indicate this is true.
I find the idea that Apple would jeopardise so much and take the hit in terms of good will just to enable the sales of a few more iMacs a bit ridiculous. Especially when they are selling them so fast already they have a hard time keeping up with production as it is.
Apple is not a profit driven company. Everything about their history, their policies, their margins and their market stance indicates that squeezing that extra dollar out of consumers is actually the last thing on the company's collective mind.
3. Gruber said that they will always be inferior to a natively-coded app, and of course he's right. Whether it's speed, UI, or compatibility, an intermediary layer by its very nature will result in an app that does not perform at the same level as a native one. ...
But you can program in another programming language without using any intermediate layers at all. C++ can call C functions without an intermediate layer. Objective-C can call C++ and C. And the same goes for many other languages. The issue of what programming language you use is totally unrelated to whether you use shoddy cross-platform compatibility layers.
People say this all the time (about it just being about the money), but I've yet to see anything that indicates it's true. It's just a flip comment to toss out that can't be disproven in any substantive way.
I bet you can't give a single concrete example that would indicate this is true.
I find the idea that Apple would jeopardise so much and take the hit in terms of good will just to enable the sales of a few more iMacs a bit ridiculous. Especially when they are selling them so fast already they have a hard time keeping up with production as it is.
Apple is not a profit driven company. Everything about their history, their policies, their margins and their market stance indicates that squeezing that extra dollar out of consumers is actually the last thing on the company's collective mind.
Even without abstraction of programming, there are still plenty of crappy apps in the store. Steve Jobs is being too gracious with what's already developed.
Sub-standard apps you will find regardless of the original programming language.
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
Your claim that "everybody knows" that Scala or other languages are better programming languages than those derived from C is what is ridiculous. For every advantage of Scala, there is a corresponding disadvantage. That's why David R. MacIver, who is no enemy of Scala, concludes on his blog: "I try to stay out of language wars these days. I find the whole endeavour incredibly tedious. I don?t really feel like arguing whether OCaml is better than Ruby is better than Scala is better than brainfuck is better than C. I like them all (ok maybe not brainfuck), and there are valid arguments for and against each of them."
Not what's best, or easiest for the develops who don't want to learn a different language.
Sometimes I want to use a screwdriver, but it's not because I don't know how to use a hammer. The problem with Apple's policy is it's too blunt. I hate crappy portware as much as anyone. But limiting programming languages isn't the answer. 95% of the apps on the app store today are distingustingly bad. And 99% of those horrific apps are already written exclusively using Apple's tools.
Sometimes a different tool does the job better. I want the choice to be able to use that tool--not because I don't know how to use the other tools, but because the other tools are simply the wrong ones for the job. As long as the final product natively targets Apple's platform, what difference does it make. Well, it makes a huge difference! Using the right tool produces a better product. And sometimes a product can only be produced using other tools. Using another tool doesn't mean you're not integrating with the platform.
standard UI and stable performance is why I agree with Apple on this one. I think Flash debs are often lazy & the app store is already deluged in mediocre apps.
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
Nice play on spinning what I said to suit your position. Perhaps I did not adequately explain myself. My point is not to focus on the language being used and not how old that language is. I failed I think to explain that.
To develop for product X, here are the guidelines. Use it or use the door. Whether you agree with it or not is irrelevant since that is how it works. If you don't want to change, then move aside for someone that will.
Developers saw how good Apple's iPhone was when it came out and how the joe-consumers were waiting in line for hours to get one. Developers of course helped the platform get to where it is. Consumers love their device due to the control Apple has on it. Scary but sad truth.
Sometimes I want to use a screwdriver, but it's not because I don't know how to use a hammer. The problem with Apple's policy is it's too blunt. I hate crappy portware as much as anyone. But limiting programming languages isn't the answer. 95% of the apps on the app store today are distingustingly bad. And 99% of those horrific apps are already written exclusively using Apple's tools.
Yet neither Flash nor Monotouch offer any respite from the aforementioned mediocrity. In fact they'd likey swell the 95% of bad apps.
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
How is garbage collection (checks to see if it needs to clear up any memory) going to use less processor time than manual memory management (clears up when it is told to). Only if it's badly written will the latter ever perform slower.
This about Apple ensuring new features get adopted as fast as possible, by controlling their platform themselves.
If they allow third-party IDEs become popular, then it'll the third party that determines when the new features are adopted (after Apple has released the new features).
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
I already covered this nonsensical assertion of hypocrisy in another thread:
Are you saying that Apple releases sub-standard software?
I love Apple and all, but because of the extra non-core frameworks that are needed on Windows, the software does run worse. And that just supports Steve's argument further.
Your claim that "everybody knows" that Scala or other languages are better programming languages than those derived from C is what is ridiculous. For every advantage of Scala, there is a corresponding disadvantage. That's why David R. MacIver, who is no enemy of Scala, concludes on his blog: "I try to stay out of language wars these days. I find the whole endeavour incredibly tedious. I don?t really feel like arguing whether OCaml is better than Ruby is better than Scala is better than brainfuck is better than C. I like them all (ok maybe not brainfuck), and there are valid arguments for and against each of them."
Right. No one language can be proclaimed universally better than any other. What matters is the final product. It all ends up as machine code anyway. Apple is the one claiming that using only C-family languages will produce better apps in the app store. I think that's demonstrably false. I love Objective-C. And Apple does a great job designing Objective-C APIs. The app we're writing uses Objective-C for all interface and user interaction code. But the backend is written in Scala and compiled with VMKit. It would be slower in Objective-C, at least 10x more lines of code, take 10x longer to write and maintain, and have more bugs. The end user has a completely native experience, they have no way of even knowing that another program language was used along the way.
Apple is unnecessarily forbidding completely native apps with this policy--that's why it's ridiculous.
Rather than it being a move about software quality (which was the reason given for the centralized App Store), it's more about profit and control. If Opera goes through, it starts to eat away at their mobile Safari smartphone share.
Opera adds almost nothing of value to the iPhone platform. And, what little it does offer is more than offset by the security problems (i.e., https issues which violate users' expectations), and the fact that it undermines the whole web app side of iPhone development. This is just another instance of someone undermining the iPhone OS platform for their own financial gain, which Apple has no obligation to tolerate. It's not like Opera are pouring their souls into Opera Mini development for the good of mankind.
Comments
That's right. Apple is the big boy on the block now, so that makes the right by default. While one does have the right to complain, you really shouldn't. Only if you have the resources to develop an entire platform on your own do your complaints have any merit. And in that case, you are then a competitor to Apple, so that invalidates your complaints as well. Best to just keep quiet and assume Apple cannot be wrong. Success==right.
Notice how the post you're replying to understands the issue to be a two-way street, whist you promptly ignore it and pretend anyone agreeing with Apple's point of view is shutting down the debate. You build your own imaginary gulag, and lock your own chains, and create your own sense of repression in this situation. Maybe you're confusing that with being trumped. Keep on torturing yourself with imaginary monsters if you like.
I still don't understand why people are so upset that a vendor would ask that things written for their devices conform to a standard they feel is best for their device. Do you want to insist that radios also carry TV? That my Honda use Ford parts? That a creator can specify what goes into and on their device?
No. But I do want to insist that TVs play video shot by any camera as long as it's in the correct format. I don't want Ford or Honda to dictate what brand of wrench can be used to work on their car.
I have no problem--indeed I agree with--Apple requiring the use of their APIs on their platform. If you have to use their buttons and their toolbars and their dialogs--great! I totally support that. But saying that I have to do so using only their choice of programming language is where they stop dictating the end result and start deciding what kind of wrench you can use to get to that end result. It's like Apple requiring that a socket wrench be used when you really need a flare nut wrench. That kind of decision hurts users because they end up with a shoddier product than they would get if they used the proper tool.
What would happen if Microsoft suddenly released an update that prevented iTunes from running? Think of the chaos that would ensue. Microsoft could take a big cut out of Apple's sales by doing just that. Could they get away with it? Probably not. Lawyers would be swarming everywhere.
It would be Microsoft's right to do, but after weighing all the costs and benefits to users and developers. If iTunes or its software underpinnings got, say, buggy/slow and started to hog system resources, made programs crash, etc (as Apple claims what some of this stuff does) and it was seriously detracting from user experience of the company's product, then it would not just be right, but prudent for Microsoft to do so.
But decency would require that the offending company be given enough notice/chances. My sense is Apple has done that with Adobe, in particular, but there has been little give from Adobe's side.
Bottom line: It's a legitimate call from Apple's standpoint.
Personally, as an iPhone developer I really could care less about Adobe, Flash and this specific change to the agreement. Adobe makes tools for the web, they have no entitlement to be on the iPhone. However, I can understand how some people are upset since they were brainwashed into thinking that open is good and also because they were probably making good money using this shortcut.
Apple needs to be more transparent and consistent with their developer agreement. They need to communicate better. A few weeks back there was an issue with adult apps and now this debacle. You can't allow something then ban it later on. Apple should seriously find a better way to manage this. Having the CEO respond to emails directly and occasionally is not the way to go. Microsoft won the PC battle because they catered much better to developers. Google's Android is has a great reputation with developers because they are seen as being open. Apple needs to improve its propaganda machine.
Currently, Apple risks alienating the very same folks who are behind the success of iPhone. At this crucial time when their biggest rival (Google) as gaining momentum, I hope they will improve on this aspect because at the first sign of Android overtaking the iPhone, you can bet the developers will follow.
... Rather than it being a move about software quality (which was the reason given for the centralized App Store), it's more about profit and control. If Opera goes through, it starts to eat away at their mobile Safari smartphone share. If Flash apps can be authored, it means there's no need to buy a Mac to build apps and no need to use XCode.
People say this all the time (about it just being about the money), but I've yet to see anything that indicates it's true. It's just a flip comment to toss out that can't be disproven in any substantive way.
I bet you can't give a single concrete example that would indicate this is true.
I find the idea that Apple would jeopardise so much and take the hit in terms of good will just to enable the sales of a few more iMacs a bit ridiculous. Especially when they are selling them so fast already they have a hard time keeping up with production as it is.
Apple is not a profit driven company. Everything about their history, their policies, their margins and their market stance indicates that squeezing that extra dollar out of consumers is actually the last thing on the company's collective mind.
3. Gruber said that they will always be inferior to a natively-coded app, and of course he's right. Whether it's speed, UI, or compatibility, an intermediary layer by its very nature will result in an app that does not perform at the same level as a native one. ...
But you can program in another programming language without using any intermediate layers at all. C++ can call C functions without an intermediate layer. Objective-C can call C++ and C. And the same goes for many other languages. The issue of what programming language you use is totally unrelated to whether you use shoddy cross-platform compatibility layers.
People say this all the time (about it just being about the money), but I've yet to see anything that indicates it's true. It's just a flip comment to toss out that can't be disproven in any substantive way.
I bet you can't give a single concrete example that would indicate this is true.
I find the idea that Apple would jeopardise so much and take the hit in terms of good will just to enable the sales of a few more iMacs a bit ridiculous. Especially when they are selling them so fast already they have a hard time keeping up with production as it is.
Apple is not a profit driven company. Everything about their history, their policies, their margins and their market stance indicates that squeezing that extra dollar out of consumers is actually the last thing on the company's collective mind.
Great car garage analogy over at TechCrunch.
In short, Apple is like a car repair place with an open hiring policy...
Sub-standard apps you will find regardless of the original programming language.
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
Your claim that "everybody knows" that Scala or other languages are better programming languages than those derived from C is what is ridiculous. For every advantage of Scala, there is a corresponding disadvantage. That's why David R. MacIver, who is no enemy of Scala, concludes on his blog: "I try to stay out of language wars these days. I find the whole endeavour incredibly tedious. I don?t really feel like arguing whether OCaml is better than Ruby is better than Scala is better than brainfuck is better than C. I like them all (ok maybe not brainfuck), and there are valid arguments for and against each of them."
Not what's best, or easiest for the develops who don't want to learn a different language.
Sometimes I want to use a screwdriver, but it's not because I don't know how to use a hammer. The problem with Apple's policy is it's too blunt. I hate crappy portware as much as anyone. But limiting programming languages isn't the answer. 95% of the apps on the app store today are distingustingly bad. And 99% of those horrific apps are already written exclusively using Apple's tools.
Sometimes a different tool does the job better. I want the choice to be able to use that tool--not because I don't know how to use the other tools, but because the other tools are simply the wrong ones for the job. As long as the final product natively targets Apple's platform, what difference does it make. Well, it makes a huge difference! Using the right tool produces a better product. And sometimes a product can only be produced using other tools. Using another tool doesn't mean you're not integrating with the platform.
If developers don't like it then hit the highway.
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
Nice play on spinning what I said to suit your position. Perhaps I did not adequately explain myself. My point is not to focus on the language being used and not how old that language is. I failed I think to explain that.
To develop for product X, here are the guidelines. Use it or use the door. Whether you agree with it or not is irrelevant since that is how it works. If you don't want to change, then move aside for someone that will.
Developers saw how good Apple's iPhone was when it came out and how the joe-consumers were waiting in line for hours to get one. Developers of course helped the platform get to where it is. Consumers love their device due to the control Apple has on it. Scary but sad truth.
Sometimes I want to use a screwdriver, but it's not because I don't know how to use a hammer. The problem with Apple's policy is it's too blunt. I hate crappy portware as much as anyone. But limiting programming languages isn't the answer. 95% of the apps on the app store today are distingustingly bad. And 99% of those horrific apps are already written exclusively using Apple's tools.
Yet neither Flash nor Monotouch offer any respite from the aforementioned mediocrity. In fact they'd likey swell the 95% of bad apps.
well - from what i read about itunes on windows - you just proved steve's argument.
Are you saying that Apple releases sub-standard software?
Exactly. And Apple is forbidding evolution--to better, faster, more stable, more maintainable programming languages. Objective-C is three decades old. New languages, like Scala, have powerful type systems and flexible syntaxes compared to Objective-C. Their type systems allow them to be heavily optimized by compilers. They are precisely garbage collected, which takes less processor time than manual memory management. And many memory allocations can be eliminated all together, which uses less memory than manually managed objects that are always allocated on the heap, and often less memory than C++ because the optimizer runs at link time and sees the whole program.
I agree with your point wholeheartedly. But you make the case for exactly why Apple's policy is ridiculous.
How is garbage collection (checks to see if it needs to clear up any memory) going to use less processor time than manual memory management (clears up when it is told to). Only if it's badly written will the latter ever perform slower.
This about Apple ensuring new features get adopted as fast as possible, by controlling their platform themselves.
If they allow third-party IDEs become popular, then it'll the third party that determines when the new features are adopted (after Apple has released the new features).
If you can't see that, you truly are an idiot.
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
I already covered this nonsensical assertion of hypocrisy in another thread:
http://forums.appleinsider.com/showp...&postcount=251
The bottom line, stop whining, man up, start programming in Objective-C.
Are you saying that Apple releases sub-standard software?
I love Apple and all, but because of the extra non-core frameworks that are needed on Windows, the software does run worse. And that just supports Steve's argument further.
Your claim that "everybody knows" that Scala or other languages are better programming languages than those derived from C is what is ridiculous. For every advantage of Scala, there is a corresponding disadvantage. That's why David R. MacIver, who is no enemy of Scala, concludes on his blog: "I try to stay out of language wars these days. I find the whole endeavour incredibly tedious. I don?t really feel like arguing whether OCaml is better than Ruby is better than Scala is better than brainfuck is better than C. I like them all (ok maybe not brainfuck), and there are valid arguments for and against each of them."
Right. No one language can be proclaimed universally better than any other. What matters is the final product. It all ends up as machine code anyway. Apple is the one claiming that using only C-family languages will produce better apps in the app store. I think that's demonstrably false. I love Objective-C. And Apple does a great job designing Objective-C APIs. The app we're writing uses Objective-C for all interface and user interaction code. But the backend is written in Scala and compiled with VMKit. It would be slower in Objective-C, at least 10x more lines of code, take 10x longer to write and maintain, and have more bugs. The end user has a completely native experience, they have no way of even knowing that another program language was used along the way.
Apple is unnecessarily forbidding completely native apps with this policy--that's why it's ridiculous.
Rather than it being a move about software quality (which was the reason given for the centralized App Store), it's more about profit and control. If Opera goes through, it starts to eat away at their mobile Safari smartphone share.
Opera adds almost nothing of value to the iPhone platform. And, what little it does offer is more than offset by the security problems (i.e., https issues which violate users' expectations), and the fact that it undermines the whole web app side of iPhone development. This is just another instance of someone undermining the iPhone OS platform for their own financial gain, which Apple has no obligation to tolerate. It's not like Opera are pouring their souls into Opera Mini development for the good of mankind.