I know this is your first post, but I just kinda don't believe you on some of the things you are saying here.
For instance this part:
Quote:
Originally Posted by zdawgsf
... To make a blanket statement that restricting iPhone app development to Objective C will ensure every app is as efficient as possible misses the point. It's like saying Mac software written in C++ will always perform more efficiently than software written in Java. ...
... is a bit overdone isn't it? Sure, you are technically accurate, but isn't *most* Mac software written in C++ actually a lot better on average than software written in Java? I mean let's be honest. True, there is no technical reason why developing in Flash has to produce bad code, but the fact is that there is an absolute *ton* of crappy junk written in Java just the same.
Then this part here:
Quote:
Originally Posted by zdawgsf
... In fact there have been several top-ten APPLE RECOMMENDED iPhone applications have been written in Java and Flash. ....
Is just plain hard to swallow.
You have to publish a list of those apps before I'd believe it.
Then you go on a bit about what a fantastic development environment Flash is??? It seems to me like you have a slight bias.
You must have a reading deficiency. You have C/ObjC/ObjC++/C++ so long as it's written in Cocoa.
That isn't true. It is possible to do virtually any combination of link up. Perl calling Win32. Python calling GTK. Java calling Cocoa. Apple provides support for those you listed above.
Quote:
Originally Posted by Bruce Atkinson
Objective C is a language that was ahead of it's time in the 80's, but it isn't the 80's any more. This decision prevents people from making better tools.
I hate going from Visual Studio or Eclipse to XCode, you lose so much functionality. It won't be long before developers get sick of the way they are treated.
I'm curious how long it takes the customers to do the same thing. There is no line Jobs won't cross at this point. How long until the lawsuits start?
I'm not sure what Apple's motivation is behind this move - but it is most certainly NOT to ensure code written for the iPhone is as efficient as possible.
What I am sure of is this is a sad day for developers and consumers. Flash/AS3 is the platform of choice for a development community that builds amazing software in an unique IDE tailored to bridging the design and development communities. In the same way Java is tailored to building portable apps for the Internet, Flash is great for creating custom UI experiences that would be incredibly difficult to build using any other language. If Apple kept the door open and focused screening apps based on what really matters - performance of the end-result - then Flash CS5 and the Packager for iPhone would expand iPhone app development to a new and hungry community of creative designer/developers. And the consumer (and Apple) would win by getting more and more creative and useful apps.
I just don't get it. It's a bad and backwards business decision. And it feels like Big Brother to me.
I think the motivation is clear: They want to control the development environment for apps on their devices. They want this partly for app quality/consistency reasons and partly for simple market dominance reasons. It's the same reason they don't want flash on their devices. They don't want their devices at the mercy of some other company like Adobe, and they don't want apps to look like flash cross-compiles.
You gotta wonder what Adobe is thinking right now though. They must have put a lot of work into these tools.
I guess the consensus is that a native fart app is better than a compelling game built with third party tools.
You've hit the nail on the head. As another comment points out, bad/buggy/crappy apps can be written in *any* programming language, even the god language - Obj-C. Have you ever seen a crappy website? Have you ever seen a really slick website? Both are written in the same languages: HTML/CSS/Javascript.
Apple's insistence on developers using only Obj-C/C/C++ is just silly.
Why? Because the user doesn't give a s*** what it was written in. Does it work without crashing, is it cool, is it useful, is it innovative? That's what the app consumer cares about.
However, the app developer *does* care about the language. Obj-C/C were cool about 10 years ago, and still are good choices for many types of apps. The tools we use to develop apps have changed dramatically in the last 10 years. We have better tools and languages now; these allow developers to produce higher quality apps in less time, which means better quality apps for the end user at lower cost.
Many of you seem to think this is an arbitrary or monopolistic decision by Apple. Did any of you watch today's presentation? Seriously--the answer was right there. The reason for this move is that the iPhone OS now evaluates each app as it is running in order to implement smart multitasking. It can't do that if the app is running within a runtime. It can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS. They can't do that if there's a DMZ (runtime shell) between them and the app.
You gotta wonder what Adobe is thinking right now though.
I would think they will continue executing their current plans with 10.1 and Openscreenproject.org. They don't need to say anything about this. Let Steve throw his tantrum and dig a deeper pit. All those internal emails helped convict Microsoft.
Behind the scenes, I would be looking for somebody small to file a restraint of trade lawsuit against Apple for attempting to prevent software developers from producing software for other platforms, or from being able to buy and use the tools they choose in their development.
I would also be getting friendly with all 50 attorneys general and whichever US Attorneys might have jurisdiction.
Quote:
Originally Posted by ktappe
Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS. They can't do that if there's a DMZ (runtime shell) between them and the app.
No, Apple does not need to do this for that reason. Whether it is in ObjC or not, the OS is going to make those kinds of judgments based on API calls, time spent in blocking APIs, or event timers set. It doesn't matter what dev tools was used to produce the binary code that the ARM chip is running, as it all ends up interfacing with the OS in the same way. Apple already enforces that with the ban on Private Frameworks.
For technology to progress and advance, it should be as open as possible. Developers should be allowed to code in whatever language they want. How can you be so incredibly brain-washed into mindless sheep that you're HAPPY about the ever-increasing limits on freedom [slavery] in the iPhone OS?
Apple chooses what apps you can or cannot use through some ridiculous draconian submission process, and now they control how developers write them too. Next thing you know Jobs will say jump of a bridge and all you sheep actually will do it.
Making apps compiled from other development tools against the rules is one thing, but exactly what tools would Apple use to detect this? I understand they have a tool that detects calls to private APIs, but what kind of signature is there for using an unapproved compiler / programming language?
My guess (based on some experience) is that like most other batch/automated translation tools, the translated programs will be inefficient and maybe even unnecessarily complex. Both factors could burn up battery life on an iPad, iPhone or iTouch. You might not see this on the surface (unless the system cannot run the program at a satisfactory speed due to all the overhead--less of a problem now with all the CPU cycles there are to burn) but it will probably still be there.
Assuming Apple got their hands on whatever tool Adobe might develop to do this, they could probably devise some kind of "signature" to detect it. But they'd have to be careful, as such a method could backfire.
A program that's translated from one language or development environment to another by hand (or rewritten in the new target language) tends not to demonstrate the excess that is left in place by automated conversion tools.
What I'd really like to know is what Apple is hoping to do here? If Flash isn't welcome, fine. But are they really trying to force Adobe to do some kind of major overhaul?
The author of the article might also be interested in knowing that Mono and Silverlight don't really have a direct relationship to one another--both are different things. The only thing they have in common is that both are technologies related to all things Microsoft. (Of course, Mono is a third party development framework that has some compatibility to Microsoft's .NET Framework.)
I think the open source community's answer to Silverlight is "Moonlight". (Moonlight is hosted as part of the Mono project, though, so maybe there is something I missed in there.)
I would think that the main issue developers consider in regards to a platform is if they think they can make some money. That's pretty much all the "treatment" they need. The idea that a bunch of current iPhone devs are going to abandon the platform because they can't use tools that they currently don't is amusing.
It all depends on how they continue to operate. It's not going to be a profitable endevour to create iphone apps if a developer puts months into developing an application only to have it rejected for arbitrary reasons. I have no problem with Apple having strict standards if they were transparent but it is not good business to have a change the rules on a whim approach to application approval. They will continue to get away with it as long as they are dominant but when Android has an equal or greater marketshare than Apple the developers are going to focus on that platform first.
John Gruber at Daring Fireball has what I think is an excellent take on this new restriction by Apple here.
From the article:
Quote:
So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage. If, say, a mobile Flash software platform — which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry — were established, that app market would not give people a reason to prefer the iPhone.
My guess (based on some experience) is that like most other batch/automated translation tools, the translated programs will be inefficient and maybe even unnecessarily complex.
I personally would like to see Apple only allow apps written in assembly language. That will ensure that:
1) Apps are super efficient with no wasted CPU or memory
2) There is a high enough barrier that no more crappy apps would be published on the App Store
Wrong. There are three devices in this platform now.
Everyone always forgets about the iPod Touch. It actually sells more than the iPhone does. Now we have iPad in the mix. I do not see Android surpassing these 3 devices combined anytime soon.
Also, their apps store has FAILED to keep up with Apple's app store growth, by gross and percentage.
While the iPod touch has done better than expected, as noted in the Keynote today, the iPhone has sold 50 million while the touch has sold 35 million.
A niggly point, but true nevertheless.
Coding a game to a potential market of 85,000 iPhones/touches, and factoring in the as yet unknown quantity of iPads that will be sold, has to be motivation enough for lots of developers to code games specifically for the iPhone. They've been doing it already and this doesn't make a huge difference in that.
I'm not a programmer, but it seems to me that this move by Apple is intended more to keep the crap apps out of the store than to stifle developers. Who wants crappy Flash apps just "recompiled" to run on the iPhone, touch, iPad anyway?
We all rely on our devices being as good an experience as possible. This is one way to keep it under control. Does it keep out some good developers? Maybe. Does it keep out a lot of crap? Definitely.
I have a touch, and the battery life is not as good as I would like. I read the same about the iPhone. But, in reading any comparison with Android phones, their battery life doing the same things is no better and in most cases a lot worse.
So, if that is what a person wants, then pick an Android phone and go with it. Frankly I'm glad Android is out there. It keeps Apple moving. But I don't want Apple moving for the sake of moving without protecting their platform AND the users of it.
John Gruber at Daring Fireball has what I think is an excellent take on this new restriction by Apple here.
From the article:
Although I respect a lot of what Gruber has to say, the Apps are not the only reason people buy iPhones. I have an iPod touch, with lots of apps, but mainly use the Apple apps for day-today use.
I love that there are a huge number of apps out there so I have lots of choice, but my choice in getting an iPhone this summer isn't based solely on the apps, it's based on the overall execution of the OS and its basic features.
John Gruber at Daring Fireball has what I think is an excellent take on this new restriction by Apple here.
From the article:
I think Gruber is right that the true motivation is developer lock-in and full platform control. Preventing un-optimized Flash apps is just the public facing explanation. With 185, 000 applications, it's not like the App Store is being threatened to be overwhelmed by Flash ports or that native apps automatically mean there aren't going to be useless or unoptimized apps.
So, if that is what a person wants, then pick an Android phone and go with it. Frankly I'm glad Android is out there. It keeps Apple moving. But I don't want Apple moving for the sake of moving without protecting their platform AND the users of it.
That is a fine sentiment and I don't disagree if that was actually what was happening. But with a lot of Apple's decisions it seems not to be about protecting the quality of their platform and the users but instead to be about protecting their lock-in at the expense of developers and users. It amazes me their position has so many defenders.
It all depends on how they continue to operate. It's not going to be a profitable endevour to create iphone apps if a developer puts months into developing an application only to have it rejected for arbitrary reasons. I have no problem with Apple having strict standards if they were transparent but it is not good business to have a change the rules on a whim approach to application approval. They will continue to get away with it as long as they are dominant but when Android has an equal or greater marketshare than Apple the developers are going to focus on that platform first.
Which developers have been slaving away on Flash based apps they intended for the iPhone? Or ported .NET? Isn't the whole point of working this way to make cross-platform apps? That being the case, not being able to deploy your app on the iPhone by definition doesn't render your work worthless. And if you really want to be able to deploy on the iPhone platform, why wouldn't you use the tools Apple is telling you are best?
Apple's move here is pretty hard nosed, but hardly capricious. It's not like they're just randomly forbidding things willy nilly for no particular reason, and any iPhone dev worth his or her salt is already working in Xcode, Objective-C, and WebKit, as Apple has always advised. This rule has absolutely no effect on such developers, and I doubt that they would start to wonder if Xcode, Objective-C, and WebKit are possibly going to be pulled out from under them just because Apple went insane. And they certainly aren't going to move away from the platform because of a rule that doesn't effect them.
That is a fine sentiment and I don't disagree if that was actually what was happening. But with a lot of Apple's decisions it seems not to be about protecting the quality of their platform and the users but instead to be about protecting their lock-in at the expense of developers and users. It amazes me their position has so many defenders.
The two aren't necessarily mutually exclusive, though, your amazement notwithstanding.
It's not that hard to imagine that Apple sincerely believes they can deliver the best user experience by controlling the platform, is it?
Which developers have been slaving away on Flash based apps they intended for the iPhone? Or ported .NET? Isn't the whole point of working this way to make cross-platform apps? That being the case, not being able to deploy your app on the iPhone by definition doesn't render your work worthless. And if you really want to be able to deploy on the iPhone platform, why wouldn't use the tools Apple is telling you are best?
Apple's move here is pretty hard nosed, but hardly capricious. It's not like there just randomly forbidding things willy nilly for no particular reason, and any iPhone dev worth his or her salt is already working in Xcode, Objective-C, and WebKit, as Apple has always advised. This rule has absolutely no effect on such developers, and I doubt that they would start to wonder if Xcode, Objective-C, and WebKit are possibly going to be pulled out from under them just because Apple went insane.
The problem is that Apples' tools aren't the best in all scenarios. If a well designed apps created with Unity3d can be of higher quality than a lessor designed version written utilizing XC and OC why is it good to ban it? Wouldn't it make a lot more sense to ban apps that don't meet a performance threshold rather than basing it on the tools they used?
I agree they don't have to wonder if Xcode, Objective-C, and WebKit but they do have to wonder if whatever functionality they decide to implement in their app is going to get rejected for arbitrary reasons.
Comments
For instance this part:
... To make a blanket statement that restricting iPhone app development to Objective C will ensure every app is as efficient as possible misses the point. It's like saying Mac software written in C++ will always perform more efficiently than software written in Java. ...
... is a bit overdone isn't it? Sure, you are technically accurate, but isn't *most* Mac software written in C++ actually a lot better on average than software written in Java? I mean let's be honest. True, there is no technical reason why developing in Flash has to produce bad code, but the fact is that there is an absolute *ton* of crappy junk written in Java just the same.
Then this part here:
... In fact there have been several top-ten APPLE RECOMMENDED iPhone applications have been written in Java and Flash. ....
Is just plain hard to swallow.
You have to publish a list of those apps before I'd believe it.
Then you go on a bit about what a fantastic development environment Flash is??? It seems to me like you have a slight bias.
You must have a reading deficiency. You have C/ObjC/ObjC++/C++ so long as it's written in Cocoa.
That isn't true. It is possible to do virtually any combination of link up. Perl calling Win32. Python calling GTK. Java calling Cocoa. Apple provides support for those you listed above.
Objective C is a language that was ahead of it's time in the 80's, but it isn't the 80's any more. This decision prevents people from making better tools.
I hate going from Visual Studio or Eclipse to XCode, you lose so much functionality. It won't be long before developers get sick of the way they are treated.
I'm curious how long it takes the customers to do the same thing. There is no line Jobs won't cross at this point. How long until the lawsuits start?
I'm not sure what Apple's motivation is behind this move - but it is most certainly NOT to ensure code written for the iPhone is as efficient as possible.
What I am sure of is this is a sad day for developers and consumers. Flash/AS3 is the platform of choice for a development community that builds amazing software in an unique IDE tailored to bridging the design and development communities. In the same way Java is tailored to building portable apps for the Internet, Flash is great for creating custom UI experiences that would be incredibly difficult to build using any other language. If Apple kept the door open and focused screening apps based on what really matters - performance of the end-result - then Flash CS5 and the Packager for iPhone would expand iPhone app development to a new and hungry community of creative designer/developers. And the consumer (and Apple) would win by getting more and more creative and useful apps.
I just don't get it. It's a bad and backwards business decision. And it feels like Big Brother to me.
I think the motivation is clear: They want to control the development environment for apps on their devices. They want this partly for app quality/consistency reasons and partly for simple market dominance reasons. It's the same reason they don't want flash on their devices. They don't want their devices at the mercy of some other company like Adobe, and they don't want apps to look like flash cross-compiles.
You gotta wonder what Adobe is thinking right now though. They must have put a lot of work into these tools.
I guess the consensus is that a native fart app is better than a compelling game built with third party tools.
You've hit the nail on the head. As another comment points out, bad/buggy/crappy apps can be written in *any* programming language, even the god language - Obj-C. Have you ever seen a crappy website? Have you ever seen a really slick website? Both are written in the same languages: HTML/CSS/Javascript.
Apple's insistence on developers using only Obj-C/C/C++ is just silly.
Why? Because the user doesn't give a s*** what it was written in. Does it work without crashing, is it cool, is it useful, is it innovative? That's what the app consumer cares about.
However, the app developer *does* care about the language. Obj-C/C were cool about 10 years ago, and still are good choices for many types of apps. The tools we use to develop apps have changed dramatically in the last 10 years. We have better tools and languages now; these allow developers to produce higher quality apps in less time, which means better quality apps for the end user at lower cost.
You gotta wonder what Adobe is thinking right now though.
I would think they will continue executing their current plans with 10.1 and Openscreenproject.org. They don't need to say anything about this. Let Steve throw his tantrum and dig a deeper pit. All those internal emails helped convict Microsoft.
Behind the scenes, I would be looking for somebody small to file a restraint of trade lawsuit against Apple for attempting to prevent software developers from producing software for other platforms, or from being able to buy and use the tools they choose in their development.
I would also be getting friendly with all 50 attorneys general and whichever US Attorneys might have jurisdiction.
Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS. They can't do that if there's a DMZ (runtime shell) between them and the app.
No, Apple does not need to do this for that reason. Whether it is in ObjC or not, the OS is going to make those kinds of judgments based on API calls, time spent in blocking APIs, or event timers set. It doesn't matter what dev tools was used to produce the binary code that the ARM chip is running, as it all ends up interfacing with the OS in the same way. Apple already enforces that with the ban on Private Frameworks.
Good. This pleases me.
Yeeeeeeessssssss!
Once again, a smart move by Apple.
Jesus Christ, these people sicken me.
For technology to progress and advance, it should be as open as possible. Developers should be allowed to code in whatever language they want. How can you be so incredibly brain-washed into mindless sheep that you're HAPPY about the ever-increasing limits on freedom [slavery] in the iPhone OS?
Apple chooses what apps you can or cannot use through some ridiculous draconian submission process, and now they control how developers write them too. Next thing you know Jobs will say jump of a bridge and all you sheep actually will do it.
Making apps compiled from other development tools against the rules is one thing, but exactly what tools would Apple use to detect this? I understand they have a tool that detects calls to private APIs, but what kind of signature is there for using an unapproved compiler / programming language?
My guess (based on some experience) is that like most other batch/automated translation tools, the translated programs will be inefficient and maybe even unnecessarily complex. Both factors could burn up battery life on an iPad, iPhone or iTouch. You might not see this on the surface (unless the system cannot run the program at a satisfactory speed due to all the overhead--less of a problem now with all the CPU cycles there are to burn) but it will probably still be there.
Assuming Apple got their hands on whatever tool Adobe might develop to do this, they could probably devise some kind of "signature" to detect it. But they'd have to be careful, as such a method could backfire.
A program that's translated from one language or development environment to another by hand (or rewritten in the new target language) tends not to demonstrate the excess that is left in place by automated conversion tools.
What I'd really like to know is what Apple is hoping to do here? If Flash isn't welcome, fine. But are they really trying to force Adobe to do some kind of major overhaul?
The author of the article might also be interested in knowing that Mono and Silverlight don't really have a direct relationship to one another--both are different things. The only thing they have in common is that both are technologies related to all things Microsoft. (Of course, Mono is a third party development framework that has some compatibility to Microsoft's .NET Framework.)
I think the open source community's answer to Silverlight is "Moonlight". (Moonlight is hosted as part of the Mono project, though, so maybe there is something I missed in there.)
I would think that the main issue developers consider in regards to a platform is if they think they can make some money. That's pretty much all the "treatment" they need. The idea that a bunch of current iPhone devs are going to abandon the platform because they can't use tools that they currently don't is amusing.
It all depends on how they continue to operate. It's not going to be a profitable endevour to create iphone apps if a developer puts months into developing an application only to have it rejected for arbitrary reasons. I have no problem with Apple having strict standards if they were transparent but it is not good business to have a change the rules on a whim approach to application approval. They will continue to get away with it as long as they are dominant but when Android has an equal or greater marketshare than Apple the developers are going to focus on that platform first.
From the article:
So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage. If, say, a mobile Flash software platform — which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry — were established, that app market would not give people a reason to prefer the iPhone.
My guess (based on some experience) is that like most other batch/automated translation tools, the translated programs will be inefficient and maybe even unnecessarily complex.
I personally would like to see Apple only allow apps written in assembly language. That will ensure that:
1) Apps are super efficient with no wasted CPU or memory
2) There is a high enough barrier that no more crappy apps would be published on the App Store
Wrong. There are three devices in this platform now.
Everyone always forgets about the iPod Touch. It actually sells more than the iPhone does. Now we have iPad in the mix. I do not see Android surpassing these 3 devices combined anytime soon.
Also, their apps store has FAILED to keep up with Apple's app store growth, by gross and percentage.
While the iPod touch has done better than expected, as noted in the Keynote today, the iPhone has sold 50 million while the touch has sold 35 million.
A niggly point, but true nevertheless.
Coding a game to a potential market of 85,000 iPhones/touches, and factoring in the as yet unknown quantity of iPads that will be sold, has to be motivation enough for lots of developers to code games specifically for the iPhone. They've been doing it already and this doesn't make a huge difference in that.
I'm not a programmer, but it seems to me that this move by Apple is intended more to keep the crap apps out of the store than to stifle developers. Who wants crappy Flash apps just "recompiled" to run on the iPhone, touch, iPad anyway?
We all rely on our devices being as good an experience as possible. This is one way to keep it under control. Does it keep out some good developers? Maybe. Does it keep out a lot of crap? Definitely.
I have a touch, and the battery life is not as good as I would like. I read the same about the iPhone. But, in reading any comparison with Android phones, their battery life doing the same things is no better and in most cases a lot worse.
So, if that is what a person wants, then pick an Android phone and go with it. Frankly I'm glad Android is out there. It keeps Apple moving. But I don't want Apple moving for the sake of moving without protecting their platform AND the users of it.
John Gruber at Daring Fireball has what I think is an excellent take on this new restriction by Apple here.
From the article:
Although I respect a lot of what Gruber has to say, the Apps are not the only reason people buy iPhones. I have an iPod touch, with lots of apps, but mainly use the Apple apps for day-today use.
I love that there are a huge number of apps out there so I have lots of choice, but my choice in getting an iPhone this summer isn't based solely on the apps, it's based on the overall execution of the OS and its basic features.
John Gruber at Daring Fireball has what I think is an excellent take on this new restriction by Apple here.
From the article:
I think Gruber is right that the true motivation is developer lock-in and full platform control. Preventing un-optimized Flash apps is just the public facing explanation. With 185, 000 applications, it's not like the App Store is being threatened to be overwhelmed by Flash ports or that native apps automatically mean there aren't going to be useless or unoptimized apps.
They lock you to one carrier.
They decide what apps you can or cannot use.
They give you no customization.
They sue the competition.
And block alternate ways to make apps/content.
And people are supporting this??
MAN they are evil. Jesus H Christ.
So, if that is what a person wants, then pick an Android phone and go with it. Frankly I'm glad Android is out there. It keeps Apple moving. But I don't want Apple moving for the sake of moving without protecting their platform AND the users of it.
That is a fine sentiment and I don't disagree if that was actually what was happening. But with a lot of Apple's decisions it seems not to be about protecting the quality of their platform and the users but instead to be about protecting their lock-in at the expense of developers and users. It amazes me their position has so many defenders.
It all depends on how they continue to operate. It's not going to be a profitable endevour to create iphone apps if a developer puts months into developing an application only to have it rejected for arbitrary reasons. I have no problem with Apple having strict standards if they were transparent but it is not good business to have a change the rules on a whim approach to application approval. They will continue to get away with it as long as they are dominant but when Android has an equal or greater marketshare than Apple the developers are going to focus on that platform first.
Which developers have been slaving away on Flash based apps they intended for the iPhone? Or ported .NET? Isn't the whole point of working this way to make cross-platform apps? That being the case, not being able to deploy your app on the iPhone by definition doesn't render your work worthless. And if you really want to be able to deploy on the iPhone platform, why wouldn't you use the tools Apple is telling you are best?
Apple's move here is pretty hard nosed, but hardly capricious. It's not like they're just randomly forbidding things willy nilly for no particular reason, and any iPhone dev worth his or her salt is already working in Xcode, Objective-C, and WebKit, as Apple has always advised. This rule has absolutely no effect on such developers, and I doubt that they would start to wonder if Xcode, Objective-C, and WebKit are possibly going to be pulled out from under them just because Apple went insane. And they certainly aren't going to move away from the platform because of a rule that doesn't effect them.
That is a fine sentiment and I don't disagree if that was actually what was happening. But with a lot of Apple's decisions it seems not to be about protecting the quality of their platform and the users but instead to be about protecting their lock-in at the expense of developers and users. It amazes me their position has so many defenders.
The two aren't necessarily mutually exclusive, though, your amazement notwithstanding.
It's not that hard to imagine that Apple sincerely believes they can deliver the best user experience by controlling the platform, is it?
Which developers have been slaving away on Flash based apps they intended for the iPhone? Or ported .NET? Isn't the whole point of working this way to make cross-platform apps? That being the case, not being able to deploy your app on the iPhone by definition doesn't render your work worthless. And if you really want to be able to deploy on the iPhone platform, why wouldn't use the tools Apple is telling you are best?
Apple's move here is pretty hard nosed, but hardly capricious. It's not like there just randomly forbidding things willy nilly for no particular reason, and any iPhone dev worth his or her salt is already working in Xcode, Objective-C, and WebKit, as Apple has always advised. This rule has absolutely no effect on such developers, and I doubt that they would start to wonder if Xcode, Objective-C, and WebKit are possibly going to be pulled out from under them just because Apple went insane.
The problem is that Apples' tools aren't the best in all scenarios. If a well designed apps created with Unity3d can be of higher quality than a lessor designed version written utilizing XC and OC why is it good to ban it? Wouldn't it make a lot more sense to ban apps that don't meet a performance threshold rather than basing it on the tools they used?
I agree they don't have to wonder if Xcode, Objective-C, and WebKit but they do have to wonder if whatever functionality they decide to implement in their app is going to get rejected for arbitrary reasons.