Another problem which is kind of an "Elephant in the room" no one is speaking about is
Perhaps no one is speaking about it because it's an irrelevant, bigoted point. That's just my personal opinion mind you.
I say bigoted as you seem to have a recuringpreoccupation with trying to cast all Flash developers as some sort of lower form of developer.
Quote:
Originally Posted by Prof. Peabody
If you are using Flash, it doesn't mean you are dumber or less capable than someone who knows C, C++, etc., but it doesn't make you a "developer" either IMO.
So Flash developers, and I believe there are 70 or so thousand of them registered on Linkedin who work for Bluechip companies to startup's are not dumber or less capable than someone who knows C, C++, but they're not "developers".
That's a very kind concession for you to make Prof. professor? But I think the label of "developer" is derived from ones employer generally, another popular one is "Flash software engineer".
A final reason, that many have suggested (including me), is that it does not make good business sense for Apple to support development tools which allow developers to create a single, one-size-fits-all, app that will run on competitors ' platforms, rather than exploit the specific advantages of Apple's platforms.
That's a pure business decision. As a user, customer, and stockholder... I support it!
.
An app can be cross platform and also take advantage of iPhone specific features. A developer can write the core of the app cross-platform using C/C++ (or even use an off-the-shelf tool such as Unity3D) but specialize it to take advantage of a specific platform.
Doing this lowers the development cost, and hence lowers the price point at which the app can be offered on the Apple devices.
It's hard to say though how much of the Universal Binary frameworks are actually the result of installing the Developer Tools or if they are there as standard.
It isn't hard to say. All the Frameworks that were present in 10.5 and earlier are Universal (ie include PPC code) in a standard install.
Quote:
Virtual PC however did not need Intel code in Mac OS X or 9 to run.
Virtual PC without Intel code (eg a Windows OS) is useless. It runs nothing.
Quote:
It worked best on G4 and G5 processors because both of those processors had some Intel code in them but it also worked on G3s which didn't.
Nonsense.
Quote:
However, Virtual PC did not need to have any Intel code in the OS at all to work. The virtual machine had Intel code in the sense that Windows is only Intel but it did not need anything in the Mac OS to be able to translate that Intel code to PPC and that's what I'm getting at with Rosetta not needing PPC code in Snow Leopard to translate it into Intel code.
Maybe that is what you mean, but that is irrelevant. Translating only the app code, without the supporting libraries, gets you nothing. To do it your way would mean trying to run Intel code and PPC code in the same memory space, against the same data structures. Theoretically might be possible, but it would be slower than molasses, as some 'glue' code would have to be run before/after every single CPU instruction in order to keep a consistent view of memory(and it would no longer be able to run on multiple cores). The Rosetta design requires PPC code + PPC libraries, and only has to run glue when you make a syscall into the Intel operating system.
Perhaps no one is speaking about it because it's an irrelevant, bigoted point. That's just my personal opinion mind you.
I say bigoted as you seem to have a recuringpreoccupation with trying to cast all Flash developers as some sort of lower form of developer.
So Flash developers, and I believe there are 70 or so thousand of them registered on Linkedin who work for Bluechip companies to startup's are not dumber or less capable than someone who knows C, C++, but they're not "developers".
That's a very kind concession for you to make Prof. professor? But I think the label of "developer" is derived from ones employer generally, another popular one is "Flash software engineer".
I didn't say anything that required you start name calling so I'm reporting you for that.
If you read what I said more carefully, you'd see that I was putting the "not a developer" remark strictly in the context of this debate also. Someone who develops scripts for TV shows is a "developer," someone who processes old-timey paper prints is a "developer" and someone who develops flash solutions is also a "developer" in the wider sense of the word. There are obviously lots of "developers" out there in that sense.
What I said was that in terms of developing apps for a software platform, (this context), someone who scripts some rectangles and puts it on a time line is not a "developer" in the same sense as a C++ programmer using XCode.
An app can be cross platform and also take advantage of iPhone specific features. A developer can write the core of the app cross-platform using C/C++ (or even use an off-the-shelf tool such as Unity3D) but specialize it to take advantage of a specific platform.
Doing this lowers the development cost, and hence lowers the price point at which the app can be offered on the Apple devices.
I agree with your points. However, the statement (my emphasis):
"An app can be cross platform and [can] also take advantage of iPhone specific features"
does not necessarily mean it will also take advantage of iPhone specific features.
With the pressures of time, schedule and competition the easiest path is to design for the lowest common denominator. As a developer, you have an (easier to develop and maintain) app that runs on lots of platforms, devices and OS versions... but doesn't take particular advantage of any one.
Apple perceives that with their devices, lead, and infrastructure (iTunes, App store, 85 million install base, existing app portfolio) that they have a significant advantage over their competition. If they overtly or tacitly support LCD cross-platform development of apps they could dissipate their advantage.
Their move may be heavy-handed and may result in developers abandoning the platform... we'll see.
If so, Apple could always say: "We've listened to the developers, and found a way..."
But, by the same token, Adobe, et al, could say: "We've listened to the developers, and found a way..."
Part of being successful is "knowing when to hold'em, and knowing when to fold'em"
Battery life on a Nexus One is pretty similar to a 3GS, and miles better than my iPhone 3G.
You can achieve good results simply through good software engineering you know. Have you considered the possibility that Android is just a more efficient, better engineered OS than the iPhone OS?
I'm not trying to suggest that iPhone OS is more efficient than Android, but there is more to the equation than just the software power optimization routines and you know it. The Nexus One starts with a higher capacity battery and certainly more power efficient hardware thanks to the 1.5 years it spotted the iPhone 3G. We'll have to see what the next iteration of the iPhone brings to the table in terms of battery life with what will probably be a variation of the A4 and likely more efficient 3G radio hardware. If it wins the battery life and performance crown, does that make iPhone OS more efficient? Hardly... apples to apples comparisons are hard to come by in this industry.
I'm not trying to suggest that iPhone OS is more efficient than Android, but there is more to the equation than just the software power optimization routines and you know it. The Nexus One starts with a higher capacity battery and certainly more power efficient hardware thanks to the 1.5 years it spotted the iPhone 3G. We'll have to see what the next iteration of the iPhone brings to the table in terms of battery life with what will probably be a variation of the A4 and likely more efficient 3G radio hardware. If it wins the battery life and performance crown, does that make iPhone OS more efficient? Hardly... apples to apples comparisons are hard to come by in this industry.
Not sure exactly what you mean, but I assume you mean that the A4 is a SoC containing many of the same components also found in the 3GS. This is true. However, it would not be accurate to say the hardware is identical. Though it is likely (proven?) that the A4 uses the same ARM architecture for the CPU (the Cortex A8), the architecture itself it is just a reference design. Through Apple's acquisitions of IC know-how (such as PA Semi) they have likely made some improvements in power efficiency, etc.
I don't know how well the tests on the web reflect real-world performance, but clock-for-clock it appears the A4 performs rather well compared to the Snapdragon equivalent found in the Nexus One based on the samplings I have seen.
I frankly don't care that much... my phone is already plenty fast for what I do. I just want better battery life without having to carry spares.
Wrong on so many levels. This was true about garbage collection in 1995. A modern generational garbage collector allocates memory about 20x faster than malloc() does (all an allocation requires is incrementing a pointer into the heap; it's almost as fast as stack allocation).
And a modern garbage collector is more cache efficient because you're not constantly invalidating cache lines to retain/release reference counts. The total time spent on garbage collection is almost always significantly less than is spent on reference counting. Modern collectors are incremental too, so they never scan the entire heap in one go. Cocoa uses autorelease pools to defer object deallocation, which is WAY slower than garbage collection.
Furthermore, if you use a modern, strictly typed language, like any statically compiled JVM/CLR language, the compiler actually eliminates many object allocations all together using escape analysis. This makes the code run even faster than C++ stack allocated structs since the compiler can see several layers of the call stack and eliminate copying that C++ might naively do (and it's significantly faster than Objective-C's heavyweight objects). And since these languages don't use dynamic dispatch like Objective-C does, you get method inlining which further increases execution speed (Objective-C compilers can't inline anything because of the calling conventions and because classes are always open for extension).
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime. But you can natively compile Java (or Scala or C#) without the platform so you're just running native code linked with Apple's native libraries. And it will run faster and with less memory use than equivalent Objective-C code. And it will be more stable and more maintainable.
There's no reason that modern, static languages should be prohibited. Progress just happens to be collateral damage in Apple's war with Adobe. And Apple's users will suffer because of it.
I genuinely want to thank you for the thoughtful post. I admit that I am one of those people that for a long time believed the fallacy that garbage collection means slow.
You seem very knowledgeable about the subject so I thought I would ask you a few questions relevant to the topic at hand, bearing in mind that my knowledge of GC and operating system concepts is somewhat limited.
I am under the impression that using garbage collection in the manner described above is generally only much more efficient than manual memory allocation in the situation where your available memory greatly exceeds the working set of your application. Due to the limited resources (I know, such a laugh... who would have thought 20 years ago that we would find ourselves limited with 256MB of RAM) available on current phone platforms, do you see this as a potential stumbling block when there are multiple applications "resident" in memory? Correct me if I'm wrong, but I thought that GCs typically did an allocation for the memory pool at the beginning of execution, which would increase the required memory of each program. If this is the case, then wouldn't multiple apps each additionally running their own memory resident RTE (due to sandboxing) with garbage collection occupy a significantly larger memory footprint than otherwise, which in turn would lead to poorer multitasking performance due to more required swaps to and from the flash memory? I would think that if common executables were available on the iPhone that two apps sharing an RTE would be able to use the same text pages for it and reduce swapping, but I don't believe that would work here. Even an RTE that exists as a dynamically linked library would cut down on the overhead.
With regards to the larger picture, I think Apple is certainly in the wrong if they intend to derail any project that uses one of the non-chosen languages just for the sake of doing so (and as many have stated, in many circumstances I don't even see HOW they could). If a developer has built a tool that takes C# and performs a translation into OBJC/C++/C that can be then compiled into machine code and run without the need for another RTE embedded in the package or access to private APIs, then more power to them. They have opened up the iPhone community to more developers which can be a good thing.
However, if Apple (like I want to believe) intends to just stop the packaging of RTEs like Flash, JVM, CLR, or whatever Ruby/Python/Perl/Lua RTE just became the flavor of the month for iPhone app development into app bundles with tools that cater to some of the lowest common denominator developers, then I don't see a significant problem there and I don't think that fundamentally the rules are really any different. I don't think we need another ten thousand flash games each containing the flash runtime embedded in the app.
Honestly don't know that this solution is the best or even good at all. We'll find out as developers vote with their future releases. I'm not leaving the platform yet, but then I don't mind using the three languages they advocate.
I'm a developer and this is not entirely true. If the OS can't put your process to sleep properly only your process gets harmed. Once it gets awaken its processing could have been jeopardized. There could be logic problems with other processes if your process shares resources with them but that is an issue with the logic, algorithm in your program and not with the process per se or the way it was coded with whichever tools.
Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.
I can't comment on the validity of the restrictions multitasking could place on the coding tools or languages used. Regardless, you're not a developer I ever want a product from. It's disturbing that you completely ignore the user in your arguments. Apparently the only criteria for building apps is the technical ability to do so, without regard for user experience. Apple would rightly reject any app you submitted to the App Store if developed in the way you describe because it would be terrible for users. There should be consistency in the way applications respond to expected features. If your app cannot be put to sleep properly and awakened using the multi-tasking services Apple provides, then it will be confusing and frustrating to use.
So, when your app crashes or destroys data because "its processing could have been jeopardized", is that just the dumb user's fault for not knowing better than to try to use your app in a multitasking fashion?
Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?
I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
I have exactly the same feeling...this is just ugly business move from Jobs that has no technical merit.
I also find funny how many people rant at flash that it is just dummy vehicle for serving ads and now they applause new OS 4 version with iAd, that does exactly the same thing.
By adding multitasking, iPhone closed a gap between itself and Android, but there are still some important steps for it to be done, such as inter-application communication or better granularity. It is safe to assume that before the OS 4 is officially out, there will be new version of Android that will broaden the gap once again.
However, if Apple (like I want to believe) intends to just stop the packaging of RTEs like Flash, JVM, CLR, or whatever Ruby/Python/Perl/Lua RTE just became the flavor of the month for iPhone app development into app bundles with tools that cater to some of the lowest common denominator developers, then I don't see a significant problem there and I don't think that fundamentally the rules are really any different. I don't think we need another ten thousand flash games each containing the flash runtime embedded in the app.
The language they used in the updated license says otherwise. It is even ridiculous, they have little to no chance to figure out apps written in whatever language if there is no RTE bundled - hope there will soon be some sort of Flash to iPhone convertor that can't be detected by the Apple censors.
Quote:
Originally Posted by sexualintellectual
We'll find out as developers vote with their future releases. I'm not leaving the platform yet, but then I don't mind using the three languages they advocate.
It will be interesting to see if there are any really sophisticated apps developed for the iPad, requiring substantial investment into development. The threat of your application being rejected for no real reason and thus flushing millions of dollars invested into development might be seen as major obstacle by developers - I think recent jerk moves of Apple finally opened some eyes through the industry.
No it's not. Android has true multi-tasking. (ie. the ability to run any app in the background continuously, not just an Apple approved small sub set of functions)
Hey, learn the facts first. The application might get the signal to stop as soon as it is removed from the front on Android and won't get back to running until specifically started again by the user. Long running processes needs to be implemented as services, which is equal to the iPhone implementation (in certain regards, it is just better). Jobs is lying again when he said the multitasking implementation is best on iPhone, it is not.
The language they used in the updated license says otherwise. It is even ridiculous, they have little to no chance to figure out apps written in whatever language if there is no RTE bundled - hope there will soon be some sort of Flash to iPhone convertor that can't be detected by the Apple censors.
You obviously don't know the first thing about the subject.
I'm really waiting for some proofs of what's in this article.
OS are doing multitasking without asking the app for a while. MacOSX (and probably the the iPhone OS) is able to schedule, kill, pause every application without a single line of extra code in the executed application. I mean, Windows does that with old DOS games !
So the OS is definitely able to at least pause every applications. For the other forms (Music in background ...) the app of course has to use Apple's API, but only for that.
And by the way, if for some reasons (I'm thinking stopping the applications for example), the OS really needs the app to use Apple's libraries even to pause applications, then why does it just does not support it ? I mean, switching applications would kill the game and that's all.
This last solution is however not really satisfying for the end user who will have apps which can work with multitasking and not others.
So IF the OS need some APIs to support multitasking and IF Apple wants all the App to support multitasking (which will clean the App store pretty much !), Apple can ask third party dev. tools developers to updated their products. Unity3D's developers can do that, even the "lazy" Adobe can and will do that.
So definitely, there is NO technical justifications for such stupid moves, is business.
I'm however curious to see how they will apply it: will they only refuse some random apps and use this clause as a reason ?
Comments
Another problem which is kind of an "Elephant in the room" no one is speaking about is
Perhaps no one is speaking about it because it's an irrelevant, bigoted point. That's just my personal opinion mind you.
I say bigoted as you seem to have a recuring preoccupation with trying to cast all Flash developers as some sort of lower form of developer.
If you are using Flash, it doesn't mean you are dumber or less capable than someone who knows C, C++, etc., but it doesn't make you a "developer" either IMO.
So Flash developers, and I believe there are 70 or so thousand of them registered on Linkedin who work for Bluechip companies to startup's are not dumber or less capable than someone who knows C, C++, but they're not "developers".
That's a very kind concession for you to make Prof. professor? But I think the label of "developer" is derived from ones employer generally, another popular one is "Flash software engineer".
A final reason, that many have suggested (including me), is that it does not make good business sense for Apple to support development tools which allow developers to create a single, one-size-fits-all, app that will run on competitors ' platforms, rather than exploit the specific advantages of Apple's platforms.
That's a pure business decision. As a user, customer, and stockholder... I support it!
.
An app can be cross platform and also take advantage of iPhone specific features. A developer can write the core of the app cross-platform using C/C++ (or even use an off-the-shelf tool such as Unity3D) but specialize it to take advantage of a specific platform.
Doing this lowers the development cost, and hence lowers the price point at which the app can be offered on the Apple devices.
It's hard to say though how much of the Universal Binary frameworks are actually the result of installing the Developer Tools or if they are there as standard.
It isn't hard to say. All the Frameworks that were present in 10.5 and earlier are Universal (ie include PPC code) in a standard install.
Virtual PC however did not need Intel code in Mac OS X or 9 to run.
Virtual PC without Intel code (eg a Windows OS) is useless. It runs nothing.
It worked best on G4 and G5 processors because both of those processors had some Intel code in them but it also worked on G3s which didn't.
Nonsense.
However, Virtual PC did not need to have any Intel code in the OS at all to work. The virtual machine had Intel code in the sense that Windows is only Intel but it did not need anything in the Mac OS to be able to translate that Intel code to PPC and that's what I'm getting at with Rosetta not needing PPC code in Snow Leopard to translate it into Intel code.
Maybe that is what you mean, but that is irrelevant. Translating only the app code, without the supporting libraries, gets you nothing. To do it your way would mean trying to run Intel code and PPC code in the same memory space, against the same data structures. Theoretically might be possible, but it would be slower than molasses, as some 'glue' code would have to be run before/after every single CPU instruction in order to keep a consistent view of memory(and it would no longer be able to run on multiple cores). The Rosetta design requires PPC code + PPC libraries, and only has to run glue when you make a syscall into the Intel operating system.
Perhaps no one is speaking about it because it's an irrelevant, bigoted point. That's just my personal opinion mind you.
I say bigoted as you seem to have a recuring preoccupation with trying to cast all Flash developers as some sort of lower form of developer.
So Flash developers, and I believe there are 70 or so thousand of them registered on Linkedin who work for Bluechip companies to startup's are not dumber or less capable than someone who knows C, C++, but they're not "developers".
That's a very kind concession for you to make Prof. professor? But I think the label of "developer" is derived from ones employer generally, another popular one is "Flash software engineer".
I didn't say anything that required you start name calling so I'm reporting you for that.
If you read what I said more carefully, you'd see that I was putting the "not a developer" remark strictly in the context of this debate also. Someone who develops scripts for TV shows is a "developer," someone who processes old-timey paper prints is a "developer" and someone who develops flash solutions is also a "developer" in the wider sense of the word. There are obviously lots of "developers" out there in that sense.
What I said was that in terms of developing apps for a software platform, (this context), someone who scripts some rectangles and puts it on a time line is not a "developer" in the same sense as a C++ programmer using XCode.
You are more like a "scripter." It's a fact jack.
Android, continuously eating up limited power reserves and wasting CPU cycles on a resource limited mobile platform.
Is any Android mobile device permanently hooked up to the Hoover Dam?
Nop, multitasking on Ansdroid is like on iPhone 4.0, applications in background doesn't eatr CPU cycles
An app can be cross platform and also take advantage of iPhone specific features. A developer can write the core of the app cross-platform using C/C++ (or even use an off-the-shelf tool such as Unity3D) but specialize it to take advantage of a specific platform.
Doing this lowers the development cost, and hence lowers the price point at which the app can be offered on the Apple devices.
I agree with your points. However, the statement (my emphasis):
"An app can be cross platform and [can] also take advantage of iPhone specific features"
does not necessarily mean it will also take advantage of iPhone specific features.
With the pressures of time, schedule and competition the easiest path is to design for the lowest common denominator. As a developer, you have an (easier to develop and maintain) app that runs on lots of platforms, devices and OS versions... but doesn't take particular advantage of any one.
Apple perceives that with their devices, lead, and infrastructure (iTunes, App store, 85 million install base, existing app portfolio) that they have a significant advantage over their competition. If they overtly or tacitly support LCD cross-platform development of apps they could dissipate their advantage.
Their move may be heavy-handed and may result in developers abandoning the platform... we'll see.
If so, Apple could always say: "We've listened to the developers, and found a way..."
But, by the same token, Adobe, et al, could say: "We've listened to the developers, and found a way..."
Part of being successful is "knowing when to hold'em, and knowing when to fold'em"
.
Battery life on a Nexus One is pretty similar to a 3GS, and miles better than my iPhone 3G.
You can achieve good results simply through good software engineering you know. Have you considered the possibility that Android is just a more efficient, better engineered OS than the iPhone OS?
I'm not trying to suggest that iPhone OS is more efficient than Android, but there is more to the equation than just the software power optimization routines and you know it. The Nexus One starts with a higher capacity battery and certainly more power efficient hardware thanks to the 1.5 years it spotted the iPhone 3G. We'll have to see what the next iteration of the iPhone brings to the table in terms of battery life with what will probably be a variation of the A4 and likely more efficient 3G radio hardware. If it wins the battery life and performance crown, does that make iPhone OS more efficient? Hardly... apples to apples comparisons are hard to come by in this industry.
I'm not trying to suggest that iPhone OS is more efficient than Android, but there is more to the equation than just the software power optimization routines and you know it. The Nexus One starts with a higher capacity battery and certainly more power efficient hardware thanks to the 1.5 years it spotted the iPhone 3G. We'll have to see what the next iteration of the iPhone brings to the table in terms of battery life with what will probably be a variation of the A4 and likely more efficient 3G radio hardware. If it wins the battery life and performance crown, does that make iPhone OS more efficient? Hardly... apples to apples comparisons are hard to come by in this industry.
But an A4 is 3GS hardware capped, isn't?
But an A4 is 3GS hardware capped, isn't?
Not sure exactly what you mean, but I assume you mean that the A4 is a SoC containing many of the same components also found in the 3GS. This is true. However, it would not be accurate to say the hardware is identical. Though it is likely (proven?) that the A4 uses the same ARM architecture for the CPU (the Cortex A8), the architecture itself it is just a reference design. Through Apple's acquisitions of IC know-how (such as PA Semi) they have likely made some improvements in power efficiency, etc.
I don't know how well the tests on the web reflect real-world performance, but clock-for-clock it appears the A4 performs rather well compared to the Snapdragon equivalent found in the Nexus One based on the samplings I have seen.
I frankly don't care that much... my phone is already plenty fast for what I do. I just want better battery life without having to carry spares.
crApp?
Mr. Mainframe fancies himself as a witty wonk.
I frankly don't care that much... my phone is already plenty fast for what I do. I just want better battery life without having to carry spares.
I don't care either
Wrong on so many levels. This was true about garbage collection in 1995. A modern generational garbage collector allocates memory about 20x faster than malloc() does (all an allocation requires is incrementing a pointer into the heap; it's almost as fast as stack allocation).
And a modern garbage collector is more cache efficient because you're not constantly invalidating cache lines to retain/release reference counts. The total time spent on garbage collection is almost always significantly less than is spent on reference counting. Modern collectors are incremental too, so they never scan the entire heap in one go. Cocoa uses autorelease pools to defer object deallocation, which is WAY slower than garbage collection.
Furthermore, if you use a modern, strictly typed language, like any statically compiled JVM/CLR language, the compiler actually eliminates many object allocations all together using escape analysis. This makes the code run even faster than C++ stack allocated structs since the compiler can see several layers of the call stack and eliminate copying that C++ might naively do (and it's significantly faster than Objective-C's heavyweight objects). And since these languages don't use dynamic dispatch like Objective-C does, you get method inlining which further increases execution speed (Objective-C compilers can't inline anything because of the calling conventions and because classes are always open for extension).
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime. But you can natively compile Java (or Scala or C#) without the platform so you're just running native code linked with Apple's native libraries. And it will run faster and with less memory use than equivalent Objective-C code. And it will be more stable and more maintainable.
There's no reason that modern, static languages should be prohibited. Progress just happens to be collateral damage in Apple's war with Adobe. And Apple's users will suffer because of it.
I genuinely want to thank you for the thoughtful post. I admit that I am one of those people that for a long time believed the fallacy that garbage collection means slow.
You seem very knowledgeable about the subject so I thought I would ask you a few questions relevant to the topic at hand, bearing in mind that my knowledge of GC and operating system concepts is somewhat limited.
I am under the impression that using garbage collection in the manner described above is generally only much more efficient than manual memory allocation in the situation where your available memory greatly exceeds the working set of your application. Due to the limited resources (I know, such a laugh... who would have thought 20 years ago that we would find ourselves limited with 256MB of RAM) available on current phone platforms, do you see this as a potential stumbling block when there are multiple applications "resident" in memory? Correct me if I'm wrong, but I thought that GCs typically did an allocation for the memory pool at the beginning of execution, which would increase the required memory of each program. If this is the case, then wouldn't multiple apps each additionally running their own memory resident RTE (due to sandboxing) with garbage collection occupy a significantly larger memory footprint than otherwise, which in turn would lead to poorer multitasking performance due to more required swaps to and from the flash memory? I would think that if common executables were available on the iPhone that two apps sharing an RTE would be able to use the same text pages for it and reduce swapping, but I don't believe that would work here. Even an RTE that exists as a dynamically linked library would cut down on the overhead.
With regards to the larger picture, I think Apple is certainly in the wrong if they intend to derail any project that uses one of the non-chosen languages just for the sake of doing so (and as many have stated, in many circumstances I don't even see HOW they could). If a developer has built a tool that takes C# and performs a translation into OBJC/C++/C that can be then compiled into machine code and run without the need for another RTE embedded in the package or access to private APIs, then more power to them. They have opened up the iPhone community to more developers which can be a good thing.
However, if Apple (like I want to believe) intends to just stop the packaging of RTEs like Flash, JVM, CLR, or whatever Ruby/Python/Perl/Lua RTE just became the flavor of the month for iPhone app development into app bundles with tools that cater to some of the lowest common denominator developers, then I don't see a significant problem there and I don't think that fundamentally the rules are really any different. I don't think we need another ten thousand flash games each containing the flash runtime embedded in the app.
Honestly don't know that this solution is the best or even good at all. We'll find out as developers vote with their future releases. I'm not leaving the platform yet, but then I don't mind using the three languages they advocate.
I'm a developer and this is not entirely true. If the OS can't put your process to sleep properly only your process gets harmed. Once it gets awaken its processing could have been jeopardized. There could be logic problems with other processes if your process shares resources with them but that is an issue with the logic, algorithm in your program and not with the process per se or the way it was coded with whichever tools.
Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.
I can't comment on the validity of the restrictions multitasking could place on the coding tools or languages used. Regardless, you're not a developer I ever want a product from. It's disturbing that you completely ignore the user in your arguments. Apparently the only criteria for building apps is the technical ability to do so, without regard for user experience. Apple would rightly reject any app you submitted to the App Store if developed in the way you describe because it would be terrible for users. There should be consistency in the way applications respond to expected features. If your app cannot be put to sleep properly and awakened using the multi-tasking services Apple provides, then it will be confusing and frustrating to use.
So, when your app crashes or destroys data because "its processing could have been jeopardized", is that just the dumb user's fault for not knowing better than to try to use your app in a multitasking fashion?
Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?
I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
I have exactly the same feeling...this is just ugly business move from Jobs that has no technical merit.
I also find funny how many people rant at flash that it is just dummy vehicle for serving ads and now they applause new OS 4 version with iAd, that does exactly the same thing.
By adding multitasking, iPhone closed a gap between itself and Android, but there are still some important steps for it to be done, such as inter-application communication or better granularity. It is safe to assume that before the OS 4 is officially out, there will be new version of Android that will broaden the gap once again.
However, if Apple (like I want to believe) intends to just stop the packaging of RTEs like Flash, JVM, CLR, or whatever Ruby/Python/Perl/Lua RTE just became the flavor of the month for iPhone app development into app bundles with tools that cater to some of the lowest common denominator developers, then I don't see a significant problem there and I don't think that fundamentally the rules are really any different. I don't think we need another ten thousand flash games each containing the flash runtime embedded in the app.
The language they used in the updated license says otherwise. It is even ridiculous, they have little to no chance to figure out apps written in whatever language if there is no RTE bundled - hope there will soon be some sort of Flash to iPhone convertor that can't be detected by the Apple censors.
We'll find out as developers vote with their future releases. I'm not leaving the platform yet, but then I don't mind using the three languages they advocate.
It will be interesting to see if there are any really sophisticated apps developed for the iPad, requiring substantial investment into development. The threat of your application being rejected for no real reason and thus flushing millions of dollars invested into development might be seen as major obstacle by developers - I think recent jerk moves of Apple finally opened some eyes through the industry.
No it's not. Android has true multi-tasking. (ie. the ability to run any app in the background continuously, not just an Apple approved small sub set of functions)
Hey, learn the facts first. The application might get the signal to stop as soon as it is removed from the front on Android and won't get back to running until specifically started again by the user. Long running processes needs to be implemented as services, which is equal to the iPhone implementation (in certain regards, it is just better). Jobs is lying again when he said the multitasking implementation is best on iPhone, it is not.
The language they used in the updated license says otherwise. It is even ridiculous, they have little to no chance to figure out apps written in whatever language if there is no RTE bundled - hope there will soon be some sort of Flash to iPhone convertor that can't be detected by the Apple censors.
You obviously don't know the first thing about the subject.
OS are doing multitasking without asking the app for a while. MacOSX (and probably the the iPhone OS) is able to schedule, kill, pause every application without a single line of extra code in the executed application. I mean, Windows does that with old DOS games !
So the OS is definitely able to at least pause every applications. For the other forms (Music in background ...) the app of course has to use Apple's API, but only for that.
And by the way, if for some reasons (I'm thinking stopping the applications for example), the OS really needs the app to use Apple's libraries even to pause applications, then why does it just does not support it ? I mean, switching applications would kill the game and that's all.
This last solution is however not really satisfying for the end user who will have apps which can work with multitasking and not others.
So IF the OS need some APIs to support multitasking and IF Apple wants all the App to support multitasking (which will clean the App store pretty much !), Apple can ask third party dev. tools developers to updated their products. Unity3D's developers can do that, even the "lazy" Adobe can and will do that.
So definitely, there is NO technical justifications for such stupid moves, is business.
I'm however curious to see how they will apply it: will they only refuse some random apps and use this clause as a reason ?