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.
If Apple wants to assure the quality of user experience, it should do everything to make apps perform well, act like other apps, etc.
Quote:
Originally Posted by ihxo
maybe there could a flag for apps to op-out of multitasking.
This is not the way Apple does things... how frustrating would it be for the user if some of his favorite apps suspend/resume and others terminate/reload.
The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this <snip> or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.
"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.
Absolute B.S. If this were the case, Apple would have spelled out clearly which compilers could be used to generate the object / binary code. They didn't. They specified which language the code could be written in.
Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.
It was only trying to pass off that troll-ish fantasy of people shunning the iPhone platform (albeit temporarily), because of some ... (not sure if you gave a reason... spite?), that made me reply at all.
...
Apple is courting developers. Apple is bending over backwards for developers. Apple is giving iPhone developers the best deal they've had in years. I'm merely maintaining that any "developer" that runs away from this deal because they only want to code in Python or Java and can't handle switching to some form of C is being foolish at best.
Language syntax is easy. It's the supporting APIs that take time to learn and become fluent in. It's hard to be fluent in more than one or two at the same time. Context switching cost isn't just a programming concept.
For large dev teams porting to ObjC is just something one part of the team does. Even if they have a large of legacy codebase and tool chains. It's mildly annoying to not have a common cross-platform codebase but they're big. Just part of the cost of doing business and they can afford it for such a large potential user base.
For small dev teams they simply target the largest market (iPhone/iPad) and ignore the other mobile targets. Their codebases are minimal and their toolchains are what Apple provides. Ignoring for the moment the small teams that use things like Unity or Torque to develop games.
It's the middle size studios/teams that really need these cross platform environments to compete with the big boys and stay as nimble as the small guys.
Small indy game teams also often depend on a game engine to do the heavy lifting and do the game logic in TorqueScript or C# (I think) for Unity.
Our strategy was to port our legacy business logic written in C# and use Monotouch. That's all up in the air now. From a business case standpoint it's one thing to have a UI team dedicated to the iPhone/iPad and keep our core desktop apps in C# and unify it under Monotouch.
It's a completely different equation if the entire codebase has to be ported to ObjC. Yah, so for us it's going to take a lot longer to get onto the platform if Monotouch is out of the equation. It's not the inability from a technical perspective but the inability from a business/resource perspective.
Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.
Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.
Apple isn't doing anything magical to support multitasking, despite what the RDF of Job's presentation might have you believing. I've read through the API diffs of the new beta and there's nothing special there. It's not even a client/server model for background processes as some have suggested. It's just plain old multitasking. Except your app gets killed after a while if the user forgets to close it, and there are some API hooks to integrate with system services (like the lock screen media player controls), and they expect developers to do a more fine-grained job of saving their app's state when their app actually does quit so that it can be restored more quickly and accurately when the app relaunches.
Apple is banning all other programming languages not for technical reasons, but because it is the most comprehensive way to block Adobe. Unfortunately, there will be a lot of unnecessary collateral damage because of that decision. But Apple apparently has no problem killing a bunch of friendlies in order to get a few more bad guys.
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.
Having not submitted my first app for approval yet, I don't know the process. I think the technical limitation probably has more to do with HOW the compiled applications are structured.
Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.]
I think the whole 'checking for multi-tasking' line of reasoning is a load of crap. The main thrust is to ease Apples approval process as much as anything.
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.
Why?
Quote:
"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.
Because?
Study the Mach microkernel and it's recent child, the XNU kernel. The messaging model is now being streamlined back to leverage the kernel properly with the highest level of efficiency.
Within an embedded platform, efficiency is paramount. In a laptop, desktop, workstation, one has latitude.
Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.
Bingo. Programming languages are functionally equivalent if complete. If you want to write in lameo++ and can compile it or even translate to Obj-C and compile then bingo done. This is 100% a red-herring. The compiler is likely the key but as you say if open source where's the secret sauce?
An API call in an OS doesn't care if C, Fortran, Java, BrainF*ck (yes a real language), etc. calls it as long as the data types work right and you have the right tool support. I find it interesting in fact that the language is the issue. If there was some magic here the COMPILER would be the issue! Since it would put in secret sauce, but a lang -> ObjC -> secret would of course work just fine and you note the legal terms are quite clear about this.
Right now my BS o' meter is red lining...I'd love to see some very explicit details on what this is technically but so far nada. If it something unusual that might be cool to know about, but right now this is all a lame discussion and it's quite sad that CS educated people are NOT jumping all over this as the BS that it is at least give the current level of information provided.
Right now simply declaring one PL or another off limits is akin to saying English is a vastly superior language to Chinese. Tell that to anyone in China and both can express ideas albeit it in different ways. PLs are no different. Lame lame lame Apple
Signed someone who loves Apple but hates partisan programming which is what this is.
Someone please correct me or explain this to me, because due perhaps to my limited programming skills, I can't understand how apple can gauge what original high level language you used if the program submitted to the app store is in binary? I am confused...
Someone please correct me or explain this to me, because due perhaps to my limited programming skills, I can't understand how apple can gauge what original high level language you used if the program submitted to the app store is in binary? I am confused...
A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.
It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)
A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.
It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)
Ok, I see thanks very much for the info, appreciate it a lot.
lol, about the last comment, another way to spur innovation!
..... 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............ blahblah
I am always intrigued by people who claim, 'it isn't rocket science.'
The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.
Typically biased article writing from Apple Insider, but good for a quick laugh I guess.
Android's multi-tasking is superior to Apple's, as it's true multi-tasking and not a half hearted attempt which only multi-tasks a few special cases. As for needing a task manager, iPhone OS 4 has one too, so to bash Android for needing one seems rather hypocritical.
Textedit? You don't need visual studio to compile a .net app it's just ms's version and they don't stop you using 3rd party versions.
Quote:
Originally Posted by anonymouse
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.
firstly shouldn't it still be the developers choice. Secondly why do you assume writing in another language means you can't still use the api's. I may be wrong and apples language may be that bad but in .net there's no problems mixing vb with c# and then hooking into a com object, don't see why this should be any different.
Quote:
Originally Posted by Prof. Peabody
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.
Your argument of no tallent is kinda flawed in that objective c is from the 80s and in the modern languages the tools people use didn't exist over 10 years ago. The fact someone may not be great at objective c doesn't mean there not good it just means they specialise in something else. If you want to be great at any language you have to do it full time and if someone can write a decent compiler that compiles to iPhone there's no reason it can't be as good as something written in Xcode.
I am always intrigued by people who claim, 'it isn't rocket science.'
The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.
I 'm always intrigued as to why rocket science gets all the credit, should have been "it isn't software development"... Anyway everything is simple and everything is complex ultimately, I don't think there's a universal notion of "difficult" to set the standards by.
Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.
No, it won't. API calls are done with the same ARM machine instructions. That is what you are scanning for.
This is a bullshit propaganda article without any basis in fact and I'm surprised that Daniel Eran Dilger will actually put his signature to it. There is no way that the OS executive (the kernel process manager) can or needs to know or distinguish between different compilers in the way it handles process scheduling.
I've re-programmed kernel executives as part of my computer science education and for me the distinction between machine code and abstract computing languages is pretty obvious and part of the fundamental freedoms of the programmer to choose his own tools
That lawyer and MBA types (including Steve Jobs) at Apple Inc. think they can exploit their ownership over the iphone OS platform to force a straightjacket upon developers is to me pretty disgusting. I'm a recent switcher (2005) - although I've been using computers since 1983. I was quite fascinated by the iphone platform and saw it as a great way to win hearts and minds for the Cocoa API but I have to say after the recent draconian moves by Apple to restrict content and free choice for developers and consumers on the iphone platform I am NEVER going to purchase an iPad or iPhone. I will go for Android although on the desktop I will still prefer OS/X.
First, let me say that I learned to program (1958) before there was anything called CS, OOP, compilers, interpreters, etc. (That's before Fortran, CoBOL, BASIC, and, yes, Flash).
Over the years I've made some effort to stay current, but programming is not my major activity... I do it for my own amazement, more than anything else.
I am not a programmer, but I know how to program (I've probably thrown away more [bad] code than a lot of you have written
Let's consider one aspect of the topic D'Jour:
A crucial element of multitasking is efficient use of RAM, whether RAM is dirty (needs to be saved and refreshed or refreshed only), and what resources the OS must expend to determine which memory is no longer needed. Also important is that RAM is organized in blocks (based on usage) that can be easily manipulated when necessary.
One thing that is apparent is that memory management in the iPhone OS is different than many other systems.
In iPhone OS XCode the programmer is responsible for acquiring memory when needed and releasing it when no longer needed.
Other languages and most interpreters remove this burden from the programmer. The "system" goes through a process called "'garbage collection" to detect memory that is no longer needed and release it to the system.
Garbage collection takes precious CPU cycles and seconds... and, likely, will result in poorer performance and poorer memory usage than a knowledgeable programmer performing manual memory management.
I haven't looked at Java or Flash for quite a while. But, AIR, they use garbage collection.
How does someone write an app that depends on system-supplied garbage collection and then deploy it on a system (iPhone OS) that doesn't provide this service?
Have Flash and Java been enhanced to support manual memory management?
Do apps written in other languages (than those supported by iPhone OS) get translated to:
1) use a kludgey, heavy-handed manual memory management?
2) get packaged with a run-time that provides garbage collection within the app?
3) use some other device to efficiently integrate with the iPhone OS multitasking (and memory management) capabilities.
It seems to me that the best way to assure the quality of the user experience is require that the providers of iPhone programs use the tools and procedures specified by the manufacturer...
Am I wrong?
Doesn't [even] Mr. GoodWrench require only GM authorized Parts and Procedures?
what really fascinates me about all this Apple vs. Flash controversy lately is how many people suddenly champion Flash/Adobe as if it is somehow sacred. since it too is a proprietary closed software licensed for profit by one corporation - morally certainly no better than any other, including Apple.
the answer is many developers and users have simply become addicted to it. like cheap drugs. when it was new it was the first good solution to a huge problem - a great high! - so it was widely embraced. ok. eventually it achieved near monopoly status in its category. but now there is a rival, Silveright/MS, and a new kid in town, HTML5/Apple. but the Flash mob won't switch, they're hooked. (and some make their living from it, of course, so you can understand their alarm.)
but nobody owes Adobe anything. their stewardship of Flash when it had to the market to itself was poor. stay addicted to it or kick the habit, but please drop the moral posturing.
"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.
BTW this is not about Adobe vs Apple. This is about Unity vs Apple. And the freedom of programmers to choose their own tools rather than be forced by lawyers to use what is in the latter's capital interest.
Comments
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.
If Apple wants to assure the quality of user experience, it should do everything to make apps perform well, act like other apps, etc.
maybe there could a flag for apps to op-out of multitasking.
This is not the way Apple does things... how frustrating would it be for the user if some of his favorite apps suspend/resume and others terminate/reload.
.
The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this <snip> or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.
"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.
Absolute B.S. If this were the case, Apple would have spelled out clearly which compilers could be used to generate the object / binary code. They didn't. They specified which language the code could be written in.
Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.
Wait until they are devalued, hen buy stock for the inevitable Apple purchase.
It was only trying to pass off that troll-ish fantasy of people shunning the iPhone platform (albeit temporarily), because of some ... (not sure if you gave a reason... spite?), that made me reply at all.
...
Apple is courting developers. Apple is bending over backwards for developers. Apple is giving iPhone developers the best deal they've had in years. I'm merely maintaining that any "developer" that runs away from this deal because they only want to code in Python or Java and can't handle switching to some form of C is being foolish at best.
Language syntax is easy. It's the supporting APIs that take time to learn and become fluent in. It's hard to be fluent in more than one or two at the same time. Context switching cost isn't just a programming concept.
For large dev teams porting to ObjC is just something one part of the team does. Even if they have a large of legacy codebase and tool chains. It's mildly annoying to not have a common cross-platform codebase but they're big. Just part of the cost of doing business and they can afford it for such a large potential user base.
For small dev teams they simply target the largest market (iPhone/iPad) and ignore the other mobile targets. Their codebases are minimal and their toolchains are what Apple provides. Ignoring for the moment the small teams that use things like Unity or Torque to develop games.
It's the middle size studios/teams that really need these cross platform environments to compete with the big boys and stay as nimble as the small guys.
Small indy game teams also often depend on a game engine to do the heavy lifting and do the game logic in TorqueScript or C# (I think) for Unity.
Our strategy was to port our legacy business logic written in C# and use Monotouch. That's all up in the air now. From a business case standpoint it's one thing to have a UI team dedicated to the iPhone/iPad and keep our core desktop apps in C# and unify it under Monotouch.
It's a completely different equation if the entire codebase has to be ported to ObjC. Yah, so for us it's going to take a lot longer to get onto the platform if Monotouch is out of the equation. It's not the inability from a technical perspective but the inability from a business/resource perspective.
Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.
Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.
Apple isn't doing anything magical to support multitasking, despite what the RDF of Job's presentation might have you believing. I've read through the API diffs of the new beta and there's nothing special there. It's not even a client/server model for background processes as some have suggested. It's just plain old multitasking. Except your app gets killed after a while if the user forgets to close it, and there are some API hooks to integrate with system services (like the lock screen media player controls), and they expect developers to do a more fine-grained job of saving their app's state when their app actually does quit so that it can be restored more quickly and accurately when the app relaunches.
Apple is banning all other programming languages not for technical reasons, but because it is the most comprehensive way to block Adobe. Unfortunately, there will be a lot of unnecessary collateral damage because of that decision. But Apple apparently has no problem killing a bunch of friendlies in order to get a few more bad guys.
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.
Having not submitted my first app for approval yet, I don't know the process. I think the technical limitation probably has more to do with HOW the compiled applications are structured.
Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.]
I think the whole 'checking for multi-tasking' line of reasoning is a load of crap. The main thrust is to ease Apples approval process as much as anything.
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.
Why?
"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.
Because?
Study the Mach microkernel and it's recent child, the XNU kernel. The messaging model is now being streamlined back to leverage the kernel properly with the highest level of efficiency.
Within an embedded platform, efficiency is paramount. In a laptop, desktop, workstation, one has latitude.
Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.
Bingo. Programming languages are functionally equivalent if complete. If you want to write in lameo++ and can compile it or even translate to Obj-C and compile then bingo done. This is 100% a red-herring. The compiler is likely the key but as you say if open source where's the secret sauce?
An API call in an OS doesn't care if C, Fortran, Java, BrainF*ck (yes a real language), etc. calls it as long as the data types work right and you have the right tool support. I find it interesting in fact that the language is the issue. If there was some magic here the COMPILER would be the issue! Since it would put in secret sauce, but a lang -> ObjC -> secret would of course work just fine and you note the legal terms are quite clear about this.
Right now my BS o' meter is red lining...I'd love to see some very explicit details on what this is technically but so far nada. If it something unusual that might be cool to know about, but right now this is all a lame discussion and it's quite sad that CS educated people are NOT jumping all over this as the BS that it is at least give the current level of information provided.
Right now simply declaring one PL or another off limits is akin to saying English is a vastly superior language to Chinese. Tell that to anyone in China and both can express ideas albeit it in different ways. PLs are no different. Lame lame lame Apple
Signed someone who loves Apple but hates partisan programming which is what this is.
Someone please correct me or explain this to me, because due perhaps to my limited programming skills, I can't understand how apple can gauge what original high level language you used if the program submitted to the app store is in binary? I am confused...
A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.
It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)
A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.
It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)
Ok, I see thanks very much for the info, appreciate it a lot.
lol, about the last comment, another way to spur innovation!
..... 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............ blah blah
I am always intrigued by people who claim, 'it isn't rocket science.'
The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.
Android's multi-tasking is superior to Apple's, as it's true multi-tasking and not a half hearted attempt which only multi-tasks a few special cases. As for needing a task manager, iPhone OS 4 has one too, so to bash Android for needing one seems rather hypocritical.
Then where is Visual Studio for Mac OSX?
Textedit? You don't need visual studio to compile a .net app it's just ms's version and they don't stop you using 3rd party versions.
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.
firstly shouldn't it still be the developers choice. Secondly why do you assume writing in another language means you can't still use the api's. I may be wrong and apples language may be that bad but in .net there's no problems mixing vb with c# and then hooking into a com object, don't see why this should be any different.
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.
Your argument of no tallent is kinda flawed in that objective c is from the 80s and in the modern languages the tools people use didn't exist over 10 years ago. The fact someone may not be great at objective c doesn't mean there not good it just means they specialise in something else. If you want to be great at any language you have to do it full time and if someone can write a decent compiler that compiles to iPhone there's no reason it can't be as good as something written in Xcode.
I am always intrigued by people who claim, 'it isn't rocket science.'
The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.
I 'm always intrigued as to why rocket science gets all the credit, should have been "it isn't software development"...
Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.
No, it won't. API calls are done with the same ARM machine instructions. That is what you are scanning for.
I've re-programmed kernel executives as part of my computer science education and for me the distinction between machine code and abstract computing languages is pretty obvious and part of the fundamental freedoms of the programmer to choose his own tools
That lawyer and MBA types (including Steve Jobs) at Apple Inc. think they can exploit their ownership over the iphone OS platform to force a straightjacket upon developers is to me pretty disgusting. I'm a recent switcher (2005) - although I've been using computers since 1983. I was quite fascinated by the iphone platform and saw it as a great way to win hearts and minds for the Cocoa API but I have to say after the recent draconian moves by Apple to restrict content and free choice for developers and consumers on the iphone platform I am NEVER going to purchase an iPad or iPhone. I will go for Android although on the desktop I will still prefer OS/X.
Over the years I've made some effort to stay current, but programming is not my major activity... I do it for my own amazement, more than anything else.
I am not a programmer, but I know how to program (I've probably thrown away more [bad] code than a lot of you have written
Let's consider one aspect of the topic D'Jour:
A crucial element of multitasking is efficient use of RAM, whether RAM is dirty (needs to be saved and refreshed or refreshed only), and what resources the OS must expend to determine which memory is no longer needed. Also important is that RAM is organized in blocks (based on usage) that can be easily manipulated when necessary.
One thing that is apparent is that memory management in the iPhone OS is different than many other systems.
In iPhone OS XCode the programmer is responsible for acquiring memory when needed and releasing it when no longer needed.
Other languages and most interpreters remove this burden from the programmer. The "system" goes through a process called "'garbage collection" to detect memory that is no longer needed and release it to the system.
Garbage collection takes precious CPU cycles and seconds... and, likely, will result in poorer performance and poorer memory usage than a knowledgeable programmer performing manual memory management.
I haven't looked at Java or Flash for quite a while. But, AIR, they use garbage collection.
How does someone write an app that depends on system-supplied garbage collection and then deploy it on a system (iPhone OS) that doesn't provide this service?
Have Flash and Java been enhanced to support manual memory management?
Do apps written in other languages (than those supported by iPhone OS) get translated to:
1) use a kludgey, heavy-handed manual memory management?
2) get packaged with a run-time that provides garbage collection within the app?
3) use some other device to efficiently integrate with the iPhone OS multitasking (and memory management) capabilities.
It seems to me that the best way to assure the quality of the user experience is require that the providers of iPhone programs use the tools and procedures specified by the manufacturer...
Am I wrong?
Doesn't [even] Mr. GoodWrench require only GM authorized Parts and Procedures?
.
the answer is many developers and users have simply become addicted to it. like cheap drugs. when it was new it was the first good solution to a huge problem - a great high! - so it was widely embraced. ok. eventually it achieved near monopoly status in its category. but now there is a rival, Silveright/MS, and a new kid in town, HTML5/Apple. but the Flash mob won't switch, they're hooked. (and some make their living from it, of course, so you can understand their alarm.)
but nobody owes Adobe anything. their stewardship of Flash when it had to the market to itself was poor. stay addicted to it or kick the habit, but please drop the moral posturing.
BTW this is not about Adobe vs Apple. This is about Unity vs Apple. And the freedom of programmers to choose their own tools rather than be forced by lawyers to use what is in the latter's capital interest.