Do iOS apps crash more than Android?
forbes.com
forbes.com
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.
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.
Android has garbage collection, yes.
Since iOS5 there's refcounting available, but that's far away from garbage collection. Just add some circular dependencies and refcounting will fail. And no, that's not only a theoretical problem (as everyone who used Python's refcounting before version 2 can tell you).
It is irrelevant to cite situations under which an algorithm will fail to reclaim storage as evidence that an algorithm is "not garbage collection", since it is provable that situations exist for every possible algorithm. I can write a program that creates an infinite linked list but only ever uses the head, most GCs would fail to reclaim the tail of the list even though it is garbage.
This is not a theoretical concern, space leaks are possible under any automatic storage reclamation scheme.
Since in practice you can write applications for Android and iOS with languages and runtimes of your choice...
As you must know, the very name Garbage Collection implies an asynchronous process that travels up and down the program memory street at periodic intervals, trying to find garbage to collect.
The iOS model is more like a waiter in an expensive restaurant who comes and takes your plate away the instant the last morsel of food is in your mouth. You don't have to discard the plate yourself, but you can guarantee he will pick up your plate the moment its free to be picked up.
Actually, that's not true.
Since at least NeXTSTEP there's refcounting. In 1989, NeXTSTEP introduced their NSObject-based Objective-C runtime with relied on -retain and -release calls to count object references. I can only find records commenting on NSObject's support for -retain and -release, but it may have been done earlier in a different Objective-C based runtime. (And I'm certain refcounting was pioneered in earlier runtimes.)
In 1995, the OpenStep standard introduced autorelease pools, which helped automate reference counting. Calling -autorelease on an object increments the retain count and instructs the enclosing autorelease pool to decrement the count when it pops.
In 2011, Lion and iOS 5 introduced ARC – Automatic Reference Counting. It's actually a pretty sweet memory management solution where simple statically applied code transformations streamline memory management without the need of a garbage collector. As you note though, circular dependencies cannot (yet!) be handled by ARC. To assert that circular dependencies can only be handled through garbage collectors is possibly short-sighted. I know the team that implemented ARC already has prototypes that handle some kinds of circular dependencies, or warn programmers of possible circular deps in their code.
To say automatic ref counting is "far away" from garbage collection is rather disingenuous. It's simply different. Both have tradeoffs. Garbage collection handles all memory management for you; automatic reference counting still requires some manual memory management. GC gracefully deals with circular dependencies; ARC leaks memory with circular dependencies. GC requires runtime overhead in memory and clock cycles; ARC minimizes memory and CPU overhead and, when you need zero overhead, you can drop down to manual memory management.
Frankly, I far prefer ARC to GC. ARC gives me almost all the benefits with no runtime overhead. There's nothing running alongside my code that might randomly suck up cycles or pause execution, and I can always profile exactly what my users will run. Don't knock refcounting just because it's not vogue.
My point about profiling the exact user experience still stands. I can exactly instrument the hotspots in my code and fix them as needed – I can disable ARC, I can avoid autorelease pools. (Or I can add my own autorelease pools or manual retains, preventing large objects from being freed until I'm outside of a hotspot.) Importantly, I know what's being profiled is exactly what will be run by my users. I can't say the same about GC code, since the collector must be free to reap whenever and however it decides. Heck, depending on the runtime, I can't even be certain which GC algorithm will be used by my customers.
I appreciate the control refcounting gives me, and I love that ARC makes writing refcounted code almost as painless as writing GC code without the loss of control. I like being able to test and profile exactly what my users will run.
It's not, so you should not, because that's completely wrong.
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.
I did this recently for an app that needed no update other than a small bug fix, but I slapped on a "support for iOS 5" just for good measures.
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.
At the end of the day, though, there's only so much you can do to save a developer from himself.
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.
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.
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.
I would have been better off it was jailbroken because I could have more easily navigated the file system and deleted the corrupt image cache right on the device.
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 have at work access to an iPhone 3GS, 4,4S with iOS ranging from 4 to 5. I also have 2 or 3 different handsets of androids to work on. I personally use an iPhone but all my coworkers androids just keep freezing all the time... (my iPhone 3GS used to freeze before but it was a long time ago...) On the other hand, since I've switched to the iphone4S, I can say that apps crash really often but I can't tell if it is due to iOS5(thank you Apple for changing really minor dumb stuff at every f'g new version without having a real deprecation rule as Android has) or my way of using the phone(I use way much more apps).
All in all, I can't really tell if iOS apps crashes more than Android but it seems that Android OS is still very buggy yet.
also, statistics are very little weak creatures from which you can extort any figures. especially,when you read this:
-----------------------------------------
Crittercism, which is backed by Google Ventures, Kleiner Perkins Caufield & Byers, AngelPad, AOL Ventures, Opus Capital and Shasta Ventures, provides crash reporting to app developers.
(To be fair the iOS approval process has sped up considerably, even with the number of submissions growing)