Your timers stop when the app leaves the screen, and each platform publishes its own limits for what happens next.

What happens to a setTimeout when someone leaves your app?

It stops, and not because React Native is doing anything unusual. Your JavaScript runs in a thread inside your app's process, and the operating system decides whether that process gets any processor time at all. Once the app is no longer the thing on screen, the answer is mostly no. Apple's UIKit documentation is specific about the first moment: the delegate method called as your app enters the background has five seconds to perform any tasks and return. Five seconds, in Apple's own words, is enough for most apps to do anything crucial, and after that the app is suspended.

If you need longer, you ask for it before you start the work, not when the app is already leaving. Apple exposes no public number for how much you get. It tells you to read the backgroundTimeRemaining property, described as the maximum amount of time remaining for the app to run in the background, and it is blunt about the penalty: if you do not end your tasks in a timely manner, the system terminates your app. Note what that means in practice. The user does not see a crash dialog. They see your app cold start the next time they tap it, which is the same slow first screen covered in app startup time, except now you caused it.

Google starts from a definition rather than a stopwatch. An app is running in the background, it says, if none of its activities are visible to the user and the app is not running any foreground service, and once that is true the system puts a number of restrictions on it, including that in most cases a background app cannot launch a foreground service. On the same page Google warns that ordinary asynchronous work, which is what a promise or a coroutine in your code amounts to, is not guaranteed to finish if the app stops being in a valid lifecycle stage. Both platforms are telling you the same thing in different vocabularies: work you have not explicitly handed to a scheduler does not survive the app going away.

So the honest framing for a handed-over project is this. You do not have a timer problem, you have a bookkeeping problem. Record when something is due, recompute the display when the app becomes active again, and treat any background execution as an optional extra that may or may not happen. Apps written that way need no permissions, no background modes and no review conversation, and they are the ones that still read correctly after a weekend in a pocket.

Apple, choosing background strategies for your app, read 17 October 2026

What does iOS let you run in the background, and for how long?

Apple sorts this by intent rather than by duration, and publishes a figure where there is one. To keep content up to date you schedule an app refresh task, and Apple states that the system decides the best time to launch it and provides your app up to 30 seconds of background runtime, and that you complete the work in that window and report completion or the system terminates your app. For heavy work there is a processing task, described as one that can take minutes to complete, which you schedule and the system runs during periods of low activity, Apple's own example being overnight while the device charges. For work you started in front of the user and must finish, you ask for extra runtime. For a server-driven wake-up there is the silent background push, where your app has up to 30 seconds once the notification is delivered, and Apple warns that sending them more often than three times per hour brings rate limitations.

Read that list again and notice what is missing. There is no entry for keep my process alive so a number can keep decreasing. The closest thing is a background mode, and background modes are tied to a purpose. App Store Review Guideline 2.5.4 says multitasking apps may only use background services for their intended purposes, and names them: VoIP, audio playback, location, task completion, local notifications and the like. Guideline 2.4.2 adds that apps may not run unrelated background processes, such as cryptocurrency mining. Declaring the audio background mode and playing silence so a timer keeps counting is a well-travelled trick, and it is precisely the behaviour those two lines were written to stop.

Apple did eventually ship a real answer for the specific case of alarms. AlarmKit arrived in iOS 26 and is documented as a way to schedule prominent alarms and countdowns to help people manage their time, handling authorisation and supplying its own presentation. It is worth knowing it exists before you build a workaround, with the caveat that it is a native framework with an iOS 26 floor, so your Expo project needs native configuration to reach it and older phones will not have it.

In an Expo project the deferrable side of this is wrapped for you. The background task module in the Expo SDK uses the system task scheduler on iOS and documents the consequences plainly: you may request a minimum interval, which defaults to once every twelve hours and cannot go below fifteen minutes, but the system may run the task later, and on iOS short intervals are often ignored because these tasks tend to run in windows such as overnight. The module also notes that the background tasks API is unavailable on iOS simulators and works only on a physical device, which is why no preview of any kind proves this feature works. Expo also marks the older background fetch module as deprecated, so a generated project using the newer one is on the right side of that migration.

Apple, choosing background strategies for your app, read 17 October 2026

What does Android let you run in the background, and for how long?

Android gives you more rope and more published ceilings. Google splits the ground into asynchronous work, the task scheduling APIs and foreground services, and says that in most cases the right choice for background work is WorkManager. For periodic work that library has a hard floor: the minimum repeat interval that can be defined is fifteen minutes, matching the platform job scheduler, and Google adds that the exact moment a worker runs depends on your constraints and on optimisations the system performs. On the same overview Google notes that a background task taking longer than ten minutes is highly likely to be interrupted, and suggests breaking it into smaller pieces.

Foreground services are the route for work that must happen now, and they come with a notification the user can see, which is the trade. Google puts numbers on two of them. A short service, the type meant to quickly finish critical work, can only run for a short period of time, which Google states as about three minutes, and if it does not stop itself the app receives an ANR. Separately, for apps targeting Android 15 or higher, data sync and media processing services are permitted a total of six hours in a twenty-four hour period, counted separately per type, after which the system calls a timeout method and the service has a few seconds to stop or the system throws a fatal exception. That figure is on Google's foreground service timeout page, which Google last updated on 16 October 2026, so check it before you design around six hours. Bringing the app to the foreground resets that clock. Google's own advice on that page is to use an alternative API such as WorkManager instead of a data sync service.

Then there is the part that catches people after launch, when the phone has been on a bedside table for an hour. Doze suspends network access, ignores wake locks, defers standard alarms to the next maintenance window, does not perform Wi-Fi scans, does not let sync adapters run, and does not let the job scheduler run, which Google spells out means WorkManager tasks do not run either. The system exits briefly for maintenance windows and schedules them less often the longer the device stays idle. Alarms you are allowed to fire during Doze have their own floor: Google states that neither of the allow-while-idle alarm methods can fire more often than once per nine minutes per app. For a long-idle device, Google says idle apps get network access about once a day.

Exact timing has a store policy attached, which is the one most people meet too late. Scheduling something for an exact wall clock time needs an exact alarm permission, and Google Play's policy restricts the version that is granted without a user prompt to apps whose core, user facing functionality requires precisely timed actions. The two examples Google gives are an alarm or timer app, and a calendar app that shows event notifications. Requests are subject to review, and apps that do not meet the criteria are disallowed from publishing on Google Play. If your app is a timer, this is the clean path. If your app merely has a timer in it, plan on asking for the other one, which Google says is no longer pre-granted to most newly installed apps that target Android 13 or higher on a device running Android 14 or higher, and is set to denied by default.

None of this is a React Native limitation, which is worth saying because the instinct after a week of this is to blame the framework. These ceilings belong to the operating systems and apply to any app on the device, written in anything. Choosing a different toolkit moves nothing here, so a comparison like Flutter against React Native is worth reading for other reasons and not for this one.

Android Developers, background work overview, read 17 October 2026, page last updated 26 February 2026

So how do you build a countdown, a reminder or a poll that works?

Four patterns cover nearly everything, and three of them involve your app not running at all. The first is the deadline. Save the absolute moment an interval ends, render the difference between then and now, and recalculate when the app becomes active. React Native's app state listener tells you when that happens. This fixes the countdown, the cooking timer, the trial expiry and the cooldown badge all at once, and it needs no permission from anyone.

The second is the scheduled local notification. You tell the operating system the time and the text, and it delivers the notification whether your app is alive or not. This is the correct answer to ring at seven, your parking expires in ten minutes, and your order is ready. On Android, check the exact alarm permission situation above before you promise the word exact to anyone. On iOS, if the app really is an alarm or timer product, AlarmKit on iOS 26 and later is the purpose-built version.

The third is to move the clock to a server. Anything that has to happen at a moment you do not control, for every user, belongs somewhere that is always awake. The server decides and sends a push, and the app reacts when it next runs. This is also the only honest answer to polling every minute, because both platforms refuse that request in writing: fifteen minutes is the floor on Android, and on iOS the system picks the time and hands you up to thirty seconds.

The fourth is the deferrable scheduler, for making the next launch faster rather than for doing anything at a given time. Register one task, keep it short, make it idempotent, and assume it may be skipped. Expo documents the conditions attached to this: the battery needs enough charge or the device needs to be plugged in, and the network needs to be available, or the task simply will not execute. It also notes that killing the app stops these tasks until the app is started again, and that swiping away in the iOS app switcher fully terminates the app while removing an Android app from recents does not, though vendor behaviour on Android varies. Build it so that a week of the task never firing is a slower first screen and not a wrong number.

The thing to hold on to is that every background capability you add has a cost after launch. A foreground service means a visible notification and battery complaints. A background mode means a review conversation. An exact alarm permission means a Play Console declaration. Each one is a line in the running bill described in what an app costs to maintain, which is a good reason to get there with the deadline pattern and a notification if you possibly can.

Android Developers, background work overview, read 17 October 2026, page last updated 26 February 2026