Panduan Lengkap Expo Push Notification 2026

Anda mungkin sudah di titik di mana aplikasi berjalan, pengguna sudah login, dan tim produk kini menginginkan alur re-engagement yang terasa native. Pengingat keranjang. Prompt ulasan. Notifikasi pesan baru. Pengumuman rilis. Insting pertama biasanya “cukup pasang push saja,” lalu seminggu kemudian Anda debug mengapa satu perangkat menerima alert, simulator tampak terdaftar dengan baik, dan tidak ada yang bisa menjelaskan mengapa tap tidak membuka layar yang benar.

Di situlah notifikasi push Expo menjadi sederhana yang menyenangkan atau rapuh yang mengejutkan.

Expo memberikan lapisan praktis di atas APNs dan FCM untuk tim React Native, yang persis mengapa banyak tim menggunakannya. Tapi jarak antara demo dan implementasi siap produksi itu nyata. Siklus hidup token, timing izin, setup listener, desain payload, dan pembersihan backend semuanya penting. Jika Anda juga sering mengubah logika aplikasi, kebutuhan akan disiplin operasional menjadi lebih tajam, terutama jika upaya retensi Anda bergantung pada pengiriman pesan yang andal dan kecepatan rilis. Pengiriman hanya berguna jika pengalaman pengguna di sekitarnya dapat diprediksi.

Table of Contents

• Fondasi untuk Meningkatkan Engagement Pengguna dengan Expo Push Notifications
  • Apa yang sebenarnya diabstraksi Expo
  • Apa arti kesiapan produksi sebenarnya
• Setup dan Konfigurasi Awal Proyek
  • Install package notifikasi
  • Tambahkan konfigurasi level proyek
  • Atur handler notifikasi lebih awal
  • Android butuh konfigurasi channel
• Meminta Permission dan Mengambil Push Token
  • Fungsi client yang seharusnya jadi baseline Anda
  • Mengapa Device.isDevice tidak opsional
  • Minta izin di saat yang tepat
• Mengirim notifikasi dari server Anda
  • Apa fungsi setiap field payload
  • Jaga payload tetap kecil dan sederhana
  • Praktik server-side yang berguna
• Menangani notifikasi masuk di aplikasi Anda
  • Penerimaan foreground dan respons pengguna adalah dua event berbeda
  • Baca data payload dan navigasi dengan tepat
  • Perilaku foreground harus sesuai konteks user
• Praktik Terbaik Produksi dan Jebakan Umum
  • Token bersifat ephemeral, bukan catatan identitas
  • Strategi refresh lebih penting daripada yang diakui kebanyakan tutorial
  • Security dan compliance bukan urusan di akhir sprint
  • Apa yang biasanya berhasil dan apa yang biasanya gagal

Fondasi untuk Meningkatkan Engagement Pengguna dengan Expo Push Notifications

Sebuah Notifikasi push Expo setup-nya menarik karena satu alasan utama: menghilangkan kompleksitas messaging native yang tidak ingin ditangani tim di awal. Daripada membangun plumbing APNs dan FCM langsung, Anda bisa bekerja dengan gateway Expo dan fokus pada perilaku produk, routing, UX izin, dan logika pesan backend.

Abstraksi itu tidak membuat push menjadi “kurang nyata.” Ia hanya mengubah di mana upaya engineering Anda diarahkan.

Layanan ini juga cukup cepat sehingga performa biasanya bukan hal pertama yang perlu dikhawatirkan. Dari 14 Maret 2023 hingga 12 Juni 2023, API notifikasi push Expo menunjukkan waktu respons median 42 milidetik, latensi p99 273 milidetik, dan tingkat error harian rata-rata 0,17% di puluhan juta pesan harian, menurut data Analisis benchmark API push Expo dari Knock. Ini seharusnya meyakinkan tim mana pun yang ragu apakah Expo hanya cocok untuk prototipe.

Apa yang sebenarnya diabstraksi Expo

Saat tim menyebut “Expo push,” mereka sering kali memaksudkan beberapa hal terpisah yang digabung jadi satu:

• Routing provider: Expo meneruskan pesan ke APNs untuk iOS dan FCM untuk Android.
• Format token: Server Anda menyimpan dan mengirim Expo Push Token, alih-alih mengurus penanganan token spesifik platform terlebih dahulu.
• Kontrak request: Anda mengirim POST payload ke push API Expo, bukan mengintegrasikan API provider native secara langsung.

Ini membantu, tetapi juga menimbulkan kesalahpahaman umum. Tim kadang mengasumsikan Expo bertanggung jawab atas semua masalah pengiriman. Dalam praktiknya, banyak kegagalan berasal dari code aplikasi, token yang kedaluwarsa, payload yang tidak valid, atau alur izin yang buruk.

Aturan praktis: Anggap Expo sebagai lapisan transport yang andal, bukan pengganti desain client dan backend yang baik.

Apa arti kesiapan produksi sebenarnya

Demo yang berjalan hanya membuktikan bahwa satu perangkat menerima satu payload sekali. Kesiapan produksi berarti hal lain:

Itulah perbedaan antara “notifikasi terkirim” dan “notifikasi mendukung alur kerja produk yang nyata.”

Setup dan Konfigurasi Awal Proyek

Banyak masalah push notification di Expo dimulai sebelum prompt izin pertama. Jika konfigurasi proyek Anda berantakan, code klien bisa terlihat benar, tetapi aplikasi tetap berperilaku tidak konsisten antar build.

Mulai dengan pustaka yang tepat terpasang dan lingkungan pengembangan yang sesuai dengan jalur build Anda. Jika Anda bekerja di luar Expo Go, membantu untuk menyelaraskan alur rilis Anda dengan panduan alternatif Expo EAS dari Capgo, karena perilaku notifikasi sering kali perlu divalidasi dalam build yang lebih mendekati kondisi produksi dibandingkan sekadar eksekusi cepat di sandbox.

Install package notifikasi

Minimal, Anda biasanya membutuhkan:

• expo-notifications untuk permintaan izin, pengambilan token, listener, dan presentasi notifikasi.
• expo-device karena Anda harus melindungi pengambilan token dengan Device.isDevice.

Perintah instalasi tipikal bergantung pada package manager Anda, tetapi kuncinya adalah keselarasan versi dengan Expo SDK Anda. Jangan mencampur versi paket secara sembarangan. Biarkan Expo menyelesaikan yang kompatibel.

Tambahkan konfigurasi level proyek

Jaga konfigurasi Anda tetap eksplisit. Minimal app.json atau app.config.js seharusnya mencerminkan fakta bahwa notifikasi adalah bagian dari kontrak aplikasi Anda, bukan sekadar tambahan di akhir.

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "plugins": ["expo-notifications"],
    "ios": {
      "bundleIdentifier": "com.example.myapp"
    },
    "android": {
      "package": "com.example.myapp"
    },
    "extra": {
      "eas": {
        "projectId": "your-project-id"
      }
    }
  }
}

Beberapa detail penting di sini:

• Bundle identifier dan nama package harus sesuai dengan aplikasi yang benar-benar Anda rilis.
• Plugin notifikasi memastikan proyek native mendapatkan setup yang diperlukan saat build.
• ID proyek EAS penting saat pengambilan token Anda mengharapkan aplikasi terkait dengan proyek Expo yang benar.

Atur handler notifikasi sejak awal

Banyak tutorial dasar terlalu lama menunda definisi perilaku notifikasi. Jangan tiru itu. Taruh di dekat app startup supaya perilaku foreground bisa diprediksi.

import * as Notifications from 'expo-notifications';

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: false,
    shouldSetBadge: true,
  }),
});

Tim perlu memutuskan apakah notifikasi foreground menampilkan alert, memutar suara, atau memengaruhi badge. Perilaku persisnya tergantung produk Anda. Aplikasi chat dan aplikasi pembayaran tidak akan membuat pilihan yang sama.

Jika Anda tidak mendefinisikan perilaku foreground secara sengaja, tim Anda akan berakhir debugging notifikasi yang “hilang” — padahal diterima, tapi tidak pernah ditampilkan sesuai ekspektasi produk.

Android butuh konfigurasi channel

Di praktiknya, notification channel Android bukan opsional. Kalau dilewati, alert Anda bisa terlihat tidak konsisten atau tidak sesuai ekspektasi pengguna.

import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';

export async function configureAndroidNotifications() {
  if (Platform.OS !== 'android') return;

  await Notifications.setNotificationChannelAsync('default', {
    name: 'Default',
    importance: Notifications.AndroidImportance.MAX,
  });
}

Siapkan ini saat inisialisasi app. Lalu jaga channel ID tetap stabil. Mengubahnya sembarangan bikin perilaku notifikasi makin sulit dipahami nanti.

Meminta Permission dan Mengambil Push Token

Ini bagian yang banyak tim salin dari snippet, lalu akhirnya menyesal.

Permintaan permission butuh timing, kesadaran platform, dan penanganan async yang disiplin. Pengambilan token hanya boleh terjadi di perangkat fisik, setelah permission selesai, dan hanya jika Anda siap langsung menyimpan hasilnya ke backend.

Fungsi client yang seharusnya jadi baseline Anda

Gunakan fungsi seperti ini sebagai titik awal:

import * as Device from 'expo-device';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

type RegisterResult =
  | { ok: true; token: string }
  | { ok: false; reason: string };

export async function registerForExpoPushNotificationsAsync(): Promise<RegisterResult> {
  if (!Device.isDevice) {
    return { ok: false, reason: 'Push notifications require a physical device.' };
  }

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.MAX,
    });
  }

  const permissions = await Notifications.getPermissionsAsync();
  let finalStatus = permissions.status;

  if (finalStatus !== 'granted') {
    const request = await Notifications.requestPermissionsAsync();
    finalStatus = request.status;
  }

  if (finalStatus !== 'granted') {
    return { ok: false, reason: 'Notification permission was not granted.' };
  }

  const projectId =
    Constants.expoConfig?.extra?.eas?.projectId ??
    Constants.easConfig?.projectId;

  if (!projectId) {
    return { ok: false, reason: 'Missing EAS project ID configuration.' };
  }

  const tokenResponse = await Notifications.getExpoPushTokenAsync({ projectId });

  return { ok: true, token: tokenResponse.data };
}

Urutan ini penting. Cek tipe perangkat dulu, atur perilaku channel Android, selesaikan izin, validasi konfigurasi proyek, lalu minta token Expo.

Mengapa Device.isDevice bukan opsional

Ini adalah salah satu kesalahan yang terlihat sepele tapi menimbulkan banyak masalah. Tim ahli hanya meminta izin secara kondisional ketika Device.isDevice bernilai true, dan jebakan umum adalah melewatkan guard tersebut, yang membuat developer mengirim notifikasi ke token simulator yang tidak valid dan menyalahkan Expo, padahal masalahnya ada di konfigurasi aplikasi, seperti yang dijelaskan dalam Catatan implementasi notifikasi Expo dari Eagerworks.

Itulah mengapa pengecekan diletakkan di awal fungsi. Jangan sembunyikan di balik helper. Buatlah jelas.

Hasil simulator berguna untuk pengujian UI. Namun, tidak dapat diandalkan untuk memvalidasi registrasi push token.

Minta izin di saat yang tepat

Jangan minta izin di splash screen. Jangan minta sebelum pengguna memahami nilainya. Waktu terbaik biasanya setelah aksi pengguna yang membuat manfaat notifikasi terasa nyata, seperti mengaktifkan pembaruan pengiriman, bergabung ke percakapan, atau menyimpan item yang dipantau.

Implementasi yang baik biasanya mengikuti alur ini:

1. Pengguna mencapai batas fitur yang bermakna.
2. Aplikasi menjelaskan nilai notifikasi melalui UI Anda sendiri.
3. Aplikasi meminta izin sistem.
4. App menyimpan token di backend segera setelah izin diberikan.

Langkah terakhir ini adalah tempat banyak app gagal. Mereka mengambil token, mencatatnya secara lokal, dan menunda registrasi backend. Nantinya, tim support tidak bisa melacak perangkat mana yang memiliki token apa pada waktu tertentu.

Berikut contoh sederhana untuk menyimpan token setelah registrasi:

export async function enablePushForCurrentUser(userId: string) {
  const result = await registerForExpoPushNotificationsAsync();

  if (!result.ok) {
    return result;
  }

  await fetch('https://api.example.com/push-tokens', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: 'Bearer user-session-token',
    },
    body: JSON.stringify({
      userId,
      token: result.token,
      platform: Platform.OS,
    }),
  });

  return result;
}

Di kemudian hari dalam alur kerja, panduan ini menjadi referensi visual yang membantu:

Bagi tim yang membangun aplikasi dengan rilis intensif, ada baiknya juga menganggap registrasi token sebagai bagian dari state operasional aplikasi, bukan sekadar bagian dari onboarding. Pola pikir ini selaras dengan alur kerja pengiriman aplikasi Expo, di mana perilaku aplikasi bisa sering berubah dan state backend perlu tetap tersinkronisasi.

Mengirim notifikasi dari server Anda

Setelah backend Anda punya Expo Push Token yang valid, mengirim notifikasi jadi mudah. Bagian sulitnya bukan permintaan itu sendiri, tapi menentukan apa yang masuk ke payload dan seberapa besar Anda memercayai state klien.

Berikut contoh minimal bergaya Node menggunakan fetch:

type ExpoPushMessage = {
  to: string;
  title: string;
  body: string;
  sound?: 'default' | null;
  data?: Record<string, unknown>;
};

export async function sendExpoPushNotification(token: string) {
  const message: ExpoPushMessage = {
    to: token,
    title: 'New review received',
    body: 'Tap to open the order details.',
    sound: 'default',
    data: {
      type: 'new_review',
      orderId: 'ord_123',
      screen: 'OrderDetails',
    },
  };

  const response = await fetch('https://exp.host/--/api/v2/push/send', {
    method: 'POST',
    headers: {
      Accept: 'application/json',
      'Accept-encoding': 'gzip, deflate',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(message),
  });

  const result = await response.json();
  return result;
}

Apa fungsi setiap field payload

Jangan jadikan payload tempat sampah. Pastikan setiap field punya tujuan yang jelas.

Panduan data object adalah tempat alur kerja produk jadi berguna. Anda bisa mengirim type dan ID record, lalu biarkan aplikasi mengambil data terbaru saat pengguna mengetuknya. Itu lebih aman daripada menyematkan blob besar atau sensitif langsung di payload.

Jaga payload tetap kecil dan sederhana

According to Panduan Courier tentang notifikasi Expo, Expo Push Tokens harus dianggap sementara, payload yang melebihi batas ukuran sekitar 4 KB bisa dibuang, dan pola yang andal adalah mengirim payload metadata kecil seperti { "type": "new_review", "id": 123 } daripada JSON besar atau media inline. Saran itu cocok dengan yang terbukti di sistem nyata. Payload kecil lebih jarang gagal dan lebih tahan lama saat logika aplikasi berubah.

Kirim data secukupnya untuk mengarahkan user. Ambil sisanya setelah aplikasi terbuka.

Praktik server-side yang berguna

Fungsi pengiriman dasar sudah cukup untuk pengujian. Namun, untuk produksi biasanya ditambahkan beberapa tanggung jawab ekstra:

• Simpan percobaan pengiriman: Simpan intent notifikasi beserta user ID, token, tipe payload, dan timestamp.
• Pisahkan pembuatan konten dari transport: Susun teks pesan di satu layer dan request Expo API di layer lain.
• Tangani feedback invalidasi: Jika Expo kemudian melaporkan DeviceNotRegistered, mark that token stale and stop retrying blindly.
• Gunakan desain yang ramah webhook: Jika sistem Anda sudah memancarkan event, arahkan pemicu notifikasi melalui jenis yang sama pola pemrosesan webhook backend yang Anda gunakan di tempat lain.

Sebelum men-debug listener klien, kirim test push manual dulu. Jika sebuah token menerima notifikasi biasa dengan payload kecil, jalur transport Anda kemungkinan besar sehat. Jika tidak, jangan mulai dengan mengubah navigasi code. Mulai dengan memvalidasi token, bentuk payload, dan status izin.

Menangani notifikasi masuk di aplikasi Anda

Pengiriman hanyalah separuh dari fitur. Aplikasi harus melakukan sesuatu yang koheren saat notifikasi tiba dan saat pengguna mengetuknya.

Itu berarti menangani dua momen terpisah:

• notifikasi tiba saat aplikasi sedang terbuka
• pengguna berinteraksi dengan notifikasi dari system tray atau lock screen

Penerimaan foreground dan respons pengguna adalah dua event berbeda

Setup yang andal biasanya mencakup kedua listener:

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';

export function useNotificationObservers(
  onForegroundMessage: (notification: Notifications.Notification) => void,
  onNotificationTap: (response: Notifications.NotificationResponse) => void
) {
  useEffect(() => {
    const receivedSub = Notifications.addNotificationReceivedListener(
      (notification) => {
        onForegroundMessage(notification);
      }
    );

    const responseSub = Notifications.addNotificationResponseReceivedListener(
      (response) => {
        onNotificationTap(response);
      }
    );

    return () => {
      receivedSub.remove();
      responseSub.remove();
    };
  }, [onForegroundMessage, onNotificationTap]);
}

addNotificationReceivedListener berjalan saat aplikasi aktif. addNotificationResponseReceivedListener berjalan saat pengguna mengetuk notifikasi yang sudah terkirim. Jangan menggabungkannya secara mental. Keduanya melayani jalur UX yang berbeda.

Baca data payload dan navigasi dengan tepat

Berikut pola praktis untuk menangani tap:

type NotificationData = {
  type?: string;
  orderId?: string;
  screen?: string;
};

export function handleNotificationTap(
  response: Notifications.NotificationResponse,
  navigation: any
) {
  const data =
    response.notification.request.content.data as NotificationData;

  if (data.screen === 'OrderDetails' && data.orderId) {
    navigation.navigate('OrderDetails', { orderId: data.orderId });
    return;
  }

  if (data.type === 'new_review') {
    navigation.navigate('Inbox');
    return;
  }

  navigation.navigate('Home');
}

Pola ini tetap tangguh karena payload berisi petunjuk routing, bukan dokumen utuh. Jika pesanan berubah sejak notifikasi dikirim, aplikasi dapat mengambil status server terkini setelah navigasi.

Notifikasi yang ditap harus mengarah ke satu tujuan yang jelas. Jika jalur fallback Anda samar, pengguna akan langsung menyadarinya.

Perilaku foreground harus sesuai konteks user

Ketika aplikasi sudah terbuka, menampilkan alert bergaya sistem secara membabi buta bisa terasa kaku. Kadang langkah yang tepat adalah banner in-app, pembaruan badge, atau refresh diam-diam. Layar inbox dukungan mungkin tidak perlu alert visual jika pengguna sudah membaca percakapan tersebut.

Itulah mengapa listener foreground Anda harus bercabang berdasarkan rute dan jenis notifikasi. Misalnya:

• Layar chat terbuka: tambahkan pesan dan hindari banner yang redundan
• Dashboard terbuka: tampilkan toast in-app yang ringan
• Peristiwa akun kritis: tampilkan penanganan UI yang lebih kuat

Pendekatan sederhana terlihat seperti ini:

export function handleForegroundNotification(
  notification: Notifications.Notification,
  currentRouteName: string
) {
  const data = notification.request.content.data as { type?: string };

  if (currentRouteName === 'ChatThread' && data.type === 'new_message') {
    // refresh local thread state
    return;
  }

  // otherwise show your own in-app UI or update badges
}

Jika aplikasi Anda tidak membedakan konteks ini, pengguna akan lebih cepat mengalami kelelahan notifikasi, bahkan jika pengiriman secara teknis sudah benar.

Praktik Terbaik Produksi dan Jebakan Umum

Sebagian besar setup notifikasi push Expo yang rusak tidak gagal karena Expo terlalu terbatas. Mereka gagal karena tim mengasumsikan token bersifat permanen, payload bisa membawa apa saja, dan pembaruan aplikasi tidak akan memengaruhi logika notifikasi.

Asumsi itu tidak bertahan di produksi.

Token bersifat ephemeral, bukan catatan identitas

Expo Push Token sebaiknya diperlakukan seperti sewa, bukan pengenal perangkat seumur hidup. Token dapat di-rotate setelah instal ulang, perubahan OS, atau event lifecycle lainnya. Jika token akhirnya kembali DeviceNotRegistered, backend Anda harus berhenti memperlakukannya sebagai aktif.

Model backend yang praktis menyimpan:

• ID pengguna
• platform
• metadata per instalasi
• token saat ini
• timestamp terakhir terlihat
• status seperti aktif, stale, atau dicabut

Jangan cuma simpan satu field token di tabel user lalu anggap selesai. User punya banyak device, dan status device bisa berubah.

Strategi refresh lebih penting daripada yang diakui kebanyakan tutorial

Panduan ekosistem resmi masih menyisakan celah operasional nyata di sini. Konten Expo push notification yang ada sering kali tidak menjelaskan cara menjaga validitas token selama siklus review App Store dan OTA updates, yang terutama penting bagi tim yang merilis perubahan live karena keandalan push bergantung pada status token saat ini dan sinkronisasi backend, seperti yang disebutkan dalam dokumentasi Expo notifications.

Hal ini memengaruhi cara Anda merancang trigger refresh. Waktu yang tepat untuk menyelaraskan status token meliputi:

• App launch setelah update
• Login user
• Perubahan pengaturan permission
• Rotasi kredensial di proses release Anda
• Flow recovery setelah tiket support terkait push

Security dan compliance bukan urusan di akhir sprint

Banyak tutorial Expo berfokus pada mekanisme dan mengabaikan risiko operasional. Itu wajar untuk aplikasi hobi. Tapi tidak untuk produk di bidang kesehatan, fintech, atau perdagangan yang diatur.

Diskusi enterprise-focused Courier tentang celah notifikasi Expo menyoroti kurangnya panduan praktis seputar pencatatan consent, audit trail, dan minimisasi paparan payload sensitif. Inti teknisnya sederhana:

• Jangan masukkan data bisnis sensitif ke dalam teks notifikasi atau metadata payload.
• Catat perubahan consent di sisi server.
• Rekam intent notifikasi mana yang dikirim ke token mana.
• Gunakan ID di payload dan ambil konten terlindungi setelah aplikasi dibuka.

Untuk tim yang menyelaraskan operasi rilis dengan cakupan kepatuhan app store dan praktik keamanan API, push harus dimasukkan dalam disiplin review yang sama dengan auth, analytics, dan logging event backend.

Push notification adalah pesan yang ditampilkan ke pengguna, tetapi juga masalah sistem terdistribusi. Perlakukan dengan ketelitian yang sama seperti state auth dan event pembayaran.

Apa yang biasanya berhasil dan apa yang biasanya gagal

Setup push Expo yang solid tidak rumit. Hanya soal disiplin.

Jika tim Anda sering merilis perubahan logika aplikasi dan butuh kontrol lebih ketat atas perilaku rilis, rollback, dan visibilitas pengiriman, Capgo layak dilihat. Ini membantu tim mobile mengirim update dengan cepat tanpa menunggu review store, yang sangat berguna saat alur notifikasi, logika routing, atau perbaikan sisi klien harus sampai ke pengguna dengan cepat.