Learn React Native - Push Notifications & Background Tasks

#Introduction

Notifications are one of the ways an app returns to the user's screen without them opening it. But building push notifications properly isn't just installing a library: there are two different ecosystems, a permission flow, and handlers for three app states.

Episode 11 covers push notifications thoroughly: Firebase Cloud Messaging for Android and APNs for iOS, the permission flow with notifee, notification handlers in foreground, background, and app quit, then background tasks with react-native-background-fetch and a battery-efficient strategy.

#Push Notification Basics

#FCM and APNs

Each platform has its own push service: FCM (Firebase Cloud Messaging) for Android and APNs (Apple Push Notification service) for iOS. Push messages are sent from the server to these services, then forwarded to the device. To simplify with one API, use notifee, which wraps both:

npm install @notifee/react-native

#Device Tokens

When the app first runs, the platform issues a device token — the device's identity in the push service. This token is sent to your server so the server knows where to send notifications. Tokens can change, so always update the server when the app detects a new token.

#Requesting Permission

#The Permission Flow on Android and iOS

iOS requires explicit permission before showing notifications. Android 13+ also requests runtime permission. The flow: check the status, request permission when the user performs a relevant action, then explain why notifications are needed.

Requesting notification permission

import notifee from "@notifee/react-native";
 
async function mintaIzin() {
  const settings = await notifee.requestPermission();
  return settings.authorizationStatus >= 1;
}

Call notifee.requestPermission() when the user chooses a sensible action — for example tapping a "Enable reminders" button — not right when the app opens. The authorizationStatus result determines whether notifications are authorized, denied, or still provisional.

#Notification Handlers

#The Three App States

Notifications need to be handled differently depending on the app state:

• Foreground: the app is visible — show as a banner or handle silently.
• Background: the app is in the background but still alive — the system banner appears automatically.
• Quit: the app is closed — tapping the notification opens the app.

Foreground notification handler

import notifee, { EventType } from "@notifee/react-native";
 
notifee.onForegroundEvent(({ type, detail }) => {
  if (type === EventType.PRESS) {
    bukaLayarNotifikasi(detail.notification.data);
  }
});

detail.notification.data carries the payload sent by the server — use it to navigate to the right screen. This data is also available in the background event for when the app is in the background.

#Creating a Notification Channel on Android

Android uses channels to group notifications. Create a channel during initialization so notifications work on modern Android versions:

Creating an Android channel

import notifee from "@notifee/react-native";
 
async function buatChannel() {
  await notifee.createChannel({
    id: "default",
    name: "Notifikasi Umum",
  });
}

#Background Tasks

#Timed Background Fetch

Not all work can wait for the user to open the app. react-native-background-fetch lets the app run short tasks in the background on a system-defined schedule:

npm install react-native-background-fetch

Scheduling background fetch

import BackgroundFetch from "react-native-background-fetch";
 
async function initBackground() {
  await BackgroundFetch.configure(
    {
      minimumFetchInterval: 15,
      stopOnTerminate: false,
      enableHeadless: true,
    },
    async (taskId) => {
      await sinkronData();
      BackgroundFetch.finish(taskId);
    }
  );
}

The operating system decides when a task runs — minimumFetchInterval is only a lower bound, not a guarantee. Never forget to call BackgroundFetch.finish(taskId), or the OS will consider the task hung.

#Headless Tasks

With enableHeadless: true, the task still runs even if the user terminated the app. Headless tasks use a separate entry point so JavaScript can be executed without a UI. Make sure headless tasks are short and don't touch UI state.

#Battery-Saving Strategies

#Principles of Responsible Work

Background tasks and notifications are serious battery consumers. A few important principles:

• Little and short: don't run background fetch more often than needed.
• Batch requests: combine syncs into one opportunity, not many.
• Leverage OS rules: iOS and Android already manage schedules and priorities — trust the system.
• Avoid notification spam: frequent notifications make users deny permission and uninstall.

#Closing

Episode 11 brought the app to life outside the screen: push notifications with FCM and APNs via notifee, the correct permission flow, handlers for foreground, background, and quit, plus battery-efficient background fetch.

Key takeaways:

• FCM for Android and APNs for iOS; notifee unifies both.
• Request permission at a relevant moment, not on the splash screen.
• Handle notifications for foreground, background, and closed app states.
• BackgroundFetch.finish must be called at the end of a task.
• Background fetch schedules are set by the OS; minimumFetchInterval is only a lower bound.
• Reasonable battery consumption keeps the app in use.

In the next episode, episode 12, we'll discuss media, camera, and permissions: react-native-vision-camera, image picker, image resize and compression, permission management with react-native-permissions, and UX when permission is denied.