Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do iOS apps crash more than Android?

forbes.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Do iOS apps crash more than Android?

#41

Post by zrgiu_ »

extension wrote: post #15
zrgiu_ wrote: post #13

Earlier quoted context omitted.

When an Android app runs of memory it also crashes, with an OutOfMemory error.

So it does. 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.

Re: Do iOS apps crash more than Android?

#42

Post by sskates »

zrgiu_ wrote: post #2

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 u…

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.

Re: Do iOS apps crash more than Android?

#43

Post by zedwill »

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.

Re: Do iOS apps crash more than Android?

#44

Post by bwarp »

cloudwalking wrote: post #21
extension wrote: post #5

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…

I have been bitten twice by changes to the iOS SDK. An app that ran fine, without error, on one version of iOS would crash on a later version. It's always something caused by a programmer, but not necessarily the app programmer...

Ironically, Microsoft tend to make sure that this never happens inside the Windows API.

Re: Do iOS apps crash more than Android?

#45

Post by masklinn »

klodolph wrote: post #22
extension wrote: post #15

Earlier quoted context omitted.

So it does. 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.

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.)

> I would consider ARC garbage collection

It's not, so you should not, because that's completely wrong.

Re: Do iOS apps crash more than Android?

#46

Post by ryannielsen »

algolicious wrote: post #40
ryannielsen wrote: post #37

Earlier quoted context omitted.

Since iOS5 there's refcounting 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 r…

Reference counting does have runtime overhead, though. Incrementing and decrementing references as a reference gets passed around isn't free. If you have many small objects, the reference count itself may become a significant memory overhead. Furthermore, GC means that memory allocation can be done by allocating at the top of the heap instead of a more expensive malloc, and freeing garbage may be literally free depen…

Yes, GC can be faster in some scenarios. I'll never get into a dispute about what's faster... legitimate arguments can be made both ways.

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.

Re: Do iOS apps crash more than Android?

#47

Post by Scaevolus »

algolicious wrote: post #40
ryannielsen wrote: post #37

Earlier quoted context omitted.

Since iOS5 there's refcounting 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 r…

Reference counting does have runtime overhead, though. Incrementing and decrementing references as a reference gets passed around isn't free. If you have many small objects, the reference count itself may become a significant memory overhead. Furthermore, GC means that memory allocation can be done by allocating at the top of the heap instead of a more expensive malloc, and freeing garbage may be literally free depen…

Another nice thing about refcounting versus other garbage collection strategies is that it can have more deterministic memory access patterns-- including possibly preventing heap fragmentation.
Post reply on HN