--- title: What Should I Do if My App Keeps Crashing on Certain Devices description: If your app keeps crashing on certain devices but not others, this guide explains how to find the cause and stop apps from crashing for good. image: https://weareaffective.com/hubfs/learning-centre-images/what-should-i-do-if-my-app-keeps-crashing-on-certain-devices.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-should-i-do-if-my-app-keeps-crashing-on-certain-devices#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What Should I Do if My App Keeps Crashing on Certain Devices Table of Contents Crashes that hit everybody get fixed within days. Crashes that only hit a slice of your users sit there for months, because nobody on the team can make them happen on the phones sitting on their desk. So if your app keeps crashing on certain devices and behaves perfectly on the rest, the cause is rarely random. Something in the build is making an assumption about memory, screen size, operating system or connection quality that one group of phones doesn't match. > Users who crash out rarely tell you why, they just stop opening the app. The commercial cost of that is brutal and quiet. People don't file a bug report. They delete the app and go somewhere else, and according to [Alphabin](https://www.alphabin.co/blog/mobile-app-testing-uninstall-rates), 62% of users uninstall apps after crashes, freezes or errors. This piece walks through how we work a device-specific crash from first report to released fix, and how to stop apps from crashing again in the same way. It covers the data to gather before touching code, how to reproduce the fault on the hardware that's actually failing, the usual suspects on older phones, and how to decide which devices you're genuinely going to support. ## What a Device-Specific Crash Pattern Is Telling You A crash that clusters tells you more than a crash that's everywhere. When one manufacturer, one chipset or one OS version is over-represented, the pattern itself is half the diagnosis. Your job is to read it before you start guessing. We saw this early on a product aimed at African communities living abroad, built to help people stay connected with their home communities. The build was technically straightforward on the handsets we had in the studio. The devices commonly used in several of the countries involved were far more limited at the time, and delivering half of the intended experience on those phones was going to be extremely challenging. The crash risk was sitting in the gap between the phones we designed for and the phones people actually held. | Pattern in the data | Usually points to | First place to look | | --- | --- | --- | | One manufacturer, many models | Custom OS behaviour | Background limits, battery saving | | Older models only | Memory or storage pressure | Image handling and caching | | A single OS version | Changed or removed API | Platform release notes | | Mixed devices, one region | Connection quality | Timeouts and retry logic | Read the cluster first. The shape of the group tells you which of those four conversations you're about to have. ## The Crash Data You Need Before You Change Any Code Crash reporting gets switched on and never read past the top line. The stack trace tells you where the app gave up. It doesn't tell you what the phone was doing at the time, and that second part is where device-specific faults live. Before anyone opens the codebase, gather the session context around each crash. Device model and manufacturer, OS version, free storage, available memory, battery state, connection type, app version, and the three or four screens the person passed through on the way in. Log free storage and available memory at the moment of the crash, not at app launch. The difference between those two numbers is often the whole answer on older handsets. Then look outside the tooling. Support requests carry patterns that crash reports miss, so read a month of them together and ask whether a common theme is emerging, then try to unpick that back to a particular problem or point of confusion in the app. People describe symptoms rather than causes. Three messages saying the app "freezes when I add a photo" is a memory report written in plain English. It's very easy to assume no news is good news with mobile apps, and it's quite the opposite. Silence usually means people left without saying anything. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Reproducing the Crash on the Device That Is Failing You can't fix what you can't make happen. Simulators are useful for layout and useless for this, because they borrow your laptop's memory, your laptop's storage and your office broadband. All three of those are the things under strain on the phone that's crashing. Buy or borrow the actual handset. A used three-year-old mid-range Android costs less than a day of developer time spent theorising. > The simulator never runs out of memory, which is exactly why it never shows you the crash. Then recreate the conditions, not only the hardware. We worked on a product used by people taking more exotic holidays and backpacking in the wilderness, and the failure only appeared in rural locations with no connection. In the office, on the same handset, everything passed. Open the app on a real device in a basement with the signal dropping in and out, with storage nearly full and twelve other apps already running, and faults surface in minutes that stayed hidden for weeks. If you still can't reproduce it, instrument the path instead. Add breadcrumb logging to the screens the crash reports keep naming, ship it, and wait for the next occurrence to arrive with its own story attached. ## Memory, Storage and Older Hardware Older phones crash for boring reasons, and image handling is near the top of the list. A photo captured at full resolution and held in memory while the app decodes it will take down a handset with limited RAM, while the newer device in your pocket absorbs it without complaint. The code is identical. The headroom isn't. Storage does the same job more slowly. When a phone is close to full, writes fail, caches can't be built and the operating system starts clearing things out underneath you. An app that assumes its cached file is still there will crash the moment the system removes it. #### When your app keeps crashing on budget handsets The device question also belongs at the start of a project rather than after launch, and it sits at the heart of any serious [app architecture design](https://weareaffective.com/app-architecture-design-we-are-affective). On that product for African communities living abroad, the limited capability of the phones in common use was a feasibility concern we raised alongside the focus group findings, because half the intended experience simply wasn't going to run well on them. There's a slower version of this failure too. Apps that eat device space and drain battery get uninstalled weeks later by people who never crashed once. They just needed the room back. Test with the device at 95% full storage and a low battery. Both states change how the operating system treats your app, and both are normal for real users. ## OS Versions, Manufacturer Skins and Permissions Android isn't one platform. Manufacturers layer their own software on top, and those layers change how background work, notifications, battery saving and file access behave. A background task that runs happily on a Pixel can be killed without warning on a handset with aggressive power management, and if your code assumes that task finished, you get a crash that only exists on one brand. Operating system updates cause the other half. An API that was deprecated two versions ago gets removed, and the app that still calls it falls over on the day the update lands. The pattern gives it away, because the crash starts on a date rather than on a device. #### Permissions as a crash cause Permissions deserve their own attention. Asking for camera, location or contacts access early, with no explanation of why, pushes people to decline. We see that in the [first sixty to a hundred and twenty seconds of a session](https://weareaffective.com/learning-centre/why-the-first-thirty-days-decide-the-next-twelve-months-of-retention-in-beauty-a), where invasive permission requests without context drive people straight back out. Declining is a normal, sensible choice, and plenty of apps then carry on as though access was granted and crash on the next screen. Handle the refusal path properly and explain the request before you make it. Both of those reduce crashes and improve the onboarding at the same time. ## When the Network Is the Real Cause Plenty of crashes that look like device faults are network faults wearing a device's clothes. Unstable connections and server timeouts produce empty responses, half-written files and requests that never return, and code that expects data gets nothing and falls over. Phones in areas with weaker coverage cluster in the crash data, which makes it look like a hardware problem. Simon was once stuck at an airport unable to retrieve his boarding pass, because the flight app showed a no connectivity error and refused to open. The ticket was already downloaded and sitting on the phone. He had to prove payment manually and get a ticket written out by hand, which turned something that should have been straightforward into a stressful morning. That's the pattern to hunt for. An app that locks already-cached, static content behind a live connection check has invented a failure it didn't need. On the backpacking product, we retrofitted [offline capability because the core functions](https://weareaffective.com/learning-centre/how-to-decide-what-belongs-offline-what-belongs-online-and-what-belongs-in-a-que) all required a connection. Map search, saved pins, tickets, itineraries and location times were useless in exactly the places people had packed the app for. Opening it to a "you're not connected" wall in the middle of nowhere is an absolute disaster for the person relying on it. ## Deciding Which Devices You Will Actually Support You can't support everything well. Trying to is how teams end up with a lot of features working badly, and people are far less likely to return to an app after a bad experience than they are to forgive a missing feature. Doing a limited number of things extremely well beats cramming more in at lower quality. So make the decision deliberately, write it down, and use these steps in order. 1. Pull your real device and OS distribution from analytics, not from market share articles. 2. Cut the list at the point where revenue and usage stop justifying the engineering cost. 3. Name a minimum OS version and a minimum RAM figure, and publish both internally. 4. Decide what unsupported devices see, which should be a clear message rather than a crash. 5. Review it every six months as the distribution shifts. A graceful block is a reasonable outcome. Telling someone on a six-year-old handset that the app needs a newer version of their operating system respects their time. Letting them download it, register, and crash on the third screen doesn't. ## Fixing the Root Cause Rather Than the Stack Trace The quick fix is to wrap the failing call in error handling and ship it. The crash disappears from your dashboard and the person using the app still can't upload their photo. You've hidden the symptom and kept the problem. We pitched for work with BMW, with the part of the business that handles fleet and rental vehicles, on the app people used to report an accident. The client couldn't work out why nobody was filling it in properly. The interface said "upload your photos" and left people to work out which angles mattered while they were standing at the roadside in shock. Adding a better error message to that form would have changed nothing. What we proposed instead was reading the accelerometer, so that after movement followed by a sudden stop the app asks whether the person has been in an accident. We separated what's needed at the scene from what can wait. An exploded diagram of the car, like the one on a rental agreement, lets people tap the areas where photos are needed. Voice recordings replaced typed witness statements, transcribed later somewhere calm. Apply the same logic to crashes. Ask what the app is demanding of the device, then remove the demand. ## Feature Scope as a Crash Risk Every feature you add is more code paths, more memory use, more third-party libraries and more surface for device-specific faults. Scope is a stability question long before it's a budget question. We worked on a well-funded sports club app, built to handle finances, games, schedules and players across a range of sports. We advised launching with one sport, on one platform, as an MVP. The client pushed back through the entire process. They didn't want to launch until everything was ready, didn't want a single sport, didn't want a single platform, didn't want an MVP. They wanted everything, which set the conditions for [scope creep that ran away from the project](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi). The stability cost of that stance is simple arithmetic. A build covering four sports, two platforms and a payments layer has many more ways to fail on an unusual handset than a build covering one sport on one platform, and far less time per path to test any of them. Offline support is the clearest example of a feature worth refusing unless it genuinely matters. On the backpacking product it was the difference between a usable app and a useless one. On a product people only open on home wifi, it's extra complexity bringing extra crashes. ## Testing Across a Real Device Matrix A device matrix is a short, honest list of what you test before every release. Short matters, because a list of forty devices gets skipped and a list of eight gets used. Build it from your own analytics rather than from general market data. Your audience isn't the average audience, and a beauty brand's user base looks nothing like a grassroots sports product's. 1. Your three highest-volume devices, whatever they are. 2. The oldest handset and oldest OS version you've committed to supporting. 3. One device from each manufacturer with a heavy software layer on top of Android. 4. One small screen and one large or foldable screen. 5. Whichever device currently generates the most crash reports. Run the matrix in real conditions. Low storage, poor signal, backgrounding the app mid-task, incoming calls, an OS update halfway through. Cloud device farms cover breadth cheaply and physical handsets catch what they miss, so a small shelf of real phones alongside a cloud service covers most of it. Put one genuinely old, cheap handset on every tester's desk and make it the default device for first-pass testing. Problems surface there first. ## Releasing the Fix Without Making Things Worse A crash fix is a change to the code that was already failing for some people, so shipping it to everyone at once doubles your exposure. Stage it instead. Release to a small percentage first, filtered to the affected devices where the platform allows it. Watch the crash-free session rate for that group against everyone else for a few days before widening. Both app stores support phased rollout, and the halt button only helps if you're actually watching the numbers. > Ship to a small slice first and watch the crash-free rate move before you widen. Keep each release small enough that you can tell what caused what. A build containing one crash fix gives you a clean read. A build containing the fix plus four new features gives you a guess. This is the same lesson the sports club project taught us from the other direction. Working with an incremental process, releasing in stages and listening to the development advice you're paying for is what gets a product live and keeps it stable. Projects that insist on everything at once are at serious risk of never launching at all, and the ones that do launch arrive without any of the safety nets that staged releases give you. ## Looking After the Users Already Affected By the time you've diagnosed a device-specific crash, a group of people have already had a bad run with your app. Fixing the code doesn't bring them back on its own, because most of them never told you anything was wrong. Reach out directly where you can. Push notifications and email to the affected device group, saying plainly what went wrong, that it's fixed, and what to do next. Reopen the support tickets that touched the issue, even the ones closed months ago. Segment the message by device model so the people who were never affected don't receive an apology for a problem they didn't have. Watch the wording. On a [genetics wellness app we worked on](https://weareaffective.com/learning-centre/why-a-genetics-products-error-states-were-rewritten-before-they-could-appear), one of the most effective things we did was pre-framing anything people found odd, rather than letting them meet it cold and decide the product was broken. We rewrote copy to say things like "this is to be expected" and "everyone is different", which stopped the error state forming in someone's head in the first place. Head off the worry before it arrives, and you don't have to repair it afterwards. Then keep reading support requests for the following month. They'll tell you whether the fix landed long before your dashboard does. ## Conclusion A crash that only affects some devices is a useful piece of information once you stop treating it as bad luck. The cluster points at the cause. Older hardware points at memory and storage, one manufacturer points at the software layer they've added, one OS version points at a changed API, and a scattered pattern tied to a region usually points at the connection. The work in between follows a steady order. Collect the session context around each crash, read your support requests alongside it, get the actual failing handset in your hand, reproduce the fault in real conditions, fix the demand your app is making rather than the line where it gave up, then release the fix in stages while you watch what happens. Underneath all of it sits a scope decision. Fewer features, running properly on a clearly defined set of devices, will beat a longer feature list that falls over on a third of the handsets your audience owns. Decide which phones you support, say so out loud, and build for those. If your app keeps crashing on particular devices and you've run out of ideas about why, [let's talk about what your crash data is showing](https://weareaffective.com/get-started). ## Frequently Asked Questions Why does my app crash on some devices but work perfectly on others? Device-specific crashes are rarely random. Something in your build is making an assumption about memory, screen size, operating system version or connection quality that one group of phones doesn't match. The fact that the crashes cluster around particular devices is itself half the diagnosis. What does the pattern in my crash data actually tell me? If one manufacturer is over-represented across many models, you are usually looking at custom OS behaviour such as background limits or battery saving. Older models only tends to mean memory or storage pressure, a single OS version points to a changed or removed API, and mixed devices in one region usually means connection quality and your timeout or retry logic. What information should I gather before I start changing code? Collect the full session context around each crash, not just the stack trace. That means device model and manufacturer, OS version, free storage, available memory, battery state, connection type, app version and the few screens the user passed through beforehand. The stack trace tells you where the app gave up, but the context tells you what the phone was doing at the time. Is the standard crash report enough on its own? Usually not, because most teams read the top line and stop there. The stack trace shows the point of failure but not the conditions that caused it, and device-specific faults almost always live in those conditions. You need the session data around the crash to make sense of it. When should I log memory and storage figures? Log free storage and available memory at the moment of the crash rather than at app launch. On older handsets the gap between those two numbers is frequently the entire explanation for the failure. Can support tickets help me find device-specific bugs? Yes, support requests often carry patterns that crash reporting tools miss entirely. Read a month of them together and look for a recurring theme, then work backwards to the specific feature or point of confusion in the app. Bear in mind that people describe symptoms rather than causes, so several differently worded complaints may all point to the same fault. How much does a crash really cost me commercially? The cost is high and largely invisible, because users who crash out rarely tell you why. According to Alphabin, 62% of users uninstall apps after crashes, freezes or errors, so most of the damage happens without a single bug report being filed. Do I need to support every device my users might own? No, but you do need to make that decision deliberately rather than by accident. Work out which devices your actual audience holds, which can differ sharply from the handsets sitting on your team's desks, then decide what you will genuinely support and test against that list. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.