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

31–40 of 47 posts

Re: Do iOS apps crash more than Android?

#31

Post by leviathan »

allenbrunson wrote: post #25
cloudwalking wrote: post #21

Earlier quoted context omitted.

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

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

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.

Re: Do iOS apps crash more than Android?

#32

Post by klodolph »

gst wrote: post #24
klodolph wrote: post #22

Earlier quoted context omitted.

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

That's just wrong. 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).

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

Re: Do iOS apps crash more than Android?

#33

Post by andrewmlevy »

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)

Re: Do iOS apps crash more than Android?

#34

Post by unreal37 »

klodolph wrote: post #32
gst wrote: post #24

Earlier quoted context omitted.

That's just wrong. 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).

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…

Kinda splitting hairs. Even though it's automatic, it's not called garbage collectio, and its handled quite differently in iOS 5 than in languages such as Java. iOS releases memory the instant its reference counter gets to 0 - not seconds or minutes later.

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.

Re: Do iOS apps crash more than Android?

#35

Post by wvenable »

zrgiu_ wrote: post #11
wvenable wrote: post #9

Earlier quoted context omitted.

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

wow, that's quite a bad experience. is your iPhone jailbroken ?

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.

Re: Do iOS apps crash more than Android?

#36

Post by asynchronous13 »

Sorry, but this analysis does not seem useful.

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.

Re: Do iOS apps crash more than Android?

#37

Post by ryannielsen »

gst wrote: post #24
klodolph wrote: post #22

Earlier quoted context omitted.

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

That's just wrong. 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).

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

Re: Do iOS apps crash more than Android?

#38

Post by shareme »

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

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.

Re: Do iOS apps crash more than Android?

#39

Post by pixie_ »

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.

Re: Do iOS apps crash more than Android?

#40

Post by algolicious »

ryannielsen wrote: post #37
gst wrote: post #24

Earlier quoted context omitted.

That's just wrong. 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).

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 depending on the algorithm used. When an object falls out of scope in a reference counted world, it is typically immediately freed - if this is a handle into a large recursive data structure, for example, it can definitely suck up cycles. Counterintuitive as it may seem, GC can be the cheapest solution in some circumstances, unless your program eschews malloc entirely.
Post reply on HN