This actually sounds like a good idea. It gives graphically undemanding, data-driven apps a relatively streamlined dev environment, while game development can draw on the existing mindshare of XNA developers.
AFAIK you can write native apps for Android. It's just that they won't run on every Android phone, but will be tied to specific architectures (not a big problem since all Android phones seem to use ARM).
OK, technically it is different. In practice, it isn't. If you want to build on the iPhone, the SDK gives you an API to use the phone's features. If you want to program against WPS7 you're getting a version of Silverlight with APIs to give you access to the phones features. Both are abstractions over a lower-level. Both are native to the phone (as opposed to web apps, which is the common distinction made on the iPhone).
In practice it is different - part of the main difference right now between iPhone, Android, and webOS is how responsive the first is compared to the other two. Snappy UI is a gigantic selling point - speed matters. It is also, IMHO, the main failing point for Palm.
It's easier on the iPhone to do more with the same hardware while maintaining UI responsiveness.
You're using the term "native" to apply to APIs, and giving it the meaning of "not platform-independent".
The generally accepted meaning of "native" when used in the term "native code" is "not run on a virtual machine". This is also the definition of native that is in use when native is applied to "applications" or "apps". "Applications" is pretty close in meaning to "code", and "applications" are very different from APIs, so I don't see how you justify interpreting native with a definition that is only applicable to APIs.
I understand what you're saying. I was trying to address the context of the article which I interpreted as saying that there were no "Native apps" which in iPhone discussions is the contrary of web-only apps. It seemed to me that the author was confusing how Silverlight works on a desktop browser to how it would work on a mobile device (which we don't even know yet, it's possible they could be compiled down to machine code, though very unlikely).
"Native Apps" is only equivalent to "web apps" on the iPhone because VMs aren't allowed on the iPhone, not because web apps don't use iPhone-specific APIs.
Using the CLR "future proofs" it. The iPhone can't use another processor without recompiling all the apps, but Windows Phone is processor independent.
Not that it really matters as it looks like the ARM monoculture is going to continue for a while. At least ARM is a sensible architecture, unlike the power-sucking monstrosity that is x86 and the hardware to support its weird and wonderful instructions.
Java has been like that since a long time, and yet it's problematic on small devices.
CLR or compiled code is not the issue here - it's the hardware - resolution, number of buttons - that stuff.
For games - compiled code and no garbage collecting might be better, but it's doable with CLR too (and actually I preffer CLR with JIT on the device more than compiling).
J2ME comes from a time when people imagined phones based on lots of very different architectures and code that would be seamlessly portable between vastly different devices.
This is not how it turned out (at least not for now).
In reality, if there is no processor fast enough to run an application on top of a virtual machine with speed that is comparable to other platforms, the app is "present-proof".
It may run well in the future, but, by then, what's the point?
The compilation doesn't have to be on the device. The CLR has always supported ahead of time compilation. What if Microsoft's App Store did the compilation before it was downloaded to your device?
How exactly it isn't? iPhone apps run natively on the ARM processor inside the device. .NET code run off pseudocode on a virtual machine. You appear to confuse the CLR with an operating system.
First native iPhone apps are compiled. Second Apple specifically made it that garbage collector is not used, although they released it for Mac OS X (Objective C 2.0 runtime).
Here is how low-level - "C", and assembly - for example you can use (depending on the ARM version) various math libraries on the iPhone to get speedup.
There's a lot of people here who seem to think .NET bytecode (or Java for that matter) is run by the VM. How 90's of you guys. It's compiled on first run, so technically there's no difference with (iPhone) Objective-C apps. The GC may factor in, though.
"The Android reference implementation does not (yet) contain such a JIT compiler, though other implementations may choose to provide one."
I thought that was one of the complaints about Android/Java - the VM runs the code; there's no JIT. That's why the prototype Dalvik JIT that was announced very recently was big news. It certainly wasn't announced in the 90s, anyway.
