Sorry, I think you've failed to grasp what Apple's "Multitasking" is about. They are perfectly happy with apps that do not multitask AT ALL. They are not offering "true" multitasking, but allowing app's to notify system daemons to carry on CERTAIN tasks, e.g. IM notificiations, VoIP, downloading content. If an app doesn't want to do this, and there's no reason an App written in MonoTouch can't do this just as easily as an ObjC Cocoa app, that really doesn't matter to Apple.
Quite. How does one extend this to real-world languages?
"You must originally compose message board posts in English"
So, nazi mind-readers to detect those secret English-as-2nd-Language speakers who are secretly, nefariously still thinking first in their native language before rephrasing it in English?
It's not MacRuby, it's RubyCocoa, but yes, they have their own project using a language not included in this list. No, I'm not expecting consistency here against their own "baby", but what kind of environment does this set up? Would you even want to use RubyCocoa in this environment, much less a 3rd party language bridge to Cocoa (which is 100% targetting Apple's platform and APIs).
please try to distinguish 'cross platform compilers' from using alternate languages to write for Cocoa APIs. it doesn't matter if you're using C# or Ruby, your program is still structured around all the native APIs necessary to function. Unless somebody reverse engineers a similar platform with identical APIs (and thus, likely built on Obj-C as well) you aren't getting around targetting CocoaTouch specifically. And there isn't anything stopping anybody from releasing cross-platform-compiler 'meta platforms' which DO use Obj-C and thus qualify under Apple's new rules.
using a different language doesn't affect security, the executable is still within the same sandbox. please read up on the plethora of projects allowing other languages to work with Cocoa, including desktop OSX, including Apple-funded projects like RubyCocoa.
what does language have to do with that? you can include your own C libraries within your project if you want, the language is no different. if people use other language interfaces to Cocoa, like RubyCocoa or MonoTouch, what is the problem, they are still using apple's libraries. the language has nothing to do with any of that.
Yes, but is relevant if they are not judged to have a anti-compoetitive effect on the market as a whole. Clearly a company does not have to be a 100% monopoly in the literal sense to run afoul of anti-monopoly laws, but these sanctions are not applied to EVERY company. In Europe, it is not even a matter of behavior illegal for 'monopolies' to engage in, if they are a 'monopoly' there can be sanctions.
If Apple was judged a monopoly alot of this type of behavior, along with AppStore monopoly, would likely be barred. Until they are judged a monopoly, this is legit from a legal POV.
Sure, 'multiplatform compiling/targeting' is one thing.
But banning non-approved languages is silly. Even apple is funding projects like RubyCocoa and bringing Python compatability to the Cocoa API. If somebody wants to write an app using CocoaTouch but finds Ruby, Python, Lua, or Mono to be a better fit for the project or their own capabilities than Obj-C, why stop them from doing so?
If the apps still have to interface with Cocoa somehow, how are such app's any more/less native than one written in Obj-C? Such a policy does nothing to stop somebody from writing a cross-platform targetting framework that uses Obj-C. The language is not the real issue.