Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.
It's a business decision, not a technical one.
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?
because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
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.
This argument about why all languages except C/Objective-C/C++ are prohibited doesn't hold up at all. All developers submit to the App Store is a binary--no source code at all. So if Apple is analyzing the program some how, they are analyzing the binary. And any natively compiled language would look the same to such a tool.
Remember, Apple isn't just banning interpreted code anymore, they're banning statically compiled code just because it comes from a different source language. This targets way more than just Flash, including hundreds of decent apps already in the App Store. Just because a different programming language is used doesn't mean it's a crappy port, and it doesn't mean it uses crappy shim libraries. Many apps are written exclusively for the iPhone using only Apple's APIs, but are written in other more productive programming languages.
Objective-C is a good language. But it is old and relatively slow. There is 30 years of computer science research built on the lessons learned with the C family of languages. You can compile and link modern languages like Scala natively, no shims, no interpreted code. The executables are nearly indistinguishable from compiled C code--and they run even faster than ObjC. But they are banned now because they're not on Apple's narrow list.
Computer science progress is being collaterally murdered in Apple's attempt to thwart Adobe. This won't scare too many developer's away from Apple's platform. But it will stop new, sophisticated software from appearing on it. Ironically, if you want to write a complex app specifically targeting the iPad, rather than porting a crappy existing app, your best bet is to use a modern language in which you are a 100x more productive. For a complex, innovative project, most developers simply don't have the resources to do it in C*--even if they know how to perfectly well.
I am in this boat. I know C/Objective-C/C++ damn well. They are each good languages in their own way. But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe. And again, what is driving me off the wall, is the end result using our language of choice would be faster, more stable, more maintainable, just as native, and with no bloated intermediate layers. I'm all for keeping Flash and crappy port ware off of the App Store. But these rules do so much more than that. Apple is shooting themselves in the foot (and me in the head).
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?
Heh, someone's a troll here but it's not me.
You have to sign the new developer agreement in order to download the 4.0 SDK. For me, it's already in place since I downloaded the 4.0 SDK. Apple didn't wait. The agreement I clicked on did not state that it would only go into effect after the 4.0 SDK is released.
And yes, iPhone apps run pretty close to the bare metal. They have to in order to get performance out of the device. UIKit is a nice abstraction and Core Animation is nice for basic visual effects, but if you enjoy playing games on your iPhone you're using an app that was written to the OpenGL spec and uses all sorts of compiler, math library, and coding tricks to eek out performance.
There are still tookits like Cocos2D and OolongEngine that are "native" to the iPhone, but a lot of the toolkits that developers were planning on to get some really good apps over are now no longer available. And I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.
That all stems from either MS not writing the .net framework for OSX, or Apple simply not allowing it. I find it interesting that you can create programs for OSX in VS on a Windows machine though, so if you ran parallels, you could write apps for osx in VS, on a mac.
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 think we need to know more about how the Adobe tool works. If there is some kind of "runtime" bundled with every Adobe generated app then I could see it being a problem. On the other hand, if the generated app is able to respond to the same messages that "normal" Objective C apps respond to, then the app should be fine. Adobe could probably solve the license issue if they make their tool generate an Xcode project with ObjC source code that contains all the required boiler plate event handlers.
Another question is in light of this new requirement for multitasking, do all of the current Apps need to be upgraded to the new version and do all Apps submitted have to be 4.0 or can people still use their current SDK and choose not to upgrade.
Also can someone explain how you quit an App in multitasking environment? I'm sure it has been explained somewhere but I have not seen it yet.
Double tap the home button to bring up the background process tray, then hold on an app until a - sign appears over it. Tap that and the app quits
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
It seems from here as though Adobe will soon be releasing an kind of Flash interpreter (they call it a "compiler" but I'm unconvinced) despite the ban on them in previous SDK agreements.
And Apple seems to have preemptively clarified the matter before Flash CS5 ships (on Monday). Until then there technically isn't a released version, just the beta.
If it IS true, then I really hope Apple and Unity can work something out, because a lot of great games will vanish without that kind of middleware!
I don't use Unity, but I suspect the core is probably in C or maybe even in obj-C for the iphone. What you wrote in C# or Javascript or whatever it is are being translated into obj-C calls by the engine. and you project is compilable on xCode, it should be fine.
People might think this is targeting Adobe, but in reality this might be written specifically for Opera. Opera says their rendering engine doesn't execute code, it's interpreting their proprietary markup language. That takes them out of the equation.
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.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.
You act as if it is a technical reason it is forgivable, but if it is a business decision then it is unrighteous. Some people seem to look for evil in everything a corporation does. As for me I will give Apple the benefit of the doubt that they have a reason that makes sense to them, whether technical or business.
I have not seen an official Apple explanation, but I have seen a lot of rampant speculation.
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.
Huh. I guess Apple may be late to the game, but the best player nonetheless.
One of the things that has made the iPhone have high retention rates has been the unbeleivable stability & performance. My BBerry was a piece of garbage & 3rd party apps were always crashing the whole system. There is a reason they need a removable battery, you have to pull it out like once a week!!!
Apple is an expert at making products that do what they are advertised to do & do it beautifully. Microsoft & other are experts at making devices that supposedly do everything & then do everything horribly. I'd rather things just work so I don't waste half my life on garbage that doesn't perform as advertised.
In this regard I think OS X really has some way to go. It has come far & Snow Leopard has been by far the most stable OS for me but I would like to see them take 10.7 more in a direction like the iPad & iPhone. Switching from PCs to Macs was one of the greatest life decisions I ever made & not once in the past 5 years have I regretted it.
This argument about why all languages except C/Objective-C/C++ are prohibited doesn't hold up at all. All developers submit to the App Store is a binary--no source code at all. So if Apple is analyzing the program some how, they are analyzing the binary. And any natively compiled language would look the same to such a tool.
I'm not an iPhone OS developer, but, if the structure of apps on iPhone OS is like the structure of apps on Mac OS X, this isn't really true. There's the compiled code, and then there are various, separate resource files that make up the .app, not all of which are in binary format.
Quote:
But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe.
This may be the case, at least temporarily, but, in the long-run, developers, the platform and users are likely to benefit more from 3rd-party frameworks developed in Objective-C, with Objective-C interfaces, and supporting Objective-C techniques, than from tools that go off in a completely different direction and don't actually add value to the platform.
Heh, someone's a troll here but it's not me.... I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.
I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.
It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
XCode is extremely easy to use and free.
Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
Although I'm not the original poster, let me just say that (as a developer!) this sort of thing isn't rocket science. To suspend an app, just write all of its allocated writeable RAM out to NVRAM, save the processor registers, and stop giving it time. To wake it back up, restore the RAM and the registers and give it cycles. It doesn't matter if it's interpreted, compiled with an alternate compiler, or a "true" Objective C app.
Yes, I have a couple apps on the store and wrote the first one using UIKit and Core Animation because nothing else existed yet. I actually haven't released anything using Unity or one of the other dozen toolkits that are popping up, but I was hoping to.
But I had also been planning on recommending such a path at work to get our Java and C# libraries over to the iPhone for some Enterprise-level stuff. Now that's never going to happen. Looks like we'll be sticking with .NET 4.0 there.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
First of all: We have no way to guarantee most of the things people state here. Should we declare a "moratorium" on discussions and conversations because of that? I'm a C/C++ developer and I have been doing it for 13 years. Naturally, you are free to believe it or not.
About my "two-sided" explanation: unlike some people, when I explain concepts or ideas, I try to convey all information I have; I don't omit the parts that go against my side. As I explained, all harm would be caused to the process that couldn't be properly placed to sleep. If other processes were coded to share resources (which would be virtually impossible since Apple doesn't allow multiple processes from the same application - maybe different processes from different applications?), there could be a problem.
Please explain why one application failing would be disastrous? As far as I can see, if an application fails, people will blame its authors, not Apple or other companies. And no honest company wants a bad image to their products.
At least, you agree that it seems more like a business decision. About the quality part, it is yet to be reasoned. I wonder if people would be enraged if IBM or Microsoft decided to tell developers how they are supposed to write code and which tools they can use or not.
because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
Wait. Are you telling me that iPhone OS 4.0 throws us back into the times of cooperative multi-tasking? That's quite a few steps in OS architecture. Btw, in the end every binary will be linked against the system libraries (like libc) in order to be able to interface the OS anyway. So clean-up work could always be done at init time of the process.
I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.
It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
XCode is extremely easy to use and free.
Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.
In short, your analogy is completely unrealistic.
Are you a developer? How many apps do you have for sale in the store? If none, please stop calling me a troll just because I disagree with you!
XCode isn't bad, but it's also not very good. I work in Java, C#, Objective-C and C on a regular basis, and I'd say that all the Java IDE's are far better than XCode, and Visual Studio is slightly better. You're right that it's free, but you get what you pay for. The real shining star of Apple's dev chain is Interface Builder, but you can't use that for games anyway so that's irrelevent.
You act as if it is a technical reason it is forgivable, but if it is a business decision then it is unrighteous. Some people seem to look for evil in everything a corporation does. As for me I will give Apple the benefit of the doubt that they have a reason that makes sense to them, whether technical or business.
I have not seen an official Apple explanation, but I have seen a lot of rampant speculation.
cross platform like Flash means it's easy to port to another platform. Apple want's to make it as hard as possible to port apps to other mobile platforms.
Think Microsoft in the 1990's. you take open standards, bastardize them just enough to make it uneconomical to port software written for your OS to another OS
Comments
Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.
It's a business decision, not a technical one.
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?
because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
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.
Remember, Apple isn't just banning interpreted code anymore, they're banning statically compiled code just because it comes from a different source language. This targets way more than just Flash, including hundreds of decent apps already in the App Store. Just because a different programming language is used doesn't mean it's a crappy port, and it doesn't mean it uses crappy shim libraries. Many apps are written exclusively for the iPhone using only Apple's APIs, but are written in other more productive programming languages.
Objective-C is a good language. But it is old and relatively slow. There is 30 years of computer science research built on the lessons learned with the C family of languages. You can compile and link modern languages like Scala natively, no shims, no interpreted code. The executables are nearly indistinguishable from compiled C code--and they run even faster than ObjC. But they are banned now because they're not on Apple's narrow list.
Computer science progress is being collaterally murdered in Apple's attempt to thwart Adobe. This won't scare too many developer's away from Apple's platform. But it will stop new, sophisticated software from appearing on it. Ironically, if you want to write a complex app specifically targeting the iPad, rather than porting a crappy existing app, your best bet is to use a modern language in which you are a 100x more productive. For a complex, innovative project, most developers simply don't have the resources to do it in C*--even if they know how to perfectly well.
I am in this boat. I know C/Objective-C/C++ damn well. They are each good languages in their own way. But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe. And again, what is driving me off the wall, is the end result using our language of choice would be faster, more stable, more maintainable, just as native, and with no bloated intermediate layers. I'm all for keeping Flash and crappy port ware off of the App Store. But these rules do so much more than that. Apple is shooting themselves in the foot (and me in the head).
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?
Heh, someone's a troll here but it's not me.
You have to sign the new developer agreement in order to download the 4.0 SDK. For me, it's already in place since I downloaded the 4.0 SDK. Apple didn't wait. The agreement I clicked on did not state that it would only go into effect after the 4.0 SDK is released.
And yes, iPhone apps run pretty close to the bare metal. They have to in order to get performance out of the device. UIKit is a nice abstraction and Core Animation is nice for basic visual effects, but if you enjoy playing games on your iPhone you're using an app that was written to the OpenGL spec and uses all sorts of compiler, math library, and coding tricks to eek out performance.
There are still tookits like Cocos2D and OolongEngine that are "native" to the iPhone, but a lot of the toolkits that developers were planning on to get some really good apps over are now no longer available. And I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.
Then where is Visual Studio for Mac OSX?
That all stems from either MS not writing the .net framework for OSX, or Apple simply not allowing it. I find it interesting that you can create programs for OSX in VS on a Windows machine though, so if you ran parallels, you could write apps for osx in VS, on a mac.
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 think we need to know more about how the Adobe tool works. If there is some kind of "runtime" bundled with every Adobe generated app then I could see it being a problem. On the other hand, if the generated app is able to respond to the same messages that "normal" Objective C apps respond to, then the app should be fine. Adobe could probably solve the license issue if they make their tool generate an Xcode project with ObjC source code that contains all the required boiler plate event handlers.
Another question is in light of this new requirement for multitasking, do all of the current Apps need to be upgraded to the new version and do all Apps submitted have to be 4.0 or can people still use their current SDK and choose not to upgrade.
Also can someone explain how you quit an App in multitasking environment? I'm sure it has been explained somewhere but I have not seen it yet.
Double tap the home button to bring up the background process tray, then hold on an app until a - sign appears over it. Tap that and the app quits
So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?
It seems from here as though Adobe will soon be releasing an kind of Flash interpreter (they call it a "compiler" but I'm unconvinced) despite the ban on them in previous SDK agreements.
And Apple seems to have preemptively clarified the matter before Flash CS5 ships (on Monday). Until then there technically isn't a released version, just the beta.
If it IS true, then I really hope Apple and Unity can work something out, because a lot of great games will vanish without that kind of middleware!
I don't use Unity, but I suspect the core is probably in C or maybe even in obj-C for the iphone. What you wrote in C# or Javascript or whatever it is are being translated into obj-C calls by the engine. and you project is compilable on xCode, it should be fine.
People might think this is targeting Adobe, but in reality this might be written specifically for Opera. Opera says their rendering engine doesn't execute code, it's interpreting their proprietary markup language. That takes them out of the equation.
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.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.
You act as if it is a technical reason it is forgivable, but if it is a business decision then it is unrighteous. Some people seem to look for evil in everything a corporation does. As for me I will give Apple the benefit of the doubt that they have a reason that makes sense to them, whether technical or business.
I have not seen an official Apple explanation, but I have seen a lot of rampant speculation.
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.
Huh. I guess Apple may be late to the game, but the best player nonetheless.
One of the things that has made the iPhone have high retention rates has been the unbeleivable stability & performance. My BBerry was a piece of garbage & 3rd party apps were always crashing the whole system. There is a reason they need a removable battery, you have to pull it out like once a week!!!
Apple is an expert at making products that do what they are advertised to do & do it beautifully. Microsoft & other are experts at making devices that supposedly do everything & then do everything horribly. I'd rather things just work so I don't waste half my life on garbage that doesn't perform as advertised.
In this regard I think OS X really has some way to go. It has come far & Snow Leopard has been by far the most stable OS for me but I would like to see them take 10.7 more in a direction like the iPad & iPhone. Switching from PCs to Macs was one of the greatest life decisions I ever made & not once in the past 5 years have I regretted it.
This argument about why all languages except C/Objective-C/C++ are prohibited doesn't hold up at all. All developers submit to the App Store is a binary--no source code at all. So if Apple is analyzing the program some how, they are analyzing the binary. And any natively compiled language would look the same to such a tool.
I'm not an iPhone OS developer, but, if the structure of apps on iPhone OS is like the structure of apps on Mac OS X, this isn't really true. There's the compiled code, and then there are various, separate resource files that make up the .app, not all of which are in binary format.
But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe.
This may be the case, at least temporarily, but, in the long-run, developers, the platform and users are likely to benefit more from 3rd-party frameworks developed in Objective-C, with Objective-C interfaces, and supporting Objective-C techniques, than from tools that go off in a completely different direction and don't actually add value to the platform.
Heh, someone's a troll here but it's not me.... I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.
I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.
It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
- XCode is extremely easy to use and free.
- Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
- The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.In short, your analogy is completely unrealistic.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
Although I'm not the original poster, let me just say that (as a developer!) this sort of thing isn't rocket science. To suspend an app, just write all of its allocated writeable RAM out to NVRAM, save the processor registers, and stop giving it time. To wake it back up, restore the RAM and the registers and give it cycles. It doesn't matter if it's interpreted, compiled with an alternate compiler, or a "true" Objective C app.
Yes, I have a couple apps on the store and wrote the first one using UIKit and Core Animation because nothing else existed yet. I actually haven't released anything using Unity or one of the other dozen toolkits that are popping up, but I was hoping to.
But I had also been planning on recommending such a path at work to get our Java and C# libraries over to the iPhone for some Enterprise-level stuff. Now that's never going to happen. Looks like we'll be sticking with .NET 4.0 there.
Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.
In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.
I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.
The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
First of all: We have no way to guarantee most of the things people state here. Should we declare a "moratorium" on discussions and conversations because of that? I'm a C/C++ developer and I have been doing it for 13 years. Naturally, you are free to believe it or not.
About my "two-sided" explanation: unlike some people, when I explain concepts or ideas, I try to convey all information I have; I don't omit the parts that go against my side. As I explained, all harm would be caused to the process that couldn't be properly placed to sleep. If other processes were coded to share resources (which would be virtually impossible since Apple doesn't allow multiple processes from the same application - maybe different processes from different applications?), there could be a problem.
Please explain why one application failing would be disastrous? As far as I can see, if an application fails, people will blame its authors, not Apple or other companies. And no honest company wants a bad image to their products.
At least, you agree that it seems more like a business decision. About the quality part, it is yet to be reasoned. I wonder if people would be enraged if IBM or Microsoft decided to tell developers how they are supposed to write code and which tools they can use or not.
because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
Wait. Are you telling me that iPhone OS 4.0 throws us back into the times of cooperative multi-tasking? That's quite a few steps in OS architecture. Btw, in the end every binary will be linked against the system libraries (like libc) in order to be able to interface the OS anyway. So clean-up work could always be done at init time of the process.
I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.
It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
- XCode is extremely easy to use and free.
- Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
- The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.In short, your analogy is completely unrealistic.
Are you a developer? How many apps do you have for sale in the store? If none, please stop calling me a troll just because I disagree with you!
XCode isn't bad, but it's also not very good. I work in Java, C#, Objective-C and C on a regular basis, and I'd say that all the Java IDE's are far better than XCode, and Visual Studio is slightly better. You're right that it's free, but you get what you pay for. The real shining star of Apple's dev chain is Interface Builder, but you can't use that for games anyway so that's irrelevent.
You act as if it is a technical reason it is forgivable, but if it is a business decision then it is unrighteous. Some people seem to look for evil in everything a corporation does. As for me I will give Apple the benefit of the doubt that they have a reason that makes sense to them, whether technical or business.
I have not seen an official Apple explanation, but I have seen a lot of rampant speculation.
cross platform like Flash means it's easy to port to another platform. Apple want's to make it as hard as possible to port apps to other mobile platforms.
Think Microsoft in the 1990's. you take open standards, bastardize them just enough to make it uneconomical to port software written for your OS to another OS