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."
I was expecting android to outdo iOS in the crash department due to all the variables in the android world hat iOS just doesnt suffer from. Namely, android has a wider range of handset support.
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 don't think this has as much to do with Android and iOS as it does with the state of software quality in general. The current state of software quality is abysmal, since the shift to scripting languages and web apps as the primary platform about ten years, the science and art of writing robust and reliable software for OO, event driven, asynchronous platforms like iOS or Android has become an almost lost skill. Unfortunately failure modes for these platforms are more dramatic than for web apps, in that you'll likely get a crash rather than 'error on page' message. The situation has been further exacerbated by management's insistence an always hiring the lowest quality developers they can find, outsourcing, H1 B's etc. If you use low quality and inexperienced devs, you'll likely get an unstable and and unreliable application on these types of platforms. This should be a wake up call to the industry in general in that we need to focus and engineering, quality and reliability, and not just minimizing cost.
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.
I wouldn't call that iOS' "fault". Mobile devices have very limited resources. This isn't like a desktop machine where you've got several gigabytes of memory to play with. If an application is badly behaved and it uses too much memory, that has an effect on the rest of the system. There's only so much memory to go around. Also, if using lots of memory becomes normalised, there's pressure to add more memory to newer models, which will result in lower battery life.
I'm an app developer, and if I ever see that one of my projects is killed for not responding fast enough, I know that there's something very, very wrong somewhere. Usually it's a sign that a junior developer decided to do something processor or network intensive synchronously on the main thread, which is a big mistake. You do what is necessary to get an interface up, and you push everything expensive into the background and update the UI when it finishes. There's no excuse for an application not responding quickly enough, it's easy to do.
If you really think Skype is not at fault, how do you explain the fact that it crashes all the time on other platforms as well?
Bogtha Bogtha Bogtha