Slashdot Mirror
iOS Vs. Android: Which Has the Crashiest Apps?
First time accepted submitter creativeHavoc writes "Forbes author Tomio Geron takes a look at data accrued by mobile app monitoring startup Crittercism. After looking at normalized data of crashes over the various mobile operating system versions he compares crash rates of apps on the two platforms. He also breaks it down further to look how the top apps compare across the competing mobile operating systems. The results may not be what you expect."
The $600 device's main purpose is NOT to make calls. It's an internet communications device that just happens to make phone calls. The people who insist that basic phones are just fine need to figure out this slight, but important, distinction. Buy an internet device if you want internet, but don't compare it to a phone.
In the short term, I'll probably opt for a BASIC voice-and-text flip-phone of some kind, because I can't afford (nor stomach!) spending $600 on a PHONE whose MAIN purpose is to MAKE CALLS when I can get a $70 model that will take care of that primary function just fine for now.
Its a common perspective, but first of all most people (at least in the US) buy their phone subsidized with a contract renewal, so the price for even a top-tier phone is $200-$300. Second, for me personally after using smartphones for a few years, I view it as the most significant personal (non-work) computing device I use daily. I definitely use it more than my home PC and tablet combined, and can therefore justify spending top dollar on a quality "phone". I won't make assumptions about you, but I know many people who found, when they get a smartphone, that its main purpose is NOT to make calls.
I dunno how iOS works, but on the Android platform the user has to clear RAM manually.
I'm going to go out on a limb here and say that you probably don't know how Android works either.
The higher the technology, the sharper that two-edged sword.
Bad apps crash -- sure. But *worse* apps may appear to keep working while storing up later trouble for the user.
Whenever I see a list of software fault types with "crash bug" at the apex, I cringe. When I led a software team, I had to de-program developers who were trained that crashing is the worst possible thing an app can do. It isn't. There are many worse ones, such as leading a user to trust false data, exposing sensitive information, and losing or corrupting a user's work. The worse thing about a crash in the absence of data loss or long recovery time is that it undermines user confidence. It's often possible for a well-architected app to crash (due to programming faults of course) with no serious implications for the user.
Crashing per se isn't a problem. It's a *symptom*. This is important! I've caught developers "fixing crash bugs" without addressing the real problems: failure to program defensively around unexpected conditions like bad input or inability to secure resources like memory or file references. I've seen super-general exception handlers buried way down on the stack which catch every possible exception and quietly attempt to restore the semblance of operation, even though they can't possibly know whether the application is in a consistent state, or whether it is holding orphaned resources. Programmers do this because they've been inculcated with the false notion that crashes per se are terrible things. This leads to hiding the symptoms errors rather than fixing the errors themselves. Hiding the cause of a crash increases the probability of faulty information, loss of data, and shipping a release with serious defects.
So don't treat crashing as a problem, but as an alert signal. A crash in itself is benign, an honest recognition of failure if you will.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.