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 seringkali adalah untuk "menghubungkan push," lalu setelah seminggu Anda sedang menggugurkan mengapa perangkat satu mendapatkan peringatan, simulator tampaknya terdaftar dengan baik, dan tidak ada yang dapat menjelaskan mengapa sentuhan tidak membuka layar yang tepat.

Itu adalah titik di mana pemberitahuan push Expo adalah sederhana atau sangat 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 sama di balik Pekerjaan Retensi Pengguna Aplikasi Mobile: Pengiriman hanya berguna jika pengalaman pengguna di sekitarnya dapat diprediksi.

Daftar Isi

• Dasar untuk Menghubungi Pengguna dengan Notifikasi 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 sebelumnya
  • Android memerlukan konfigurasi saluran
• Mengajukan Izin dan Mengambil 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 yang berguna di sisi server
• Mengolah 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 berfungsi dan apa yang biasanya rusak

Dasar untuk Menghubungi Pengguna dengan Notifikasi Expo

Suatu Notifikasi Expo Pengaturan notifikasi 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: HTML fragment teks dari string Capgo yang lebih panjang (kunci induk `capwesome_diff_experience_capgo`). Halaman/area: Halaman perbandingan Capawesome. Peran: Paragraf pemasaran atau hukum yang panjang. Dilihat di: halaman capwesome.astro. Simpanlah istilah produk/merek dan istilah pengembang 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.

itu seharusnya memberikan kepastian bagi tim yang bertanya-tanya apakah Expo hanya cocok untuk prototipe.

Apa yang sebenarnya diabstrak oleh Expo

• Ketika tim mengatakan “push Expo,” mereka sering kali berarti beberapa kekhawatiran yang terpisah yang digabungkan bersama: 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 pengaturan 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 Proyek Awal dan Konfigurasi

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, pembaruan, 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

• Perlu diingat bahwa notifikasi adalah bagian dari kontrak aplikasi Anda, bukan sesuatu yang dianggap remeh. 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 tepat.

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 Anda. Aplikasi obrolan dan aplikasi pembayaran tidak akan membuat pilihan yang sama.

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

Android memerlukan konfigurasi saluran

Saluran notifikasi Android tidak opsional 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.

Meminta Ijin dan Mengambil Token Push

Mengapa banyak tim mengambil kode dari snippet, lalu kemudian menyesalinya.

Ijin meminta memerlukan waktu, kesadaran platform, dan pengelolaan async yang disiplin. Pengambilan token harus terjadi hanya pada perangkat fisik, hanya setelah ijin 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 saluran Android, menyelesaikan ijin, memvalidasi konfigurasi proyek, kemudian meminta token Expo.

Mengapa ini tidak boleh diabaikan Device.isDevice Salah satu dari sedikit kesalahan yang menciptakan banyak kebisingan sementara terlihat tidak berbahaya. Tim ahli hanya meminta ijin secara kondisional ketika

tidak boleh diabaikan Device.isDevice Kebiasaan ini seringkali dilupakan, yang menyebabkan pengembang mengirim notifikasi ke token simulator yang tidak valid dan menyalahkan Expo ketika masalah sebenarnya adalah konfigurasi aplikasi, seperti yang dijelaskan didan Eagerworks’ Implementasi Notifikasi Expo Catatan.

Alasan itu, periksaan berada di atas fungsi. Jangan sembunyikannya di bantuan. Biarkan jelas.

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

Tanyakan izin pada saat yang tepat

Jangan tanyakan pada layar splash. Jangan tanyakan sebelum pengguna memahami nilai. Waktu yang terbaik biasanya setelah aksi pengguna yang membuat manfaat notifikasi konkrit, seperti mengaktifkan pengiriman update, 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:

For tim yang membangun aplikasi dengan perilisan 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 Alur Kerja Pengiriman Aplikasi Expo, 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 adalah hal yang sederhana. 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 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;
}

Contoh minimal menggunakan

Tujuan Setiap Bidang Payload

Objek 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

Biarkan muatan kecil dan membosankan

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

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

Habits server yang berguna

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

• Simpan upaya kirim: Simpan niat pengiriman dengan ID pengguna, token, jenis muatan, dan tanggal.
• Jangan gabungkan penghasilan konten dengan transportasi: Bangun salinan pesan di satu lapisan dan permintaan Expo API di lapisan lain.
• Handle feedback invalidasi: Jika Expo kemudian melaporkan DeviceNotRegisteredtandai token itu sudah ketinggalan 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 memeriksa penggunaan klien, kirim notifikasi uji manual terlebih dahulu. Jika token menerima notifikasi sederhana 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. Pengaturan 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.

Pengaturan 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 datang ketika aplikasi terbuka
• pengguna berinteraksi dengan pemberitahuan dari tray sistem atau layar kunci

Penerimaan dan respons pengguna dalam keadaan depan berbeda-beda

Konfigurasi yang dapat diandalkan 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 ketika aplikasi aktif. addNotificationResponseReceivedListener berjalan ketika pengguna mengetuk pemberitahuan yang telah dikirim. Jangan gabungkan mereka secara mental. Mereka memiliki jalur UX yang berbeda.

Baca payload data dan navigasikan secara sengaja

Contoh 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 mengandung petunjuk navigasi, bukan dokumen utuh. Jika urutan telah berubah sejak pemberitahuan dikirim, aplikasi dapat mengambil keadaan 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 tanpa mempertimbangkan konteks pengguna dapat terkesan 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.

Oleh karena itu, pengaturan pendengar latar belakang Anda harus membagi berdasarkan rute dan jenis peringatan. Misalnya:

• Layar chat terbuka: Tambahkan pesan dan hindari menampilkan banner yang tidak perlu
• Layar dashboard terbuka: Tampilkan toast aplikasi yang ringan
• Peristiwa akun kritis: Tampilkan perawatan UI yang lebih kuat

Saat ini, pendekatan 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 peringatan lebih cepat, bahkan jika pengiriman teknisnya sudah benar.

Praktik Terbaik Produksi dan Kesalahan Umum

Sebagian besar pengaturan notifikasi push Expo yang rusak tidak gagal karena Expo terlalu terbatas. Mereka gagal karena tim asumsi token adalah permanen, payload dapat membawa apa saja, dan pembaruan aplikasi tidak akan mempengaruhi logika notifikasi.

Asumsi itu tidak bertahan di produksi.

Token-token adalah sementara, bukan catatan identitas.

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

Model backend yang praktis menyimpan:

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

Tidak menyimpan satu lapangan token pada tabel pengguna dan menganggapnya sudah selesai. Pengguna memiliki perangkat yang berbeda, dan perangkat berubah status.

Strategi refresh lebih penting daripada yang sebagian besar tutorial akui

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

Meluncurkan aplikasi setelah pembaruan

• Masuk pengguna
• Perubahan pengaturan izin
• Rotasi kredensial di proses rilis Anda
• Meluncurkan aplikasi setelah pembaruan
• Alur pemulihan setelah tiket dukungan terkait push

Keamanan dan kinerja tidak boleh berada di akhir sprint

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

Diskusi Courier yang berfokus pada bisnis enterprise tentang kekurangan Expo notification menunjukkan kurangnya panduan praktis seputar pencatatan persetujuan, jejak audit, dan pengurangan paparan payload sensitif. Ambilalih sederhana dari insinyur adalah:

• Tidak masukkan data bisnis sensitif ke dalam teks atau metadata notifikasi.
• Catat perubahan persetujuan di server.
• Rekam notifikasi mana 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 practicespush harus dimasukkan dalam disiplin yang sama dengan autentikasi, analitis, dan logging event backend.

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

Apa yang biasanya berhasil dan apa yang biasanya gagal

Konfigurasi push Expo yang solid tidak rumit. Itu 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 melihatnya. Ini membantu tim mobile untuk mengirimkan update dengan cepat tanpa harus menunggu ulasan toko, yang sangat berguna ketika aliran notifikasi, logika routing, atau perbaikan sisi klien perlu mencapai pengguna dengan cepat.