It really irks me when crashes are made out to be the result of user actions, or some inescapable act of god. Excepting the very rare hardware fault, crashes are caused by a programmer error. PERIOD. That is all that really matters from the user's perspective. There may be some way to work around the bug by tinkering with things, but nothing the user does can ever cause a crash.
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.
That's not really proof that you were doing things correctly. You could well have been relying on undocumented corner case behavior that just happened to be true in one version of iOS, but not the next.
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 believe most of the "fixes for iOS 5" and "adding iOS 5 support" updates are just marketing strategies. It makes users feel that the app is up to date.
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.
To be fair, this is why you, as an Apple Developer, get the SDK in advance of the general public and is why Apple strongly encourages you to do your due diligence before the iOS version goes public. And they do release API diffs, too.
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.
Oh how I sometimes wish I had some kind of memory management in Android ... It's a real joy when the system decides to reclaim a few thousands of of objects when the user is playing your game.
iOS and Android both have garbage collection, and it is mandatory for neither OS. (I would consider ARC garbage collection, and nothing is stopping you from running C code on Android.)
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).
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.
You're saying you have a different definition of "garbage collection", that's fine. Reference counting is listed as one of the three classical garbage collection algorithms on page 19 of "Garbage Collection" by Richard Jones and Rafael Lins. In the preface they define garbage collection as "the automatic reclamation of heap-allocated storage after its last use by a program."
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...
Anything that runs in Dalvik VM has gc turned on and its mandatory.. even C programs that run in Dalvik, all androd applications run in Dalvik even c ones, have the Dalvik Vm gc turned on..thus quite mandatory on Android.
My anecdotal evidence co-incides with this, I used to use Android and had barely any crashes (the only ones were generally specifically reproducable bugs), and now I use iOS and I see a lot more.
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.
I get loads of iOS app crashes. My wife routinely crashes the browser on her iPad. It is interesting though that unlike Android she never thought the apps were crashing, because they just silently exit and return her to the home screen without any message. She always just assumed she accidently exited the app herself. On Android on the other hand you get the ugly 'Force Close' and other unfriendly messages. I always wonder if this contributes to commonly held belief that iOS apps are of higher 'quality' (obviously other things like smoothness and design do too...)
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.
I develops applications for a living on both android and iOS, and as a developer, each one has its quirks.
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.
I suspect that 75% of the crashes on iOS are from poor memory management due to naïve app programmers. Android app developers don't need to worry about memory management, because Java takes care of this automatically. I suspect with iOS-5's new automatic reference counting, iOS crashes will decrease.
I agree. ARC should help solve some of the memory management issues of "naïve" developers, particularly with its zeroing weak references feature. Then at least delegate callbacks from URL connections get passed to nil instead of the view controller that just got popped off the stack, for example.
At the end of the day, though, there's only so much you can do to save a developer from himself.
YMMV, I guess. I believe there's a general rule that the more crappy apps you put on your device, the more often you will see crashes. I almost never see an app crash, the worst offender over the years has been the New York Times app, of all things. I periodically delete it and read the Times in Safari until they ship a new version. My wife OTOH plays a ton of games and sees a fair amount of crashes. I'm guessing games are not as well-tested, but also, more apps will mean more crashes. Crash, BTW, means "freezes up". Easy to recover by pushing the button and the phone and the rest of the apps are still fine. The phone itself has only crashed a couple of times over the last three years, requiring a power off and restart.
I have almost never had an iOS app crash on me. I get crashes in Android apps almost weekly. I honestly don't know where those guys are getting their data, but I really don't believe it.
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 get iOS app crashes all the time -- and not just third party applications. The app store seems particularly buggy and in the 5 months since I've had my iPhone; crashing on multiple occasions.
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.
It was not at the time. I've only been jailbroken since the untethered for iOS 5 came out.
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.
I work with an iPhone 4 and an HTC Sensation all day long. 12 hours a day I'm holding either phones in my hands. I have >500 purchases in my itunes account, and just as many in my android market account. That's what I'm basing my belief on.
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.
The last two or three iOS updates caused quite a few crashes until some updates rolled in, and beyond that I still get some every day. Most of the on my iPad, mostly due to the fact that I use it a bit more and with apps that deal with more data (e.g. GoodReader) or network traffic (browsers, Flipboard, Alien Blue).
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.
You only see crash reports in the publisher console if the user reports the crash. In practice, users will send a report only a small fraction of the time, so that's where software that automatically does it all the time becomes very useful.
I mention this in the article, but I want to re-emphasize how the approval time is a huge factor. We've had Android developers submit fixes the same day they've discovered a bug on our platform, while iOS devs wait in the queue. You could argue this allows buggier apps to be submitted in the first place, but this sample is taken from devs who use our service and obviously care about producing high quality apps.
(To be fair the iOS approval process has sped up considerably, even with the number of submissions growing)
I've made apps for Android and iPhone. The iPhone crashes less. I've found in a lot of cases that null pointer exceptions that usually would kill an Android app and handled silently by iPhone because in Objective-C passing a message (calling a function) on a null value is just ignored. I wonder how many other iPhone apps have avoided crashing because of this behavior.
I wouldn't hold my breath. For the most part, if a developer can't be bothered to clean up their memory manually then they probably can't be bothered to use ARC properly. It's not trivial: http://longweekendmobile.com/2011/09/07/objc-automatic-refer...
I get an iOS app crashing all the time. The Facebook app closes unexpectedly on me a fair bit, and I've had Safari close two or three times, but apart from that everything I use seems to be very stable...
I've been repeatedly shocked about how many of my friends give me crap for liking Android and then talk about their apps crashing frequently. I can't say I've had a single app crash on my Galaxy Nexus and that includes running nightly CM9s.
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.