Petunjuk Master Expo Push Notification 2026

Sekarang Anda mungkin sudah mencapai titik di mana aplikasi berjalan, pengguna telah masuk, dan produk sekarang ingin aliran re-engagement yang terasa asli. Pengingat keranjang. Prompt ulasan. Peringatan pesan baru. Pengumuman rilis. Insting pertama seringkali adalah untuk

,

, kemudian setelah seminggu Anda sedang debugging mengapa perangkat satu mendapatkan peringatan, simulator tampaknya terdaftar dengan baik, dan tidak ada yang bisa menjelaskan mengapa sentuhan tidak membuka layar yang tepat. Itu di mana Expo notifikasi push adalah sederhana atau sangat rapuh.Expo memberikan lapisan praktis atas APNs dan FCM, yang tepat mengapa banyak tim menggunakan layanan ini. Namun, gap antara demo dan implementasi siap produksi nyata adalah 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.

Pengalaman pengguna yang dapat diprediksi adalah kunci di balik pekerjaan peningkatan retensi aplikasi mobile.

• Daftar Isi Panduan Notifikasi Push Expo
  • Apa yang sebenarnya diabstrak oleh Expo
  • Apa yang sebenarnya berarti siap produksi
• Pengaturan dan Konfigurasi Proyek Awal
  • Pasang paket notifikasi
  • Tambahkan konfigurasi proyek
  • Tetapkan handler notifikasi awal
  • 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
• Mengirim Notifikasi Dari Server Anda
  • Apa yang harus dilakukan oleh setiap bidang payload
  • Tetapkan payload kecil dan membosankan
  • Habits server yang berguna
• Mengatasi 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 adalah sementara, bukan catatan identitas
  • Strategi refresh lebih penting daripada yang biasanya ditunjukkan oleh tutorial
  • Keamanan dan konsultasi tidak boleh berada di akhir sprint
  • Apa yang biasanya berfungsi dan apa yang biasanya rusak

The Dasar untuk Menghubungi Pengguna dengan Notifikasi Expo Push

Satu Konfigurasi notifikasi Expo push 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 milidetik, 273 milidetik latency p99,, dan tingkat kesalahan harian rata-rata 0,17%di seluruh jutaan pesan harian across tens of millions of daily messagesMenurut Knock's Expo push __CAPGO_KEEP_0__ analisis benchmark. Knock’s Expo push API benchmark analysisApakah yang sebenarnya diabstrak oleh Expo

Saat tim mengatakan “Expo push,” mereka sering kali berarti beberapa kekhawatiran yang terkait yang digabungkan bersama:

Routing penyedia:

• Expo mengalihkan pesan ke APNs untuk iOS dan FCM untuk Android. Format token:
• Format token: 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 daripada langsung mengintegrasikan API penyedia native.

Itu membantu, tapi juga menciptakan kesalahpahaman umum. Tim kadang-kadang asumsi Expo menguasai setiap masalah pengiriman. Pada kenyataannya, 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 sehat.

Apa yang sebenarnya berarti siap produksi

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

Itu perbedaan antara "pengiriman pemberitahuan" dan "pemberitahuan mendukung alur kerja produk nyata."

Pengaturan dan Konfigurasi Proyek Awal

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 bangun.

Mulai dengan library yang terpasang dengan benar dan lingkungan pengembangan yang sesuai dengan jalur bangun. Jika Anda bekerja di luar Expo Go, membantu untuk menyelaraskan alur kerja lokal dengan pengaturan klien pengembangan Expo yang disesuaikan karena perilaku pemberitahuan sering perlu diverifikasi dalam bangun yang lebih dekat dengan produksi daripada menjalankan sandbox cepat.Pasang paket pemberitahuan

Paling tidak, Anda akan memerlukan:

untuk permintaan izin, pengambilan token, pemantauan, dan presentasi pemberitahuan.

• expo-notifications Paket yang biasanya diperlukan
• expo-device karena Anda harus menjaga pemulihan token dengan Device.isDevice.

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

Tambahkan konfigurasi tingkat proyek

Tetapkan konfigurasi Anda secara eksplisit. Minimal app.json atau app.config.js harus mencerminkan fakta bahwa notifikasi adalah bagian dari kontrak aplikasi Anda, bukan sesuatu yang dilupakan.

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

• Identifikasi paket dan nama paket perlu sesuai dengan aplikasi yang Anda kirimkan.
• Plugin notifikasi menjamin proyek native mendapatkan konfigurasi yang diperlukan selama pembangunan.
• ID Proyek EAS Perlu dipertimbangkan apabila pengambilan token menunggu aplikasi terkait dengan proyek Expo yang tepat.

Setel handler notifikasi sejak awal.

Banyak tutorial dasar menunda terlalu lama untuk mendefinisikan perilaku notifikasi. Jangan. Letakkan dekat awal aplikasi agar 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 notifikasi. 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 menghabiskan waktu untuk mengdebug notifikasi yang hilang yang sebenarnya diterima tetapi 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,
  });
}

Setel ini selama inisialisasi aplikasi. Kemudian, jaga ID saluran tetap stabil. Mengubahnya secara santai membuat perilaku notifikasi lebih sulit untuk dipahami nanti.

Mengajukan Izin dan Mengambil Token Push

Ini adalah bagian yang banyak tim salin dari snippet, lalu kemudian menyesalinya.

Pengajuan izin memerlukan waktu, kesadaran platform, dan penanganan async yang disiplin. Pengambilan token memerlukan dilakukan hanya pada perangkat fisik, hanya setelah izin diselesaikan, dan hanya jika Anda siap untuk menyimpan hasilnya di backend Anda segera.

The fungsi klien yang harus menjadi dasar Anda

Pakai 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 itu penting. Anda harus memeriksa jenis perangkat terlebih dahulu, atur perilaku saluran Android, resolusi izin, validasi konfigurasi proyek, kemudian minta token Expo.

Mengapa Device.isDevice tidak boleh diabaikan

Hal ini salah satu dari sedikit kesalahan yang menciptakan banyak kebisingan sementara terlihat tidak berbahaya. Tim ahli hanya meminta izin kondisional ketika Device.isDevice benar, dan kesalahan umum adalah melewatkan penjaga itu, yang menyebabkan pengembang mengirimkan notifikasi ke token simulator yang tidak valid dan menyalahkan Expo ketika masalah sebenarnya adalah konfigurasi aplikasi, seperti yang dijelaskan dalam Catatan implementasi notifikasi Expo Eagerworks.

Oleh karena itu, periksaan itu berada di atas fungsi. Jangan sembunyikannya di balik bantuan. Buatlah jelas.

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

Tanyakan izin pada saat yang tepat

Don’t tanyakan di layar splash. Jangan tanyakan sebelum pengguna memahami nilai. Waktu terbaik biasanya setelah aksi pengguna yang membuat manfaat notifikasi menjadi 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 di 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 bisa mengetahui perangkat mana yang memiliki token mana pada waktu 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 kemudian hari dalam alur kerja, walkthrough ini adalah referensi visual yang membantu:

Untuk tim yang membangun aplikasi dengan perilisan yang sering, juga membantu untuk berpikir tentang registrasi token sebagai bagian dari keadaan operasional aplikasi, bukan hanya bagian dari proses onboarding. Mindset itu cocok dengan alur kerja aplikasi pengiriman Expo di mana perilaku aplikasi dapat berubah sering dan keadaan backend harus tetap sinkron.Untuk tim yang membangun aplikasi dengan perilisan yang sering, juga membantu untuk berpikir tentang registrasi token sebagai bagian dari keadaan operasional aplikasi, bukan hanya bagian dari proses onboarding. Mindset itu cocok dengan alur kerja aplikasi pengiriman Expo

Mengirimkan Pemberitahuan Dari Server Anda

Setelah backend Anda memiliki Expo Push Token yang valid, mengirimkan pemberitahuan adalah hal yang sederhana. Bagian yang sulit bukanlah permintaan itu sendiri. Itu adalah menentukan apa yang termasuk dalam payload dan seberapa banyak kepercayaan Anda pada keadaan klien.

Contoh minimal Node-style menggunakan __CAPGO_KEEP_0__ 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 yang harus dilakukan oleh setiap bidang payload

Jangan biarkan payload menjadi tempat sampah. Tetapkan setiap bidang dengan sengaja.

The data 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 payload.

Tetapkan payload kecil dan membosankan

Menurut Petunjuk Courier untuk pemberitahuan ExpoToken Pemberitahuan Expo harus dianggap sebagai sementara, payload yang melebihi batas ukuran sekitar 4 KB dapat dihentikan, dan pola yang dapat diandalkan adalah mengirimkan 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.

Habits server yang berguna

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.
• Pisahkan penghasilan konten dari transportasi: Buat salinan pesan di satu lapisan dan permintaan Expo API di lapisan lain.
• Tangani umpan balik invalidasi: Jika Expo kemudian melaporkan DeviceNotRegisteredMark token tersebut sudah tidak aktif dan berhenti mencoba secara acak.
• Menggunakan desain yang ramah webhook: Jika sistem Anda sudah mengirimkan event, arahkan trigger pemberitahuan melalui pola pengolahan webhook backend yang sama seperti yang Anda gunakan di tempat lain. Sebelum memulai debugging listener klien, kirimkan push manual terlebih dahulu. Jika token menerima pemberitahuan sederhana dengan payload kecil, jalur transportasi Anda kemungkinan besar sehat. Jika tidak, jangan mulai dengan mengubah navigasi __CAPGO_KEEP_0__. Mulai dengan memvalidasi token, bentuk payload, dan status izin. Pengelolaan Pemberitahuan 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.

Artinya mengelola dua momen terpisah:

pemberitahuan datang ketika aplikasi terbuka

pengguna berinteraksi dengan pemberitahuan dari tray sistem atau layar kunci

• Diagram alir yang menggambarkan siklus pemberitahuan push untuk aplikasi mobile dalam keadaan latar depan dan belakang.
• __CAPGO_KEEP_0__

Transaksi latar depan dan respons pengguna adalah event yang berbeda

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 disampaikan. Jangan kombinasikan mereka secara mental. Mereka melayani jalur UX yang berbeda.

Baca payload data dan navigasikan secara sengaja

Contoh praktis untuk penanganan sentuhan:

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');
}

Polanya tetap tahan karena payload mengandung petunjuk routing, bukan dokumen utuh. Jika urutan telah berubah sejak pemberitahuan disampaikan, aplikasi dapat mengambil status server saat ini setelah navigasi.

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

Perilaku latar depan harus sesuai dengan konteks pengguna

Ketika 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. Layar inbox dukungan mungkin tidak memerlukan peringatan yang terlihat ketika pengguna sedang membaca percakapan tersebut.

Itulah mengapa listener latar depan Anda harus bercabang berdasarkan rute dan jenis pemberitahuan. Misalnya:

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

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

Praktik Terbaik dan Kesalahan Umum di Produksi

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

Asumsi tersebut tidak bertahan di produksi.

Token adalah sementara, bukan catatan identitas

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

Model backend yang praktis menyimpan:

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

Jangan menyimpan satu bidang token pada tabel pengguna dan selesai. Pengguna memiliki perangkat yang berbeda, dan perangkat berubah status.

Strategi refresh lebih penting daripada yang sebagian besar tutorial mengakui

Pedoman ekosistem resmi meninggalkan celah operasional yang nyata di sini. Konten pemberitahuan push Expo yang ada sering tidak menjelaskan bagaiman menjaga validitas token di seluruh Siklus ulasan aplikasi App Store dan pembaruan OTA, yang sangat penting bagi tim yang mengirimkan perubahan hidup karena keandalan push bergantung pada keadaan token saat ini dan sinkronisasi backend, seperti yang disebutkan dalam Dokumentasi notifikasi Expo.

Hal itu mempengaruhi cara Anda merancang trigger refresh. Waktu yang baik untuk memulihkan keadaan token termasuk:

• Peluncuran aplikasi setelah pembaruan
• Pendaftaran pengguna
• Perubahan pengaturan izin
• Kerja rotasi kredential pada proses rilis Anda
• Aliran 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 yang terkait dengan kesehatan, fintech, atau perdagangan yang diatur

Diskusi fokus bisnis Courier tentang celah notifikasi Expo menonjolkan kekurangan panduan praktis seputar pencatatan persetujuan, jejak audit, dan pengurangan paparan payload sensitif. Pengambilan ilmu teknik langsung sederhana:

• Jangan memasukkan data bisnis sensitif ke dalam teks pemberitahuan atau metadata payload.
• Catat perubahan persetujuan di sisi server.
• Rekam mana notifikasi intent yang dikirimkan ke token mana.
• Gunakan ID di payload dan ambil konten yang dilindungi setelah aplikasi dibuka.

Bagi tim yang menyelaraskan operasi rilis dengan praktik keamanan yang lebih luas dan __CAPGO_KEEP_0__ keamanan aplikasi app store compliance and API security practicesPemberitahuan push adalah pesan yang menghadap pengguna, tetapi juga merupakan masalah sistem distribusi. Tatalah mereka dengan perawatan yang sama yang Anda berikan pada keadaan autentikasi dan event pembayaran.

Apa yang biasanya berfungsi dan apa yang biasanya rusak

Biasanya berfungsi

A solid Expo push setup tidaklah 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 layak untuk dilihat. Ini membantu tim mobile mengirimkan update dengan cepat tanpa harus menunggu tinjauan toko, yang sangat berguna ketika aliran pemberitahuan, logika routing, atau perbaikan sisi klien harus mencapai pengguna dengan cepat.