Does iOS Crash More Than Android? A Data Dive


Recommended Posts

One good thing about Android is whenever an app crash you have an option to report it to the developer.

its send the details of the crash and the developer fix those issues.

I have seen many app which mention that in the change log.

One good thing about Android is whenever an app crash you have an option to report it to the developer.

its send the details of the crash and the developer fix those issues.

I have seen many app which mention that in the change log.

Also, updates/fixes get approved and posted faster with android. Updates can take days or a week to get approved by Apple for iOS since it has to go through the approval process. With Android, and update/fix can be released within hours.

Because I know what I'm talking about. I know what a crash is and how it manifests. A crash is not just "Oh crap. It's all gone wrong. Throw an error or reboot". IOS handles crashes a LOT better than android, and hides them from the user.

So you are saying that it's better to have the application you are using randomly vanish and the "desktop" appear than to see "This app may have frozen, wait or force close?" or "This app stopped working unexpectedly, force close"?

Maybe it's better for less computer literate people who think that is normal app behaviour, but I personally disagree that seeing no error message whatsoever is better than seeing an error message.

Please stop stating "iOS handles crashes a LOT better" as if it is a fact, when it is obviously personal preference. Thank you :)

What do you mean iOS crashes? Android doesn't "crash" either. It's always apps that crash.

The bottom line is that iOS is not "just working" while Android keeps crashing which is the BS mantra constantly being thrown out.

Besides the lack of a report dialog in iOS, wouldn't both OSes act the same way with regards to crashes?

In any case, anyone can deliberately do something silly like write data beyond the size of a list and trigger an app crash on an OS, and there are only a limited number of ways an OS can deal with that.

Quite petty to compare OSes based on "crashiness" if you ask me.

Because I know what I'm talking about. I know what a crash is and how it manifests. A crash is not just "Oh crap. It's all gone wrong. Throw an error or reboot". IOS handles crashes a LOT better than android, and hides them from the user.

The OS could be a bit more informative if an app repeatedly crashes a few times in a row. Regular users won't understand why, for instance, an app keeps returning to the home screen one second after starting it, and it doesn't help if they repeat launching the app over and over.

  • 2 months later...

I had an iPod touch.. I had to restore it so much it kept crashing.. In the end I scrapped it (hey it was only 2nd gen) and I got a Samsung galaxy ace, it works perfectly, it updates well, never had a problem

P.s the ipt probably due the the fact I was tinkering with the os but on the stock os, it crashed definitely more than once s month

As always.. we see proof that all that talk about how iOS is better is BS. Naturally these claims have always come from less than informed users and not backed up by facts.. as I have always said, from the very first iPhone until the last, iOS apps crashed more than Android ones.

One of the reasons is that developing apps for iOS/Obj-C forces you to keep track of your pointers and handle memory management and if a developer doesn't pay attention their app will eventually address a bad pointer or will try to garbage collect something that doesn't exist and the app will crash (though Apple uses their BS tactics by not showing any dialog boxes but simply kills the app when it crashes). Android apps on the other hand suffered from a different problem (Android handles garbage collection differently so this was not a huge issue), and this problem was the fact that some developers didn't use threads to offload main thread for UI and it caused apps to lock, showing the infamous (force close or wait dialog boxes). Since later versions of Android this practice has been addressed with many good things and Google introduced stuff like AsyncTask which allow you to easily run long-running processes on a separate thread while transfering results back to main UI thread with onPostExecute.

I'm glad someone came out and actually showed the numbers that destroy this Apple myth.

You can't really blame any particular OS for crashing when 95% of the time, the crash is being caused by a poorly written app, not the OS itself. I doubt very much that many of these "measured" crashes were just OS based, for either brand.

This was my first thought. plus how many more can be put down to user 'error' and not the phone?

99% of all those iOS crashes are caused by an app called Farmville.

For those with iPads and iPhones, just go to App store and download that app and run it.

I will change my name if you manage to run it even once at all. (v2.7 by the way.)

Ha ha ha listen to you all. So your personal experiences are good enough to make an assumption on a whole market. Shut up. I have both, IOS crashes sometimes and Android crashes sometimes. It's just all down to luck and how good the programmer is with the particular app. I would say I've had a harder time with IOS but would never say that Android is better although Android does seem to cope better when I'm throwing a lot of complex things at it.

One of the reasons is that developing apps for iOS/Obj-C forces you to keep track of your pointers and handle memory management and if a developer doesn't pay attention their app will eventually address a bad pointer or will try to garbage collect something that doesn't exist and the app will crash

And if your app is targeting iOS 4+, not using CoreFoundation, and is being compiled by the new LLVM compiler with Automatic Reference Counting enabled, this is (in most cases) a thing of the past.

When I say "iOS handles crashed better", what I mean is that it HIDES the fact that there is any kind of issue from the user. "Better" was a poor choice of word.

VERY poor. Just terminating the app without showing the user ANY kind of feedback as to why is the WORST imaginable way to handle an error!

VERY poor. Just terminating the app without showing the user ANY kind of feedback as to why is the WORST imaginable way to handle an error!

There are certainly some ways Apple could make it more apparent that an app has crashed, but I find a "This app has crashed" or bug reporter modal dialog to be more annoying than just saying nothing. I'm usually aware that the app has crashed. A dialog just adds an extra step in between me and getting the app launched again.

hmm. Don't think I've experienced more than a couple crashes on my Desire HD but I thought iOS didn't crash at all for some reason.

are you being serious?? Why would ever think that, did you think iOS was immune to crashes or something?

I've had several iphones, ipads and ipods as well as several android phones and tablets, without a doubt android apps crash 100x more times for me than anything on ios, I just had an android app crash on me a few minutes ago on my galaxy S2 phone "GasBuddy" and last night the google play store crashed while I was browsing, facebook and ebay crash about every other day at least once, haven't had many crashes on ios, I think the cardshark app may have crashed once on my ipad.

are you being serious?? Why would ever think that, did you think iOS was immune to crashes or something?

No.. but that was the rhetoric of all Apple fanboys. iOS is infallible and perfection of the mobile OS and Android is a turd that crashes non-stop. Well now we see what's what.

No.. but that was the rhetoric of all Apple fanboys. iOS is infallible and perfection of the mobile OS and Android is a turd that crashes non-stop. Well now we see what's what.

Rhetoric from a few iOS users and then wrapped in hyperbole and shot right back to ALL iOS users. Way to get back at em' bro! That will teach them.

This topic is now closed to further replies.
  • Posts

    • Zed 1.7.2 has landed with updated OpenCode models, bug fixes and other improvements by David Uzondu Zed 1.7.2 recently landed on the stable release channel, bringing a host of AI-related features including automatic context compaction and settings-based skill management, along with other things like better Markdown preview rendering and custom git commands in the graph view. Starting with the AI stuff, the developers introduced "/compact", a command that basically summarizes your conversation history on demand. This tool prevents your active chat window from hitting token limits by compressing older parts of the dialogue into a brief overview. In addition to that, the team relocated skill management to the settings UI, improving how the application communicates errors regarding those skills, and updated the OpenCode model roster to support DeepSeek V4 Flash, MiniMax M3, Qwen 3.7 Plus, and Nemotron 3 Ultra Free. External agent users can also monitor context window cost metrics and delete individual sessions directly from their history. Right-clicking ref labels in the git graph now opens a context menu that runs different actions against selected targets, kind of how VS Code does it. Here are some of the bug fixes this new release brings: The active agent fails to auto-select when creating a new git worktree. A scrollbar unexpectedly appears on wrapped code blocks in the agent chat. Collapse indicators for project headers appear when performing sidebar searches. Bracketed ellipsis title prefixes fail to show the ellipsis icon properly. Project icons render incorrectly in the recent projects picker. Diff hunk controls appear inside non-editable commit view multibuffers. The software update button hangs indefinitely on the downloading stage. Restoring an agent terminal in a remote project triggers a sudden crash. Splitting a pane that contains an active commit view causes a crash. Linux Wayland freezes when trying to read the clipboard from laggy external apps. Zed is a "newish" code editor trying to break the massive stronghold VS Code has on the developer community. Funny enough, the editor was created by former GitHub employees who worked on the Atom text editor (which Microsoft killed in 2022, several years after it bought GitHub). The project officially hit version 1.0 back in April, introducing platform parity for Windows and Linux alongside deep support for DeepSeek-V4-Pro.
    • 26H2 absolutely will support ARM Windows just not on devices that came with 26H1. This is evident by the fact I am running 26H2, which on my MacBook Neo and Surface Pro 12 (inch), within a VM.
    • Mp3tag 3.35 by Razvan Serea Mp3tag is a powerful and yet easy-to-use tool to edit metadata (ID3, Vorbis Comments and APE) of common audio formats. It can rename files based on the tag information, replace characters or words from tags and filenames, import/export tag information, create playlists and more. The program supports online freedb database lookups for selected files, allowing you to automatically gather proper tag information for select files or CDs. Mp3tag supports the following audio formats: Advanced Audio Coding (aac) Free Lossless Audio Codec (flac) Monkeys Audio (ape) Mpeg Layer 3 (mp3) MPEG-4 (mp4 / m4a / m4b / iTunes compatible) Musepack (mpc) Ogg Vorbis (ogg) OptimFROG (ofr) OptimFROG DualStream (ofs) Speex (spx) Toms Audio Kompressor (tak) True Audio (tta) Windows Media Audio (wma) WavPack (wv) Mp3tag 3.35 changelog: This version introduces a new Files options page, enhanced toolbar customization, support for RF64 WAV files, improved Discogs and MusicBrainz tag sources, and many other improvements and fixes. See the Release Notes for more details. Download: Mp3tag 64-bit | 5.7 MB (Freeware) Download: Mp3tag 32-bit | 5.2 MB Link: Mp3tag Homepage | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • The FIFA World Cup is not US centric.
    • It’s amusing how Microsoft is pushing IT admins as if this was a major, game-changing update. In reality, it’s just an enablement package that bumps the build number, which is disappointing compared to the more substantial 22H2 and 24H2 releases. Technically, 25H2, 26H1, and the upcoming 26H2 are essentially the same, differing only in support schedules. They could have included the Windows K2 improvements here, but chose not to. The era of Windows being in the backburner continues, and this 26H2 release feels like an afterthought. Shame, Nadella, shame.
  • Recent Achievements

    • Week One Done
      AMV earned a badge
      Week One Done
    • One Month Later
      AMV earned a badge
      One Month Later
    • Collaborator
      ryansurfer98 went up a rank
      Collaborator
    • One Month Later
      Eurosoft10 earned a badge
      One Month Later
    • Week One Done
      Eurosoft10 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      523
    2. 2
      +Edouard
      172
    3. 3
      PsYcHoKiLLa
      78
    4. 4
      Steven P.
      72
    5. 5
      Michael Scrip
      71
  • Tell a friend

    Love Neowin? Tell a friend!