It's true, it's a lot easier for developers on Android to fix bugs and quickly update their apps because of the lack of an approval process, but that also lowers the bar a great deal on the quality of apps (a lot of which never get updated).
Edit: I don't know how this goes on iOS, but for Android Market apps, you can see all crash reports straight in the publisher console, without the need for 3rd party services.
The worst problem I've ever had is some kind of corruption in the photos app. I thought perhaps it was a corrupt file but I couldn't launch the Photos app to delete it. I couldn't launch the camera app either. There's no way to delete any of the camera roll photos from iTunes either! I went over a month like this until I used a third party desktop application to delete every photo on the phone -- and that didn't work. So I started deleting random cache file in the file system before it finally started working again.
iOS apps crash pretty silently -- they just disappear. That might make the appearance of crashes much smaller.
Personally I see crashes on iOS a couple of times a week, and I hardly use third-party apps. Most of my crashes are Safari!
It might have just been luck, but Safari absolutely never crashed for me, and pretty much the same goes for all my other iOS apps.
But... To be on the topic: I don't think their data is accurate because of the way publishing works on both markets, and of the lack of transparency in other important aspects (how many apps do they base their statistics on each platform ? what's the total users number they have on each platform?) which can reveal exactly WHY those statistics are the way they are for them.
I guess "Among apps that use the Crittercism service, iOS client applications crash more often" was a bit too wordy.
But that's anecdotal evidence anyway, and with my usage pattern you'd just need a few "black sheep" to really bring down the average.
My Android usage isn't that heavy, so not really comparable. Not that many crashes this far, but especially in the early days quite a few freezes.
Also, it wouldn't surprise me if iOS apps crash more than Android apps, because iOS doesn't have virtual memory. When an iOS app runs out of physical memory, it gets killed. This was allegedly a design decision.
It's always something caused by a programmer, but not necessarily the app programmer...
Awhile back, a bunch of apps got updated with what the authors called "fixes for iOS5." I have an app on the store that works all the way back to iOS 3.0, and it needed no updates at all for iOS5.
Occasionally Apple does take away documented, working APIs, but it's rare. In general, I'd say an app needs updates for a new version of iOS mostly because the author assumed things that weren't true.
Though it also has garbage collection, which likely prevents the kind of memory leaks that crash most iOS apps in the first place. And does it let the browser use swap? Because iOS doesn't, so web pages can crash it about as easily as apps can.
At the end of the day, though, there's only so much you can do to save a developer from himself.
I always attributed it to memory management - manual memory management is simply a lot easier to f' up than garbage collection. Meanwhile Android apps are slower and probably consume more memory. It's all tradeoffs.
In the subset of apps that 1) are tracked by crittercism, and 2) crashed, here is some data. Great. I'm more interested in the number of apps that did not crash - but those have already been filtered out of the data set. Also important if you want to make a meaningful comparison, what percentage of apps on each platform are tracked by crittercism?
Way too many unknowns to draw any meaningful conclusions from this data.
Iphone apps tend to be more robust. The objc language has some interesting features like being able to signal a nil (the objc null). You can chain operations without having to care about fails in the middle, and check the final result for nil. This is the equivalent, saving the distance, to the java null pointer assignments, which is perhaps one of the most common errors.
The tricky issue about objetiveC and iphone is memory usage. Memory that is not correctly managed, like free twice, it is going to fail crashing the app (the EXC_BAD_ACCESS error). Getting this right takes a considerable amount of time and effort. Tools to make this easier are the SDK memory monitor, static code analyzers like clang, or the automatic reference counting (ARC) which lets the compile handle release and retain operations for you.
(To be fair the iOS approval process has sped up considerably, even with the number of submissions growing)
