Over the past 5 years, I’ve used smartphones from Apple and Palm (powered by iOS and webOS), and played around with Android devices over the same timeframe though I’ve never owned one for daily use.
Still, I find the different design choices at the system level to be very different, and the results pretty much what you’d expect for each one:
- iOS: apps are written in Objective C and compiled to native code; there’s no swapfile I’m aware of. There are two results here: apps run fast, and they crash often. They crash because they segv from bad code, they crash because malloc returns null and they segv instead of checking for that, and they crash because the platform kills them for using too much memory.
- Android: apps are written in Java and run in a JIT-compiled VM (which has gotten faster over time, notably in the 2.3 release); I don’t know if there’s a swapfile, but I suspect stock Android releases don’t have one and mods like CyanogenMod allow one. As I said above, I don’t have deep experience with Android devices, but my general perception is that on contemporary roughly equivalent hardware, it feels significantly faster than webOS and significantly slower than iOS. (I’m talking about user perception of speed here, which has to do both with how responsive the UI is and how fast real work gets done. iOS and webOS both pay more attention than Android to keeping the UI responsive, to the best of my knowledge.)
So. This evidence is relatively unsurprising and easy to explain — interpreted code that can have as much memory as it wants never crashes but takes forever to do anything useful; native code under tight memory management is much faster and much more crash prone — what’s interesting to me is that all 3 of these approaches were considered viable in the marketplace. And I don’t even know that the dog slowness of webOS is the reason it failed in the marketplace (and if HP had poured the right resources into it and actually shipped what they said they would in 2011, a better optimized webOS 3 running on 2011-class hardware might not have even felt slow). But even discounting webOS, the other two approaches are both provably market-viable.