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?
It seems illogical to me that they could believe that banning apps based on toolset used delivers a better experience than banning apps based on something like not meeting performance thresholds or some other measurement that truly would benefit users.
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 suppose anything's possible, but how often do cross platform toolkits produce better than native results? And even if there's the odd standout, is it reasonable to imagine that iPhone users are going to suffer any particular dearth of top-notch apps because of Apple's policy?
I get that there's a kind of "in a perfect world all else being equal" kind of thing here, but the bottom line is that Apple's users won't suffer and the vast majority of iPhone developers won't suffer. Given Apple's self-interest in controlling the platform, it's not hard to see why they figured they could go ahead and do this.
Quote:
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.
I think the arbitrary app rejection thing has been wildly overstated.
I wish someone with greater knowledge of the whole thing than the article's author would chime in with an explanation.
I am no coder, but it seems to me that if the resultant code is the same then there is no way to tell what the thing was "originally" written in. Conversely, if Apple can tell what language things were "originally written in," then the resultant code is not equivalent and they have every right to argue for it not being used.
It's fairly straightforward. If the language isn't one of the authorized languages it will won't have the applicable Apple Framework calls, and those have signatures that are readily identifiable. Or the compiled code could have an embedded runtime component which would also be identifiable. Or the cross compilers generate code that has a certain fingerprint. Compiled code is actually very traceable and forensically usable in court during licensing/patent/copyright cases. If it's identifiable enough for a set of lawyers and a judge, that makes it pretty straightforward for the applicable Apple engineers.
It seems illogical to me that they could believe that banning apps based on toolset used delivers a better experience than banning apps based on something like not meeting performance thresholds or some other measurement that truly would benefit users.
I imagine the real question, from Apple's perspective, would be whether or not banning a tool set would result in any actual loss for the user. I think the answer to that is an obvious "no."
Beyond that you appear to be just insisting on a kind of pointless platform morality, or something. Are you under the impression that there was some great functionality that will never hit the iPhone because people can't use cross-platform tool kits? Because I've never really heard anyone argue that the point of working cross-platform was that you were likely to end up with better applications than if you used native tools.
And it's not like the platform is hurting for capable devs that are happy to use the native tools, so....
I suppose anything's possible, but how often do cross platform toolkits produce better than native results? And even if there's the odd standout, is it reasonable to imagine that iPhone users are going to suffer any particular dearth of top-notch apps because of Apple's policy?
I get that there's a kind of "in a perfect world all else being equal" kind of thing here, but the bottom line is that Apple's users won't suffer and the vast majority of iPhone developers won't suffer. Given Apple's self-interest in controlling the platform, it's not hard to see why they figured they could go ahead and do this.
I think the arbitrary app rejection thing has been wildly overstated.
We'll see, there are a lot of good apps written using Unity3D. Will those get to stay or will they be removed? If they stay and the policy doesn't flow through to existing apps (i.e. no mass removal of already approved apps - like Apple has done in the past) then maybe it won't be too bad for users except for losing out on any apps developed by talented C# coders who choose not to go the ObjC route.
Maybe the abitrary app rejection thing has been overstated but some of the examples are so egregious (Google Voice, banning apps for using certain non profane words, using gestures apple doesn't want others to use, etc....) that the reputation the app approval process has is a well deserved one.
So in addition limiting what apps you can install on your Apple devices, now they have decided that how the apps are developed is also their business.
I am sorry, this is just plain silly.
I see the mobile market going to same way as the desktop market. Apple will do well, making a nice living off the drones that don't mind their draconian operating practices, meanwhile the bulk of the market will go to other companies that don't want to act as your nanny.
-kpluck
The kind of thing Apple just ruled out has significant security implications. When an app provides a security breach that wouldn't have been there had the correct API usage been implemented, then yes it becomes Apples problem and Apple has every right to control that potential problem vector. Because nobody would buy for a second Apple trying to pass the blame for a security problem to somebody else on a non-jailbroken phone.
You have no idea how your 15 year from now desktop OS looks from a security standpoint. It actually looks a lot like it will be going the way of the iPhone OS / Chrome browser. You won't have a nanny, you will have a self sealing sandbox, and to keep the sand from getting out of the box, or unauthorized sand from getting in there will be a lot less development monkey-business allowed.
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.
I do think this rule change is going to put more developers in the crossfire than just the odd person wanting to port a Flash app.
For example, Appcelerator Titanium is supposed to allow people with primarily web development skills in Javascript and Ruby to have greater access to iPhone APIs to make native apps, kind of like the Android philosophy, and claims to be used by tens of thousands of developers.
Perhaps not all of those developers are targeting the iPhone, but there is now concern about whether this development tool and people who use it will continue to be supported in iPhone 4.
Similarly as John Gruber mentioned, the Unity Engine used in popular games like Ravensword uses Mono and is at risk. Ravensword had notable graphics and good performance as a 3d RPG when it was released so it's not like not being a pure XCode creation was a huge hinderance.
Even the much talked about Unreal Engine 3 for iPhone uses UnrealScript and a virtual machine for game logic. Interestingly, Apple reportedly worked closely with Epic to get the virtual machine working since the VM would otherwise be banned. Presumably, Apple could make another exception for Epic and UnrealScript. Although, this opens the door to questions on who deserves exceptions.
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.
Well, I think Gruber got a few things right, but...
a) I don't think he actually said anywhere that, "the true motivation is developer lock-in." He did however say:
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. [...] If that were to happen, there’s no lock-in advantage.
b) I think he comes very close to the "true" motivations here:
Quote:
Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.
and here:
Quote:
Flash CS5 and MonoTouch aren’t so much cross-platform as meta-platforms. Adobe’s goal isn’t to help developers write iPhone apps. Adobe’s goal is to encourage developers to write Flash apps that run on the iPhone (and elsewhere) instead of writing iPhone-specific apps. Apple isn’t just ambivalent about Adobe’s goals in this regard — it is in Apple’s direct interest to thwart them.
In other words, the goal of these "meta-platforms", especially Flash, is to achieve developer lock-in themselves and to commoditize actual platforms so that they simply become vehicles for, in Adobe's case, Flash content, which is ultimately controlled by Adobe.
To a large extent, this is no different from Apple's motivations for not approving Google Voice. This is exactly what Google does, they commoditize platforms to turn them all into Google platforms, which is exactly the goal of Google Voice on smartphones.
It's also worth pointing out that Gruber believes Apple's stance will be good for users, a point with which I completely agree:
Quote:
Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. [...]
My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles.
Consider [...] Amazon’s Kindle clients for iPhone OS and Mac OS X. The iPhone OS Kindle app is excellent [...] The Mac Kindle app is a turd [...] The iPhone OS Kindle app is a native iPhone app, written in Cocoa Touch. The Mac Kindle app was produced using the cross-platform Qt toolkit.
We'll see, there are a lot of good apps written using Unity3D. Will those get to stay or will they be removed? If they stay and the policy doesn't flow through to existing apps (i.e. no mass removal of already approved apps - like Apple has done in the past) then maybe it won't be too bad for users except for losing out on any apps developed by talented C# coders who choose not to go the ObjC route.
That's actually a good point, and I'll be interested in seeing how Apple handles existing apps. As far as talented programers in something other than the platform language, that's pretty much how it always is, isn't it? You learn the language of the device you want to develop for, or risk being at a competitive disadvantage.
Quote:
Maybe the abitrary app rejection thing has been overstated but some of the examples are so egregious (Google Voice, banning apps for using certain non profane words, using gestures apple doesn't want others to use, etc....) that the reputation the app approval process has is a well deserved one.
Well, the reputation is certainly well publicized, but given the vast number of apps available I disagree it's well deserved. There have been a handful of high profile apps that appear to have run athwart of either AT&T or Apple or politics or all three. There have been some stupid and arbitrary bans that seem to have been a result of overworked reviewers, and that's been improved. And there are the private API call issues that have actually been pretty consistent and a matter of dire warnings from Apple, so those are really on the dev.
I think if you did a percentage analysis you'd find that the number of truly "arbitrary" app rejections are vanishingly slight, albeit including a very few big guns that got a lot of press.
I like Apple less and less with everything they do like this. What business of theirs is it what tools a developer uses? The app that results runs natively... I REALLY don't like the following:
"The prohibition may also be a roadblock for Appcelerator and its Titanium SDK or the similar PhoneGap, both of which are designed to build native mobile apps using web technologies such as HTML and JavaScript. The clause specifically limits JavaScript for use in web apps, and does not allow it to link against the native Cocoa Touch APIs."
Google and others have done amazing web apps with HTML+JavaScript. Hate on Flash all you want Apple, but why oppose using these cross-platform tools? If you'll let me run it as a webpage, why won't you let me run it as an app that resides on my device so I don't have to be connected to the web to use it? Infuriating. Why not let developers create apps that can either run over the web or locally from a device, on any platform!? That's the future I want to live in, not under Apple's proprietary monopoly.
(Clearly this is aimed at Google's Chrome OS, and their emphasis on web apps.)
Quote:
Originally Posted by ihxo
Do you have any idea what you are talking about?
No, he doesn't. He obviously has never written a line of code. Or if he has I hope I never have to work with him.
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.
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?
What lawsuit? Providing all the necessary tools for free from the point that 3rd part development started absolutely eliminated any possibility of claiming economic damages from anyone coming into the party at any point. If Apple charged an arm and a leg for the dev tools there might be a problem, but that isn't the case.
In other words, the goal of these "meta-platforms", especially Flash, is to achieve developer lock-in themselves and to commoditize actual platforms so that they simply become vehicles for, in Adobe's case, Flash content, which is ultimately controlled by Adobe.
To a large extent, this is no different from Apple's motivations for not approving Google Voice. This is exactly what Google does, they commoditize platforms to turn them all into Google platforms, which is exactly the goal of Google Voice on smartphones.
It's also worth pointing out that Gruber believes Apple's stance will be good for users, a point with which I completely agree:
Yes, it probably is less about pure Apple lock in than Apple preventing others from controlling their platform. Still, I don't see the allowance of Flash, .Net or what have you ports to significantly devalue the overall iPhone platform. There are advantages in performance and features for native apps, but shouldn't those be able to stand on their own? I would hope customers would be discerning enough to be able to pick what apps they like based on other's actual experience with them and there own experience with them rather than what underlying language they can from. If they don't like it, refunds are allowed, and since developers take the hit with Apple's app commission, if being non-native is actually costing them money, that should be a strong incentive on it's own for developers to go native. So I think the situation would be able to sort itself out on it's own. Banning non-native apps likely won't have a significant effect on the platform, but not banning them would likewise probably not have caused a freeze in interest for native apps or good quality apps.
Does anyone realize what would happen if Adobe said, ya know, we are no longer making After Effects for the Mac? TV and commercials would go into a frenzy. Apple should watch out how far they keep pushing Adobes buttons. I would use a little more caution.
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.
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?
See post above. Customers as creatives never get what they want. Apple is all about the consumer now. Jobs is pushing the buttons a little to hard. I wish the US Atty would step in and remove all the raping we as customers get compared to other countries. Contracts no teethering well, unless you jail break of course.
Does anyone realize what would happen if Adobe said, ya know, we are no longer making After Effects for the Mac? TV and commercials would go into a frenzy. Apple should watch out how far they keep pushing Adobes buttons. I would use a little more caution.
Last time I checked, Photoshop's (for instance) installed base was something like 50% Mac. Don't know about the rest of the CS apps, but I'm willing to bet the Mac segment is vastly disproportionate to the Mac's overall market share.
No matter how gnarly Apple gets about the mobile space (and that's all it is, they've done nothing to deprecate Adobe on the desktop), Adobe simply can't afford to mess with their Mac Creative Suite apps. It would be corporate suicide.
This clause insures that developers who build multi-platform apps will create apps that are best-in-class for the iPhone platform - not just hacked Bizarro Java apps.
This insures that iPhone users will get BEST TREATMENT from developers and are not treated like second-class citizens.
How does it? It just mean developers write one set of code for there web version, desktop version, every other mobile version and then a second one for the iPhone.
It only makes it the best for the iPhone is the sales of there app on the iPhone are larger than that of every other device combines. In which case the ported app probably wasn't going to be that bad anyway. If the iPhone isn't outwaying all the others combined, it just means all core development goes into the others and then you try and re-write it for the iPhone as quickly as possible.
What it does definitely mean is anyone who had been writing iPhones in another dev tool which they could do well, now have to use something they can't use so well. Forget any argument on which is actually better, it's all about what the developer can actually use.
Also are Apple really just asking Adobe to put all there effort into the windows versions of their apps and force every creative team to have to start moving to Windows.
So in addition limiting what apps you can install on your Apple devices, now they have decided that how the apps are developed is also their business.
Amen. This is silly and not a good thing since it will also mean that Unity 3D games won't be possible under OS4 anymore. A lot of top-selling titles were made using Unity.
As long as the content has a certain quality, doesn't contain pr0n etc, who cares if its been made with devtool A or B?
btw I'm sick of people bashing Flash in its whole. I think people should bash wrong use of the technology, not the technology itself.
And don't get started on propierty closed-source stuff. The iPhone itself is as closed as it can be.
What is the point of this utterly stupid clause? Why not judge the end product result and be satisfied with that? This is persisting the current technology, killing one route for creativity and competition! I have everything Apple, but feel more and more like i am getting my stuff from some communist state!
Either this is somehow a mistake, or Apple is getting too cocky and going to cause themselves problems. I'm no programmer, but I understand that many programming houses use interpreters to go from pseudo-code to C and C++ already. This has a number of benefits on development cycle and code portability from what I understand.
While people may object to crapware being on the AppStore, as a business owner, I might want to write my own crapware app for internal use. I'm not going to hire a programmer or learn objective-C to do it... as that would (arguably) eliminate the business benefit for it. (Thinking of something like a custom calculator combined with reference documents.) A web app may not cut it, if it needs to be used in environments where internet cannot be relied on.
I can see no way that Apple can legally stand on this requirement, as long as the Adobe apps (and others) output objective-C code and do not try and compile directly. (I can see reasons why Apple wants to requrie developers to use their compiler for thier product, and that should not be an issue.)
Comments
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?
It seems illogical to me that they could believe that banning apps based on toolset used delivers a better experience than banning apps based on something like not meeting performance thresholds or some other measurement that truly would benefit users.
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 suppose anything's possible, but how often do cross platform toolkits produce better than native results? And even if there's the odd standout, is it reasonable to imagine that iPhone users are going to suffer any particular dearth of top-notch apps because of Apple's policy?
I get that there's a kind of "in a perfect world all else being equal" kind of thing here, but the bottom line is that Apple's users won't suffer and the vast majority of iPhone developers won't suffer. Given Apple's self-interest in controlling the platform, it's not hard to see why they figured they could go ahead and do this.
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.
I think the arbitrary app rejection thing has been wildly overstated.
I wish someone with greater knowledge of the whole thing than the article's author would chime in with an explanation.
I am no coder, but it seems to me that if the resultant code is the same then there is no way to tell what the thing was "originally" written in. Conversely, if Apple can tell what language things were "originally written in," then the resultant code is not equivalent and they have every right to argue for it not being used.
It's fairly straightforward. If the language isn't one of the authorized languages it will won't have the applicable Apple Framework calls, and those have signatures that are readily identifiable. Or the compiled code could have an embedded runtime component which would also be identifiable. Or the cross compilers generate code that has a certain fingerprint. Compiled code is actually very traceable and forensically usable in court during licensing/patent/copyright cases. If it's identifiable enough for a set of lawyers and a judge, that makes it pretty straightforward for the applicable Apple engineers.
It seems illogical to me that they could believe that banning apps based on toolset used delivers a better experience than banning apps based on something like not meeting performance thresholds or some other measurement that truly would benefit users.
I imagine the real question, from Apple's perspective, would be whether or not banning a tool set would result in any actual loss for the user. I think the answer to that is an obvious "no."
Beyond that you appear to be just insisting on a kind of pointless platform morality, or something. Are you under the impression that there was some great functionality that will never hit the iPhone because people can't use cross-platform tool kits? Because I've never really heard anyone argue that the point of working cross-platform was that you were likely to end up with better applications than if you used native tools.
And it's not like the platform is hurting for capable devs that are happy to use the native tools, so....
I suppose anything's possible, but how often do cross platform toolkits produce better than native results? And even if there's the odd standout, is it reasonable to imagine that iPhone users are going to suffer any particular dearth of top-notch apps because of Apple's policy?
I get that there's a kind of "in a perfect world all else being equal" kind of thing here, but the bottom line is that Apple's users won't suffer and the vast majority of iPhone developers won't suffer. Given Apple's self-interest in controlling the platform, it's not hard to see why they figured they could go ahead and do this.
I think the arbitrary app rejection thing has been wildly overstated.
We'll see, there are a lot of good apps written using Unity3D. Will those get to stay or will they be removed? If they stay and the policy doesn't flow through to existing apps (i.e. no mass removal of already approved apps - like Apple has done in the past) then maybe it won't be too bad for users except for losing out on any apps developed by talented C# coders who choose not to go the ObjC route.
Maybe the abitrary app rejection thing has been overstated but some of the examples are so egregious (Google Voice, banning apps for using certain non profane words, using gestures apple doesn't want others to use, etc....) that the reputation the app approval process has is a well deserved one.
So in addition limiting what apps you can install on your Apple devices, now they have decided that how the apps are developed is also their business.
I am sorry, this is just plain silly.
I see the mobile market going to same way as the desktop market. Apple will do well, making a nice living off the drones that don't mind their draconian operating practices, meanwhile the bulk of the market will go to other companies that don't want to act as your nanny.
-kpluck
The kind of thing Apple just ruled out has significant security implications. When an app provides a security breach that wouldn't have been there had the correct API usage been implemented, then yes it becomes Apples problem and Apple has every right to control that potential problem vector. Because nobody would buy for a second Apple trying to pass the blame for a security problem to somebody else on a non-jailbroken phone.
You have no idea how your 15 year from now desktop OS looks from a security standpoint. It actually looks a lot like it will be going the way of the iPhone OS / Chrome browser. You won't have a nanny, you will have a self sealing sandbox, and to keep the sand from getting out of the box, or unauthorized sand from getting in there will be a lot less development monkey-business allowed.
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.
I do think this rule change is going to put more developers in the crossfire than just the odd person wanting to port a Flash app.
http://www.appcelerator.com/
For example, Appcelerator Titanium is supposed to allow people with primarily web development skills in Javascript and Ruby to have greater access to iPhone APIs to make native apps, kind of like the Android philosophy, and claims to be used by tens of thousands of developers.
http://www.appcelerant.com/iphone-os...nt-to-you.html
Perhaps not all of those developers are targeting the iPhone, but there is now concern about whether this development tool and people who use it will continue to be supported in iPhone 4.
Similarly as John Gruber mentioned, the Unity Engine used in popular games like Ravensword uses Mono and is at risk. Ravensword had notable graphics and good performance as a 3d RPG when it was released so it's not like not being a pure XCode creation was a huge hinderance.
Even the much talked about Unreal Engine 3 for iPhone uses UnrealScript and a virtual machine for game logic. Interestingly, Apple reportedly worked closely with Epic to get the virtual machine working since the VM would otherwise be banned. Presumably, Apple could make another exception for Epic and UnrealScript. Although, this opens the door to questions on who deserves exceptions.
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.
Well, I think Gruber got a few things right, but...
a) I don't think he actually said anywhere that, "the true motivation is developer lock-in." He did however say:
So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. [...] If that were to happen, there’s no lock-in advantage.
b) I think he comes very close to the "true" motivations here:
Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.
and here:
Flash CS5 and MonoTouch aren’t so much cross-platform as meta-platforms. Adobe’s goal isn’t to help developers write iPhone apps. Adobe’s goal is to encourage developers to write Flash apps that run on the iPhone (and elsewhere) instead of writing iPhone-specific apps. Apple isn’t just ambivalent about Adobe’s goals in this regard — it is in Apple’s direct interest to thwart them.
In other words, the goal of these "meta-platforms", especially Flash, is to achieve developer lock-in themselves and to commoditize actual platforms so that they simply become vehicles for, in Adobe's case, Flash content, which is ultimately controlled by Adobe.
To a large extent, this is no different from Apple's motivations for not approving Google Voice. This is exactly what Google does, they commoditize platforms to turn them all into Google platforms, which is exactly the goal of Google Voice on smartphones.
It's also worth pointing out that Gruber believes Apple's stance will be good for users, a point with which I completely agree:
Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. [...]
My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles.
Consider [...] Amazon’s Kindle clients for iPhone OS and Mac OS X. The iPhone OS Kindle app is excellent [...] The Mac Kindle app is a turd [...] The iPhone OS Kindle app is a native iPhone app, written in Cocoa Touch. The Mac Kindle app was produced using the cross-platform Qt toolkit.
We'll see, there are a lot of good apps written using Unity3D. Will those get to stay or will they be removed? If they stay and the policy doesn't flow through to existing apps (i.e. no mass removal of already approved apps - like Apple has done in the past) then maybe it won't be too bad for users except for losing out on any apps developed by talented C# coders who choose not to go the ObjC route.
That's actually a good point, and I'll be interested in seeing how Apple handles existing apps. As far as talented programers in something other than the platform language, that's pretty much how it always is, isn't it? You learn the language of the device you want to develop for, or risk being at a competitive disadvantage.
Maybe the abitrary app rejection thing has been overstated but some of the examples are so egregious (Google Voice, banning apps for using certain non profane words, using gestures apple doesn't want others to use, etc....) that the reputation the app approval process has is a well deserved one.
Well, the reputation is certainly well publicized, but given the vast number of apps available I disagree it's well deserved. There have been a handful of high profile apps that appear to have run athwart of either AT&T or Apple or politics or all three. There have been some stupid and arbitrary bans that seem to have been a result of overworked reviewers, and that's been improved. And there are the private API call issues that have actually been pretty consistent and a matter of dire warnings from Apple, so those are really on the dev.
I think if you did a percentage analysis you'd find that the number of truly "arbitrary" app rejections are vanishingly slight, albeit including a very few big guns that got a lot of press.
"The prohibition may also be a roadblock for Appcelerator and its Titanium SDK or the similar PhoneGap, both of which are designed to build native mobile apps using web technologies such as HTML and JavaScript. The clause specifically limits JavaScript for use in web apps, and does not allow it to link against the native Cocoa Touch APIs."
Google and others have done amazing web apps with HTML+JavaScript. Hate on Flash all you want Apple, but why oppose using these cross-platform tools? If you'll let me run it as a webpage, why won't you let me run it as an app that resides on my device so I don't have to be connected to the web to use it? Infuriating. Why not let developers create apps that can either run over the web or locally from a device, on any platform!? That's the future I want to live in, not under Apple's proprietary monopoly.
(Clearly this is aimed at Google's Chrome OS, and their emphasis on web apps.)
Do you have any idea what you are talking about?
No, he doesn't. He obviously has never written a line of code. Or if he has I hope I never have to work with him.
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.
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?
What lawsuit? Providing all the necessary tools for free from the point that 3rd part development started absolutely eliminated any possibility of claiming economic damages from anyone coming into the party at any point. If Apple charged an arm and a leg for the dev tools there might be a problem, but that isn't the case.
In other words, the goal of these "meta-platforms", especially Flash, is to achieve developer lock-in themselves and to commoditize actual platforms so that they simply become vehicles for, in Adobe's case, Flash content, which is ultimately controlled by Adobe.
To a large extent, this is no different from Apple's motivations for not approving Google Voice. This is exactly what Google does, they commoditize platforms to turn them all into Google platforms, which is exactly the goal of Google Voice on smartphones.
It's also worth pointing out that Gruber believes Apple's stance will be good for users, a point with which I completely agree:
Yes, it probably is less about pure Apple lock in than Apple preventing others from controlling their platform. Still, I don't see the allowance of Flash, .Net or what have you ports to significantly devalue the overall iPhone platform. There are advantages in performance and features for native apps, but shouldn't those be able to stand on their own? I would hope customers would be discerning enough to be able to pick what apps they like based on other's actual experience with them and there own experience with them rather than what underlying language they can from. If they don't like it, refunds are allowed, and since developers take the hit with Apple's app commission, if being non-native is actually costing them money, that should be a strong incentive on it's own for developers to go native. So I think the situation would be able to sort itself out on it's own. Banning non-native apps likely won't have a significant effect on the platform, but not banning them would likewise probably not have caused a freeze in interest for native apps or good quality apps.
Take that Flash, Java, Silverlight.
Apple has done a great job of keeping crud off it's mobile devices.
Once again, a smart move by Apple.
Does anyone realize what would happen if Adobe said, ya know, we are no longer making After Effects for the Mac? TV and commercials would go into a frenzy. Apple should watch out how far they keep pushing Adobes buttons. I would use a little more caution.
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.
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?
See post above. Customers as creatives never get what they want. Apple is all about the consumer now. Jobs is pushing the buttons a little to hard. I wish the US Atty would step in and remove all the raping we as customers get compared to other countries. Contracts no teethering well, unless you jail break of course.
Does anyone realize what would happen if Adobe said, ya know, we are no longer making After Effects for the Mac? TV and commercials would go into a frenzy. Apple should watch out how far they keep pushing Adobes buttons. I would use a little more caution.
Last time I checked, Photoshop's (for instance) installed base was something like 50% Mac. Don't know about the rest of the CS apps, but I'm willing to bet the Mac segment is vastly disproportionate to the Mac's overall market share.
No matter how gnarly Apple gets about the mobile space (and that's all it is, they've done nothing to deprecate Adobe on the desktop), Adobe simply can't afford to mess with their Mac Creative Suite apps. It would be corporate suicide.
This clause insures that developers who build multi-platform apps will create apps that are best-in-class for the iPhone platform - not just hacked Bizarro Java apps.
This insures that iPhone users will get BEST TREATMENT from developers and are not treated like second-class citizens.
How does it? It just mean developers write one set of code for there web version, desktop version, every other mobile version and then a second one for the iPhone.
It only makes it the best for the iPhone is the sales of there app on the iPhone are larger than that of every other device combines. In which case the ported app probably wasn't going to be that bad anyway. If the iPhone isn't outwaying all the others combined, it just means all core development goes into the others and then you try and re-write it for the iPhone as quickly as possible.
What it does definitely mean is anyone who had been writing iPhones in another dev tool which they could do well, now have to use something they can't use so well. Forget any argument on which is actually better, it's all about what the developer can actually use.
Also are Apple really just asking Adobe to put all there effort into the windows versions of their apps and force every creative team to have to start moving to Windows.
So in addition limiting what apps you can install on your Apple devices, now they have decided that how the apps are developed is also their business.
Amen. This is silly and not a good thing since it will also mean that Unity 3D games won't be possible under OS4 anymore. A lot of top-selling titles were made using Unity.
As long as the content has a certain quality, doesn't contain pr0n etc, who cares if its been made with devtool A or B?
btw I'm sick of people bashing Flash in its whole. I think people should bash wrong use of the technology, not the technology itself.
And don't get started on propierty closed-source stuff. The iPhone itself is as closed as it can be.
Closed doesn't mean "bad" perse.
While people may object to crapware being on the AppStore, as a business owner, I might want to write my own crapware app for internal use. I'm not going to hire a programmer or learn objective-C to do it... as that would (arguably) eliminate the business benefit for it. (Thinking of something like a custom calculator combined with reference documents.) A web app may not cut it, if it needs to be used in environments where internet cannot be relied on.
I can see no way that Apple can legally stand on this requirement, as long as the Adobe apps (and others) output objective-C code and do not try and compile directly. (I can see reasons why Apple wants to requrie developers to use their compiler for thier product, and that should not be an issue.)