3 ms·

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

by johns 17y ago

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).

bensummers 17y ago
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.
- malkia 17y ago
  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).
  - rbanffy 17y ago
    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).
- rbanffy 17y ago
  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?
  - bensummers 17y ago
    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?
potatolicious 17y ago
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.
wtallis 17y ago
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.
- johns 17y ago
  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).
  - wtallis 17y ago
    "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.
rbanffy 17y ago
> In practice, it isn't. 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.

by johns 17y ago

bensummers 17y ago

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.

malkia 17y ago
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).
- rbanffy 17y ago
  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).
rbanffy 17y ago
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?
- bensummers 17y ago
  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?

potatolicious 17y ago

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.

wtallis 17y ago

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.

johns 17y ago
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).
- wtallis 17y ago
  "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.

rbanffy 17y ago

> In practice, it isn't. 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.