Battery Drain: Common React Native Mistakes

Key facts, with sources

• The median crash-free session rate across mobile apps in 2025 was 99.95%, with top-performing teams at the 75th percentile holding 99.99%. (Luciq Mobile App Stability Outlook 2025)
• Compared with JavaScriptCore, the Hermes engine cuts typical React Native app startup from about 4.5 seconds to about 2.0 seconds, memory from about 185 MB to 136 MB, and engine app-size overhead from about 12 MB to 8 MB. (OneUptime Blog)
• Real-world production migrations to React Native's New Architecture report around 43% faster cold starts, 39% faster rendering, and 26% lower memory usage. (RapidNative)
• Shopify's performance bar for its React Native apps is critical screens loading in under 500 milliseconds at the 75th percentile, alongside over 99.9% crash-free sessions. (Shopify Engineering)
• Published optimization case studies include Discord cutting app startup time in half and Coinbase reporting an 80% funnel performance improvement after its React Native rewrite. (CatDoes)

Why battery bugs escape your test cycle

Battery problems are invisible in development because nobody develops for eight hours on one charge — the device sits on a cable while you iterate. The damage shows up in aggregate on user devices: the OS attributes energy use per app, users check the battery screen, see your name near the top, and uninstall. Android additionally tracks excessive wakeups and background activity as vitals that can affect store visibility, so drain is a distribution problem as well as a reputation one.

The root cause is almost always the same shape: work that continues when its purpose has expired. A timer serving a screen nobody is looking at, a socket held open for an app in the background, a sensor subscription outliving its feature. Every fix in this post is a variation on making work stop when its reason stops.

Polling that never sleeps

The classic offender is setInterval started at app launch and never reconsidered: refresh a feed, re-check a status, sync a cart — every thirty seconds, forever, including while backgrounded, where each tick can wake the JS engine, hit the network, and power the radio for data nobody sees. Multiply by every screen that added its own timer and the app burns measurable energy doing nothing useful.

Every recurring timer should answer two questions: does this need to run when the app is inactive — almost always no — and is polling even the right mechanism, or should a push or socket deliver changes instead? At minimum, gate timers on AppState so they stop on background and resume on active, and prefer one owner for periodic sync over ad-hoc intervals scattered across screens.

import { AppState } from 'react-native';

useEffect(() => {
  let timer: ReturnType<typeof setInterval> | null = null;

  const start = () => {
    if (!timer) timer = setInterval(syncStatus, 60_000);
  };
  const stop = () => {
    if (timer) {
      clearInterval(timer);
      timer = null;
    }
  };

  start();
  const sub = AppState.addEventListener('change', (state) =>
    state === 'active' ? start() : stop()
  );

  return () => {
    stop();
    sub.remove();
  };
}, []);

Location tracking at maximum everything

GPS is among the most power-hungry components in the phone, and the default posture of copy-pasted location code is worst-case: highest accuracy, continuous updates, no distance filter, running in the background because a permission prompt got approved once. For most product features — showing nearby items, tagging a check-in, sorting by distance — a single fix at coarse accuracy when the screen appears is entirely sufficient.

When you genuinely need continuous tracking, tune it like the scarce resource it is: request the lowest accuracy the feature tolerates, set a distance filter so updates fire on meaningful movement rather than on a schedule, and stop the subscription the moment the feature is not in use. In audits I make teams justify every background-location entitlement; a surprising number exist only because a tutorial included them.

CPU kept hot by invisible work

Rendering costs energy, and React Native offers several ways to render pointlessly. Infinite looping animations — spinners, pulsing badges, shimmer placeholders — that keep running after their content loaded or their screen lost focus force continuous frame production. Re-render storms from over-broad state subscriptions keep the JS thread busy even when the visible UI is static. Keep-awake flags enabled for a video screen and never released prevent the display from ever resting.

The discipline is lifecycle symmetry: everything that starts must have a defined stop. Animations tie to screen focus and stop when data arrives; a screen that is not focused should trigger near-zero renders — verifiable with re-render highlighting while you navigate elsewhere; every keep-awake acquire has a release in a cleanup path. None of these fixes is hard; what is hard is noticing, because the UI looks identical either way.

Networking that keeps the radio awake

Mobile radios have a cost profile developers rarely think about: powering up for a transmission is expensive, and the radio stays in a high-energy state briefly after each transfer. Many small, scattered requests are therefore far worse than the same bytes sent together — an app that fires analytics events individually, refreshes three resources on three timers, and heartbeats a socket every few seconds keeps the radio hot more or less permanently.

Batch what can be batched: queue analytics and flush on an interval or on background transition, coalesce related refreshes into one request cycle, and let the platform's background-transfer mechanisms schedule non-urgent uploads efficiently. Retry logic needs special scrutiny — a failing endpoint retried in a tight loop with no exponential backoff converts one outage into hours of radio-and-CPU burn on every affected device, which is exactly when thousands of devices are affected simultaneously.

Verifying drain before and after fixes

Battery work needs measurement like any other optimization, and the platforms provide the instruments. On iOS, the Xcode energy gauge shows live energy impact by category — CPU, networking, location, GPU — while you exercise the app, and Instruments can attribute sustained CPU to specific call stacks. On Android, the Studio profilers show CPU and network activity over time, and system-level battery statistics reveal wakeups and background behavior across longer sessions.

My acceptance test for any battery fix is behavioral: background the app and confirm CPU, network, and location activity actually go quiet within a few seconds; leave the app idle in the foreground and confirm renders and requests stop. Then watch production signals — OS-reported battery attribution, Android vitals, and review language about heat and battery — to confirm the fleet-wide trend follows the lab result.

When to hire senior help

Bring in a senior performance specialist when your crash-free rate sits below roughly 99.9%, startup exceeds a couple of seconds on mid-range Android, or the team lacks profiling experience with Hermes, the JS thread, and native tooling. Performance rescue work is diagnostic in nature, so a short expert engagement typically finds the handful of hot spots that in-house teams spend months guessing at. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — App Performance Optimization projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Profiling only on high-end iPhones in dev mode, then discovering the real user base on low-end Android devices experiences multi-second startups and dropped frames
• ✕Rendering long feeds with ScrollView or an untuned FlatList instead of a virtualized list like FlashList, blocking the JS thread during scroll
• ✕Passing new inline functions and object literals on every render without memoization, causing cascading re-renders that never show up until lists grow
• ✕Ignoring JS bundle size and startup path, shipping no lazy loading or inline requires, so time-to-interactive balloons as the app grows

Frequently asked questions

Sources

• Luciq Mobile App Stability Outlook 2025
• OneUptime Blog
• RapidNative
• Shopify Engineering
• CatDoes