Panduan Master Expo Pemberitahuan Push 2026

Anda mungkin sudah mencapai titik di mana aplikasi berfungsi, pengguna telah masuk, dan produk sekarang ingin aliran kembali yang terasa asli. Pengingat keranjang. Prompt tinjauan. Peringatan pesan baru. Pengumuman rilis. Insting pertama sering kali adalah untuk "menghubungkan push," lalu seminggu kemudian Anda sedang menggugurkan mengapa perangkat tertentu menerima peringatan, simulator tampaknya mendaftar dengan baik, dan tidak ada yang dapat menjelaskan mengapa sentuhan tidak membuka layar yang tepat.

Itu di mana pemberitahuan push Expo adalah sederhana atau rapuh.

Expo memberikan lapisan praktis atas APNs dan FCM, yang tepat mengapa banyak tim menggunakan itu. Namun, gap antara demo dan implementasi siap produksi nyata. Siklus token, waktu izin, pengaturan pendengar, desain payload, dan pembersihan backend semua berperan. Jika Anda juga mengirimkan perubahan logika aplikasi yang sering, kebutuhan untuk disiplin operasional menjadi lebih tajam, terutama jika pekerjaan peningkatan retensi Anda bergantung pada pesan yang dapat diandalkan dan kecepatan rilis. Itu adalah kekhawatiran yang lebih luas di balik Pengembangan Aplikasi Pengguna Retensi Mobile: Pengiriman hanya berguna jika pengalaman pengguna di sekitarnya dapat diprediksi.

Peta Kandungan

• Dasar untuk Menghubungkan Pengguna dengan Notifikasi Push Expo
  • Apa yang sebenarnya diabstraksi oleh Expo
  • Apa yang sebenarnya berarti siap produksi
• Pengaturan Awal dan Konfigurasi Proyek
  • Instal paket notifikasi
  • Tambahkan konfigurasi tingkat proyek
  • Atur pengolah notifikasi awal
  • Android memerlukan konfigurasi saluran
• Mengajukan Izin dan Mengabadikan Token Push
  • Fungsi klien yang harus menjadi dasar Anda
  • Mengapa Device.isDevice tidak optional
  • Minta izin pada saat yang tepat
• Mengirimkan Pemberitahuan dari Server Anda
  • Apakah setiap bidang payload harus lakukan
  • Pastikan payload kecil dan membosankan
  • Habits server yang berguna
• Menangani Pemberitahuan Masuk di Aplikasi Anda
  • Penerimaan latar depan dan respons pengguna adalah peristiwa yang berbeda
  • Baca payload data dan navigasikan dengan sengaja
  • Perilaku latar depan harus sesuai dengan konteks pengguna
• Praktik Terbaik Produksi dan Kesalahan Umum
  • Token-token itu sementara, bukan catatan identitas
  • Strategi refresh lebih penting daripada yang sebagian besar tutorial akui
  • Keamanan dan kinerja tidak boleh berada di akhir sprint
  • Apa yang biasanya berhasil dan apa yang biasanya gagal

Dasar untuk Menggugah Pengguna dengan Notifikasi Push Expo

Suatu Notifikasi push Pengaturan Expo menarik karena satu alasan di atas semua. Ini menghilangkan banyak kompleksitas pesan native yang tim tidak ingin miliki pada hari pertama. Sebaliknya, Anda dapat bekerja dengan gateway Expo dan fokus pada perilaku produk, routing, UX izin, dan logika pesan backend.

Abstraksi ini tidak membuat push “kurang nyata.” Ini hanya mengubah tempat upaya insinyur Anda.

Pelayanan ini juga cukup cepat sehingga kinerja biasanya bukan hal pertama yang perlu dikhawatirkan. Dari 14 Maret 2023 hingga 12 Juni 2023, notifikasi push Expo API menunjukkan waktu respons median 42 milisekon 273 milisekon latency p99, 42 milisekon waktu respons mediandan sejumlah 0,17% per hari di seluruh context: Halaman perbandingan Capawesome. Area: Halaman perbandingan Capawesome. Peran: Paragraf pemasaran atau hukum yang panjang. Dilihat di: halaman capwesome.astro. Simpan istilah produk/brand dan istilah developer Capgo secara tepat. Kunci pesan `capwesome_diff_experience_capgo` (Capwesome Diff Experience Capgo).jutaan pesan sehari Knock’s Expo push API benchmark analysisanalisis benchmark Knock untuk __CAPGO_KEEP_0__ push Expo

. Ini akan menenangkan tim yang bertanya-tanya apakah Expo hanya cocok untuk prototipe.

Apa yang sebenarnya diabstraksi Expo

• Ketika tim mengatakan “push Expo,” mereka sering kali berarti beberapa kekhawatiran yang terpisah yang digabungkan: Routing penyedia: Expo mengalihkan pesan ke untuk iOS dan FCM untuk Android.
• Format token: Pelayanan server Anda menyimpan dan mengirimkan Token Push Expo daripada mengelola token spesifik platform terlebih dahulu.
• Kontrak permintaan: Anda mengirimkan payload ke Expo’s push API bukan langsung mengintegrasikan API penyedia native.

Itu membantu, tetapi juga menciptakan kesalahpahaman umum. Tim kadang-kadang asumsi Expo menguasai setiap masalah pengiriman. Dalam prakteknya, banyak gagal datang dari aplikasi code, token yang kadaluarsa, payload yang rusak, atau aliran izin yang buruk.

Aturan praktis: Tangani Expo sebagai lapisan transportasi yang dapat diandalkan, bukan sebagai pengganti desain klien dan backend yang baik.

Apa yang sebenarnya berarti siap produksi

Demo yang berfungsi hanya membuktikan bahwa satu perangkat menerima satu payload sekali. Siap produksi berarti sesuatu yang lain:

Perbedaan antara "pengiriman pemberitahuan" dan "pemberitahuan mendukung alur kerja produk nyata."

Pengaturan Awal dan Konfigurasi Proyek

Banyak rasa sakit Expo push dimulai sebelum prompt izin pertama. Jika konfigurasi proyek Anda longgar, klien code dapat terlihat benar sementara aplikasi masih berperilaku tidak konsisten di antara build.

Mulai dengan library yang tepat terinstal dan lingkungan pengembangan yang sesuai dengan jalur build. Jika Anda bekerja di luar Expo Go, membantu untuk menyelaraskan alur kerja lokal dengan pengaturan klien pengembangan Expo yang disesuaikan Mulai dengan library yang tepat terinstal dan lingkungan pengembangan yang sesuai dengan jalur build. Jika Anda bekerja di luar Expo Go, membantu untuk menyelaraskan alur kerja lokal dengan pengaturan klien pengembangan Expo yang disesuaikanKarena perilaku notifikasi sering perlu diverifikasi dalam build yang lebih mirip produksi daripada jalankan sandbox yang cepat.

Instal paket notifikasi

Setidaknya, Anda biasanya memerlukan:

• expo-notifications untuk permintaan izin, pengambilan token, pemantauan, dan presentasi notifikasi.
• expo-device Karena Anda harus menjaga pengambilan token dengan Device.isDevice.

Perintah instalasi biasanya bergantung pada manajer paket Anda, tetapi kunci adalah sinkronisasi versi dengan Expo SDK. Jangan campuradukkan versi paket acak. Biarkan Expo menyelesaikan yang kompatibel.

Tambahkan konfigurasi pada tingkat proyek

Jaga konfigurasi Anda eksplisit. Minimal app.json atau app.config.js context

{
  "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"
      }
    }
  }
}

Karena Anda harus menjaga pengambilan token dengan

• Sebuah beberapa hal yang penting di sini: perlu sesuai dengan aplikasi yang sebenarnya Anda kirim.
• The plugin notifikasi memastikan proyek native mendapatkan konfigurasi yang diperlukan selama pembangunan.
• The ID proyek EAS berperan ketika pengambilan token menunggu aplikasi terkait dengan proyek Expo yang benar.

Setelah handler notifikasi pada awalnya

Banyak tutorial dasar menunda terlalu lama untuk mendefinisikan perilaku notifikasi. Jangan. Letakkan dekat awal aplikasi sehingga perilaku latar depan dapat diprediksi.

import * as Notifications from 'expo-notifications';

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

Tim memutuskan apakah notifikasi latar depan harus menampilkan peringatan, memainkan suara, atau mempengaruhi tombol. Perilaku yang tepat tergantung pada produk. Aplikasi obrolan dan aplikasi pembayaran tidak akan membuat pilihan yang sama.

Jika Anda tidak mendefinisikan perilaku latar depan secara sengaja, tim Anda akan berakhir mengdebug notifikasi yang hilang yang sebenarnya diterima tapi tidak pernah ditampilkan seperti yang diharapkan produk.

Android memerlukan konfigurasi saluran

Saluran notifikasi Android tidak optional dalam prakteknya. Jika Anda melewatinya, peringatan Anda dapat terlihat tidak konsisten atau gagal untuk sesuai dengan harapan 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,
  });
}

Setelah ini selama inisialisasi aplikasi. Lalu jaga ID saluran stabil. Mengubahnya secara santai membuat perilaku notifikasi lebih sulit untuk dipahami nanti.

Mengajukan Izin dan Mengambil Token Push

Bagian ini sering diambil dari kode snippet, lalu akhirnya menyesal.

Permintaan izin memerlukan waktu yang tepat, kesadaran platform, dan pengelolaan async yang disiplin. Pengambilan token harus dilakukan hanya pada perangkat fisik, hanya setelah izin diresolusi, dan hanya jika Anda siap menyimpan hasilnya di backend Anda segera.

Fungsi klien yang harus menjadi titik awal Anda

Gunakan fungsi seperti ini sebagai titik awal Anda:

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 penting. Anda memeriksa jenis perangkat terlebih dahulu, mengatur perilaku kanal Android, menyelesaikan izin, memvalidasi konfigurasi proyek, kemudian meminta token Expo.

Mengapa Device.isDevice tidak boleh diabaikan

Hal ini salah satu kesalahan yang menciptakan banyak kebisingan sementara terlihat tidak berbahaya. Tim ahli hanya meminta izin kondisional ketika Device.isDevice adalah benar, dan salah satu kelemahan umum adalah melewatkan guard tersebut, yang menyebabkan pengembang mengirim notifikasi ke token simulator yang tidak valid dan menyalahkan Expo ketika masalah sebenarnya adalah konfigurasi aplikasi, seperti yang dijelaskan di Eagerworks’ Implementasi Notifikasi Expo Catatan.

Alasan itu, periksaan dilakukan di atas fungsi. Jangan sembunyikan di bantuan. Buatlah jelas.

Hasil simulator berguna untuk tes UI. Mereka tidak dapat dipercaya untuk memvalidasi pendaftaran token push.

Berikan izin pada saat yang tepat

Jangan bertanya pada layar splash. Jangan bertanya sebelum pengguna memahami nilai. Waktu yang terbaik biasanya setelah aksi pengguna yang membuat manfaat notifikasi konkrit, seperti mengaktifkan update pengiriman, bergabung dalam percakapan, atau menyimpan item yang ditonton.

Implementasi yang baik biasanya mengikuti alur ini:

1. Pengguna mencapai batasan fitur yang bermakna.
2. Aplikasi menjelaskan nilai notifikasi dalam UI sendiri.
3. Aplikasi meminta izin sistem.
4. Aplikasi menyimpan token di backend segera jika izin diberikan.

Langkah terakhir itu adalah di mana banyak aplikasi gagal. Mereka mengambil token, merekamnya secara lokal, dan menunda registrasi backend. Kemudian, dukungan tidak dapat mengetahui perangkat mana yang memiliki token mana pada saat tertentu.

Contoh sederhana dari 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 bagian workflow yang lebih lanjut, panduan ini adalah referensi visual yang membantu:

Untuk tim yang membangun aplikasi dengan perilisan yang berat, juga membantu untuk berpikir bahwa pendaftaran token sebagai bagian dari keadaan operasional aplikasi, bukan hanya bagian dari proses onboarding. Mindset ini sesuai dengan alur kerja aplikasi Expo yang lebih luas, di mana perilaku aplikasi dapat berubah sering dan keadaan backend harus tetap sinkron.Mengirimkan Pemberitahuan dari Server Anda

Setelah backend Anda memiliki token push Expo yang valid, mengirimkan pemberitahuan menjadi lebih mudah. Bagian yang sulit bukanlah permintaan itu sendiri. Itu adalah menentukan apa yang harus ada di payload dan seberapa banyak kepercayaan yang Anda berikan pada keadaan klien.

Contoh Minimal dengan Node

Contoh di atas 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;
}

Apakah setiap bidang payload harus melakukan apa?

Jangan biarkan payload menjadi tempat sampah. Pastikan setiap bidang memiliki tujuan.

Objek ini adalah di mana alur kerja produk menjadi berguna. Anda dapat melewatkan jenis dan ID rekaman, kemudian biarkan aplikasi mengambil data terbaru ketika pengguna mengetuk. Itu lebih aman daripada menyematkan blob besar atau sensitif secara langsung ke dalam muatan. data Ini

Jaga ukuran payload kecil dan membosankan

Mengikuti panduan Courier untuk pemberitahuan Expo, Token Push Expo harus dianggap sebagai sementara, payload yang melebihi batasan ukuran sekitar 4 KB dapat ditolak, dan pola yang dapat diandalkan adalah mengirimkan payload metadata kecil seperti { "type": "new_review", "id": 123 } daripada JSON besar atau media inline. Saran itu sesuai dengan apa yang berfungsi di sistem nyata. Payload kecil gagal kurang sering dan bertahan lebih baik ketika logika aplikasi berubah.

Kirimkan cukup data untuk menentukan pengguna. Ambil sisa data setelah aplikasi dibuka.

Hal-hal berguna di server

Fungsi kirim dasar cukup untuk tes. Fungsi produksi biasanya menambahkan beberapa tanggung jawab:

• Simpan upaya kirim: Simpan niat pemberitahuan dengan ID pengguna, token, jenis payload, dan tanggal.
• Jangan campur aduk antara penghasilan konten dan transportasi: Bangunlah salinan pesan di satu lapisan dan permintaan Expo API di lapisan lain.
• Handle feedback invalidasi: Jika Expo kemudian melaporkan DeviceNotRegisteredtandai token itu sudah ketinggalan zaman dan berhenti mencoba secara acak.
• Gunakan desain yang ramah webhook: Jika sistem Anda sudah mengirimkan event, arahkan trigger notifikasi melalui pola pengolahan webhook backend yang sama seperti yang digunakan di tempat lain. Sebelum memulai debugging listener klien, kirimlah notifikasi uji manual terlebih dahulu. Jika token menerima notifikasi biasa dengan payload kecil, jalur transportasi Anda mungkin sehat. Jika tidak, jangan mulai dengan mengubah navigasi __CAPGO_KEEP_0__. Mulai dengan memvalidasi token, bentuk payload, dan status izin. Pengelolaan Notifikasi Masuk di Aplikasi Anda

Before debugging client listeners, send a manual test push first. If a token receives a plain notification with a tiny payload, your transport path is probably healthy. If not, don’t start by changing navigation code. Start by validating the token, payload shape, and permission state.

Pengelolaan Notifikasi Masuk di Aplikasi Anda

Pengiriman hanya setengah fitur. Aplikasi harus melakukan sesuatu yang kohesif ketika notifikasi datang dan ketika pengguna mengetuknya.

Artinya, menangani dua momen yang berbeda:

• pemberitahuan tiba ketika aplikasi terbuka
• pengguna berinteraksi dengan pemberitahuan dari tray sistem atau layar kunci

Penerimaan dan respons pengguna dalam keadaan depan adalah dua kejadian yang berbeda.

Konfigurasi yang dapat diandalkan biasanya mencakup kedua pendengar:

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 ketika aplikasi aktif. addNotificationResponseReceivedListener berjalan ketika pengguna mengetuk pemberitahuan yang telah dikirim. Jangan kombinasikan mereka secara mental. Mereka berfungsi pada jalur UX yang berbeda.

Baca payload data dan navigasikan secara sengaja.

Berikut adalah pola praktis untuk menangani ketukan:

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 stabil karena payload berisi petunjuk navigasi, bukan dokumen utuh. Jika urutan telah berubah sejak pemberitahuan dikirim, aplikasi dapat mengambil status server saat ini setelah navigasi.

Pemberitahuan yang diketuk harus menuju satu tujuan yang jelas. Jika jalur cadangan Anda tidak jelas, pengguna akan menyadari segera.

Perilaku latar belakang harus sesuai dengan konteks pengguna

Jika aplikasi sudah terbuka, menampilkan peringatan sistem secara acak dapat terasa tidak nyaman. Terkadang langkah yang tepat adalah menampilkan banner aplikasi, memperbarui badge, atau memperbarui secara diam-diam. Layar inbox dukungan mungkin tidak memerlukan peringatan yang terlihat ketika pengguna sedang membaca percakapan tersebut.

Itulah mengapa pendengar latar belakang Anda harus bercabang berdasarkan rute dan jenis notifikasi. Misalnya:

• Layar chat terbuka: tambahkan pesan dan hindari menampilkan banner yang tidak perlu
• Layar dashboard terbuka: tampilkan notifikasi ringan di dalam aplikasi
• Kegiatan akun kritis: tampilkan perawatan UI yang lebih kuat

Sistem sederhana 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-konteks ini, pengguna akan merasa lelah dengan notifikasi lebih cepat, bahkan jika pengiriman teknisnya benar.

Praktik Terbaik Produksi dan Kesalahan Umum

Jangan terlalu percaya bahwa Expo push notification yang rusak tidak gagal karena Expo terlalu terbatas. Mereka gagal karena tim asumsi token yang permanen, payload dapat membawa apa saja, dan pembaruan aplikasi tidak akan mempengaruhi logika notifikasi.

Asumsi itu tidak bertahan di produksi.

Token adalah sementara, bukan catatan identitas.

Token Expo Push sebaiknya dianggap seperti sewa, bukan identitas perangkat seumur hidup. Token dapat berputar setelah reinstall, perubahan OS, atau kejadian siklus lainnya. Jika token akhirnya kembali DeviceNotRegistered, backend Anda harus berhenti menganggapnya sebagai aktif.

Model backend yang praktis menyimpan:

• ID pengguna
• platform
• metadata instalasi yang dipisahkan
• token saat ini
• timestamp terakhir dilihat
• status seperti aktif, kadaluarsa, atau dibatalkan

Tidak menyimpan satu lapangan token di tabel pengguna dan menganggapnya sudah selesai. Pengguna memiliki beberapa perangkat, dan perangkat berubah status.

Strategi refresh lebih penting daripada yang sebagian besar tutorial akui

Panduan ekosistem resmi meninggalkan celah operasional nyata di sini. Konten push Expo yang ada sering tidak menjelaskan bagaimana menjaga kevalidan token di seluruh siklus ulasan App Store dan pembaruan OTA , yang sangat penting bagi tim yang mengirimkan perubahan hidup karena keandalan push bergantung pada status token saat ini dan sinkronisasi backend, seperti yang disebutkan didocumentasi push Expo Yang mempengaruhi cara Anda merancang trigger refresh. Waktu yang baik untuk membenahi status token termasuk:.

Launch aplikasi setelah pembaruan

• Masuk pengguna
• Perubahan pengaturan izin
• Kerja rotasi kredential di proses rilis Anda
• status seperti aktif, kadaluarsa, atau dibatalkan
• Alur pemulihan setelah tiket dukungan terkait push

Keamanan dan kinerja tidak boleh berada di akhir sprint

Banyak tutorial Expo fokus pada mekanisme dan mengabaikan risiko operasional. Itu baik untuk aplikasi hobi. Tidak baik untuk produk-produk yang berhubungan dengan kesehatan, fintech, atau perdagangan yang terregulasi.

Diskusi Courier yang berfokus pada bisnis enterprise tentang celah notifikasi Expo menunjukkan kekurangan panduan praktis seputar pencatatan persetujuan, jejak audit, dan pengurangan paparan payload sensitif. Pengambilan sisi teknis langsung adalah sederhana:

• Tidak masukkan data bisnis sensitif ke dalam teks atau metadata notifikasi.
• Catat perubahan persetujuan di server.
• Rekam notifikasi apa yang dikirimkan ke token mana.
• Gunakan ID di payload dan ambil konten yang dilindungi setelah aplikasi dibuka.

Untuk tim yang mengatur operasi rilis dengan disiplin yang lebih luas app store compliance and API security practices__CAPGO_KEEP_0__

Peringatan push adalah pesan yang menghadap pengguna, tetapi juga merupakan masalah sistem yang terdistribusi. Berikan perhatian yang sama seperti yang Anda berikan pada keadaan autentikasi dan event pembayaran.

Apakah yang biasanya berhasil dan apa yang biasanya gagal

Konfigurasi push Expo yang solid tidak rumit. Ini adalah disiplin.

Jika tim Anda mengirimkan perubahan logika aplikasi yang sering dan membutuhkan kontrol yang lebih ketat atas perilaku rilis, pengembalian, dan visibilitas pengiriman, Capgo Pertimbangkan untuk menggunakan Capgo. Ini membantu tim mobile mengirimkan pembaruan dengan cepat tanpa harus menunggu tinjauan toko, yang sangat berguna ketika aliran notifikasi, logika routing, atau perbaikan sisi klien harus mencapai pengguna dengan cepat.