On a low end phone your app gets more time per frame and far less room to use it.

What actually gets harder when the phone is slower?

Start with the thing that does not change. Android's slow rendering guidance says an app must render frames in under 16ms to reach 60 frames per second, that the window drops to 11ms at 90fps and 8ms at 120fps, and that overrunning by 1ms does not make the frame late: the Choreographer drops it entirely. A 60Hz panel hands you the most generous figure on that list, and the cheaper the phone the more likely that is the panel it has. The flagship in your pocket, running at 120Hz, is working to half of it. Whatever is wrong on the cheap phone, a tight deadline is not it.

What changes is how much fits inside the window. React Native's performance guide is blunt about where your code runs: for most apps, your business logic runs on the JavaScript thread, which is where your React application lives, where API calls are made and where touch events are processed. One thread. The guide's own illustration is a state change on a complex tree that takes 200ms and drops 12 frames, with any JavaScript-driven animation appearing to freeze for that whole time. That example is an illustration rather than a measurement, and the point survives either way: the same render costs more of the window on a slower processor, and the work does not get interleaved with anything.

Some things survive a blocked JavaScript thread and some do not, and the split explains most of what users report. The same guide notes that a ScrollView keeps scrolling while the JavaScript thread is locked up, because the ScrollView lives on the main thread and the scroll does not wait for your code to acknowledge it. Native stack navigators behave better than JavaScript ones for the same reason: the transition runs on the native main thread. So a complaint that scrolling is fine but tapping does nothing is a JavaScript thread problem, and a complaint that the whole screen stutters while nothing is happening is usually not.

One React Native note is specifically about weak graphics hardware. Moving a view can drop main-thread frames, and the guide says this is especially true on Android when you have text with a transparent background positioned on top of an image, or any other situation where alpha compositing would be required to redraw the view on each frame. Its fix is to let the platform cache the view as a texture, with a warning attached: do not overuse it or your memory use could go through the roof. That is the trade you will meet repeatedly on cheap hardware. Every fix for a frame problem spends memory, and memory is the thing you have least of.

React Native, Performance Overview, page dated 12 August 2026, read 17 October 2026

Why does it run out of memory before it runs out of speed?

Because the ceiling is hard and the slowdown is gradual. Android's memory management overview says that to maintain a functional multi-tasking environment, Android sets a hard limit on the heap size for each app, that the exact heap size limit varies between devices based on how much RAM the device has available overall, and that an app which reaches heap capacity and tries to allocate more can receive an OutOfMemoryError. There is no published table of limits per phone. The documented way to find yours is to ask the device at runtime, through a call that returns the number of megabytes available for your app's heap. That page carries a last-updated date of 19 May 2026.

Garbage collection is the part that connects memory back to dropped frames. The same page says the system decides when to collect, that you do not generally control it from your code, and that a collection landing in the middle of an intensive loop such as an animation can push your code past the recommended 16ms threshold for smooth frame rendering. It then names the pattern that causes it: allocating many objects in the innermost part of a loop on every frame. On a phone with a small heap you reach that state sooner, so the stutter and the crash have the same cause and arrive in that order.

Then there is being killed outright. Android's low memory killer page, dated 21 September 2026, says devices often run with very little free memory by design, and that the low memory killer daemon reacts to high memory pressure by killing the least essential processes to keep the system performing acceptably. It scores processes so background apps go first and system processes last. It also says trim callbacks have not been helpful at preventing low-memory kills, which is why Android deprecated most of them, and that there is no API for detecting native memory pressure events. What you are left with is an exit-reason API that tells you after the fact why the previous run died. iOS describes the same squeeze in its own words: Apple's launch-time guidance says that if someone has just played a memory-intensive game, your app was typically evicted from memory to give the foreground app more, and that your return is then a cold launch.

If you want to know what you are running on, an Expo project has one honest answer available. The Expo device library reports the device's total memory in bytes, with a caveat printed next to it that is the whole lesson: this is the total memory accessible to the kernel, but not necessarily to a single app. It also reports a device year class, which Expo defines by pointing at the open source library of that name rather than by publishing a scale of its own. Both numbers are fine for deciding whether to turn a feature off, and neither is a performance measurement. If you have never added a library to one of these projects, getting started with Expo covers the shape of it.

What do Apple and Google count as a phone that is too slow?

Google answers with a number you choose. Play Console Help says that if you want to exclude devices by performance indicators, you can create targeting rules based on RAM size or System on Chip, and its worked example is a rule that excludes devices with less than 512 MB RAM. Two footnotes do the real work. RAM rules are based on the total memory the device reports rather than the branded memory, so the rule and the number on the box disagree, and a single device model can come back as partially excluded because its variants ship with different memory. And device exclusion rules do not apply to internal testers, so the track most first builds go to is the one no rule can filter.

Google also names an entry-level tier outright. Android (Go edition) covers entry-level devices running Android 8.1 or higher with 1 GB of RAM or less, and the Play Console carries an Android Go exclusions setting next to the other rules. Android's API reference puts the same figure in developer terms: the low-RAM check has existed since API level 19, returns true if this is a low-RAM device, and is hedged twice in one sentence, because whether a device is low-RAM is ultimately up to the device configuration and currently generally means something with 1GB or less of RAM. Treat it as a hint for turning features off, which is what the reference says it is mostly intended for: deciding whether to turn off certain features that require more RAM.

Apple answers with a capability instead of a number. Its support documentation says the App Store uses values in the required device capabilities property list key to work out the hardware-related capabilities an app needs, so that people only download apps their device supports. The published list of those keys, as it stood on 17 October 2026, is almost entirely hardware features: a camera flash, a gyroscope, NFC, telephony, a graphics API. Three of them are performance floors, two naming a chip generation and one a gaming tier. None of them is an amount of memory. So on iOS you can refuse a device because of what silicon it has, and you cannot refuse it for having too little RAM.

Both of these are blunt instruments, and reaching for either is a decision about your market rather than a fix. Google says an excluded device will not be able to see or install your app on Google Play at all, so the rule removes the customer rather than the crash. The ordinary answer is to support the phone and do less on it, which is why the low-RAM check and the device year class exist in the first place. Doing less on it is also a recurring cost rather than a one-off piece of work, and it belongs in the same budget line as what an app costs to maintain.

Google Play Console Help, view and restrict your app's compatible devices, read 17 October 2026

How do you test on a phone you do not own?

Rule one, before you buy anything: measure a release build. React Native's performance guide says JavaScript thread performance suffers greatly in development mode, that this is unavoidable because far more work happens at runtime to give you good warnings, and to always test performance in release builds. The same guide treats console logging as a serious bottleneck on the JavaScript thread and recommends stripping those calls from production builds even if your own code makes none, because a third-party library could. React Native's loading guidance adds the reason the gap is so wide: in release builds the JavaScript is compiled to bytecode ahead of time and loaded on demand, rather than parsed as the app starts. A debug build on a cheap phone is the worst measurement available, and it is the one most people take.

Rule two: use the field data you already have. Apple's guidance on shipping apps says the Xcode Organizer shows anonymised performance data from your users, including launch times, memory use and responsiveness, and that you can filter a metric by device and by median or high value. Launch time comes with a 50th and a 90th percentile. Hang rate is reported as the seconds per hour your app is unresponsive, counting only periods longer than 250 ms. Apple then says the sentence this entire page exists to repeat: its operating systems support a broad variety of devices with different hardware capabilities, and code that performs flawlessly on one hardware model can hang on another. Google's device catalog is the same tool with a different shape, listing per-model metrics for your app alongside a breakdown of that model by memory and Android version.

Rule three: know what each platform calls a failure, because the thresholds are not close. Android separates a slow frame, which takes between 16ms and 700ms, from a frozen frame, which takes between 700ms and five seconds, from an application-not-responding event past five seconds, and says no frame in your app should ever take longer than 700ms. Apple starts counting a hang at 250 ms. If you are trying to agree with a client on whether an app is acceptable, those are the published lines to argue from, and they are the reason the same app can be inside tolerance on one store and outside it on the other.

Rule four: if you cannot get the handset, simulate the condition. Apple is direct that you get higher-fidelity measurements by profiling on a device rather than a simulator, and that if your data shows the app performing poorly on a particular class or model of device, you should profile on that device. Where that is impossible, Android documents a memory stress tool you push to the phone over adb and run for a set number of seconds against a set number of megabytes, specifically so you can reproduce a memory-stressed environment and write tests against it. It also lists what you will see when you do: a native abort, a core dump, or a trim callback. Fixes for all of this often arrive as a version bump rather than as code you write, which is what the Expo SDK release notes are for reading before you start optimising by hand.