Panduan Master Expo Notifikasi Push 2026

Anda mungkin telah mencapai titik di mana aplikasi berfungsi, pengguna telah masuk, dan produk sekarang ingin mengaktifkan aliran re-engagement yang terasa asli. Pengingat keranjang. Prompt ulasan. Notifikasi pesan baru. Pengumuman rilis. Insting pertama seringkali adalah untuk "menghubungkan push," kemudian setelah seminggu Anda sedang debugging mengapa perangkat tertentu menerima notifikasi, simulator tampaknya terdaftar dengan baik, dan tidak ada yang dapat menjelaskan mengapa sentuhan tidak membuka layar yang tepat.

Itu adalah titik di mana notifikasi push Expo adalah sederhana atau sangat rapuh.

Expo memberikan lapisan praktis atas APNs dan FCM, yang tepat mengapa banyak tim menggunakan layanan ini. Namun, perbedaan antara demo dan implementasi siap produksi 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. Itu adalah kekhawatiran yang sama di balik Pekerjaan Retensi Pengguna Aplikasi MobileKirimannya hanya berguna jika pengalaman pengguna di sekitarnya dapat diprediksi.

Tabel Konten

• Dasar untuk Menghubungi Pengguna dengan Push 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
  • Tetapkan pengaturan 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
• Mengirimkan Pemberitahuan Dari Server Anda
  • Apa yang harus dilakukan oleh setiap bidang payload
  • Tetapkan payload kecil dan membosankan
  • Habits yang berguna di sisi server
• Mengatasi Pemberitahuan Masuk di Aplikasi Anda
  • Penerimaan latar depan dan respons pengguna adalah peristiwa yang berbeda
  • Bacalah payload data dan navigasikan secara sengaja
  • Penggunaan latar depan harus sesuai dengan konteks pengguna
• Praktik Terbaik Produksi dan Kesalahan yang Umum
  • Token adalah 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 Menghubungi Pengguna dengan Pemberitahuan Expo Push

Satu Pemberitahuan Expo push Konfigurasi ini menarik karena satu alasan di atas semua. Ini menghilangkan banyak kompleksitas pesan native yang tim tidak ingin miliki pada hari pertama. Sebaliknya dari membangun plumbing APNs dan FCM langsung, 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 di mana upaya insinyur Anda pergi.

Juga, layanan ini cukup cepat sehingga kinerja biasanya bukan hal pertama yang perlu dikhawatirkan. Dari 14 Maret 2023 hingga 12 Juni 2023, pemberitahuan push Expo API menunjukkan waktu respons median 42 milisecond, 273 milisecond latency p99dan sehari-hari error rata-rata 0,17% di seluruh puluh juta pesan sehari-hari menurutanalisis benchmark Knock’s Expo push __CAPGO_KEEP_0__ Knock’s Expo push API benchmark analysisApa yang sebenarnya diabstrak oleh Expo

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

Routing penyedia:

• Expo mengalihkan pesan ke APNs APNs untuk iOS dan FCM untuk Android.
• Format token: Pelayanan server Anda menyimpan dan mengirimkan Token Push Expo sebaliknya 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, tapi juga menciptakan kesalahpahaman umum. Tim kadang-kadang menganggap Expo memiliki setiap masalah pengiriman. Dalam prakteknya, banyak gagal datang dari aplikasi code, token yang ketinggalan zaman, 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 “pemberitahuan kirim” 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 Banyak rasa sakit Expo push dimulai sebelum prompt izin pertama. Jika konfigurasi proyek Anda longgar, klien __CAPGO_KEEP_0__ dapat terlihat benar sementara aplikasi masih berperilaku tidak konsisten di antara build.Karena 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 melindungi pengambilan token dengan Device.isDevice.

Perintah instalasi biasanya 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 proyek

Tetapkan konfigurasi Anda 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 menyesuaikan dengan aplikasi yang sebenarnya Anda kirim.
• Plugin notifikasi memastikan proyek native mendapatkan konfigurasi yang diperlukan selama pembangunan.
• ID Proyek EAS berperan ketika token pengambilan mengharapkan aplikasi untuk terkait dengan proyek Expo yang tepat.

Tetapkan handler notifikasi awal

Banyak tutorial dasar menunda terlalu lama untuk mendefinisikan perilaku notifikasi. Jangan. Pasangnya di 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 debugging “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 menyesuaikan 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,
  });
}

Tetapkan 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

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

Pertanyaan izin memerlukan waktu, kesadaran platform, dan penanganan async yang disiplin. Pengambilan token harus terjadi hanya pada perangkat fisik, hanya setelah izin diselesaikan, 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 izin, memvalidasi konfigurasi proyek, kemudian meminta token Expo.

Mengapa Device.isDevice tidak optional

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

Itulah mengapa periksaan berada di atas fungsi. Jangan sembunyikannya di bantuan. Buatlah jelas.

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

Minta izin pada saat yang tepat

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

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. Nanti, 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 kemudian tahap workflow, panduan ini adalah referensi visual yang bermanfaat:

Untuk tim yang membangun aplikasi dengan fokus pada rilis, juga membantu untuk berpikir tentang pendaftaran token sebagai bagian dari keadaan operasional aplikasi, bukan hanya bagian dari proses onboarding. Mindset tersebut sesuai dengan alur kerja aplikasi Expo yang lebih luas di mana perilaku aplikasi dapat berubah sering dan keadaan backend harus tetap sinkron.Mengirim Notifikasi Dari Server Anda

Setelah backend Anda memiliki token Expo Push yang valid, mengirim notifikasi menjadi lebih mudah. Bagian yang sulit bukanlah permintaan itu sendiri. Itu adalah menentukan apa yang harus dimasukkan ke dalam payload dan seberapa banyak kepercayaan yang Anda berikan pada keadaan klien.

Contoh minimal Node-style menggunakan

Tujuan setiap bidang payload 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;
}

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

Bidang

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

Tahanlah muatan kecil dan membosankan

Menurut Petunjuk Kurir untuk Pemberitahuan Expo, Token Pemberitahuan 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 } bukan 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 pemberitahuan dengan ID pengguna, token, jenis muatan, dan tanggal.
• Menghasilkan konten terpisah dari transportasi: Buat salinan pesan di satu layer dan permintaan Expo API di layer lain.
• Mengatasi feedback kadaluarsa: Jika Expo kemudian melaporkan DeviceNotRegistered, tandai token tersebut sudah kadaluarsa 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 yang digunakan di tempat lain. Sebelum memeriksa pemirsa klien, kirimkan push manual terlebih dahulu. Jika token menerima pemberitahuan 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.

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.

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

Handling Incoming Notifications in Your App

Artinya, Anda harus mengatasi dua momen yang berbeda:

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

Penerimaan latar depan dan respons pengguna 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 memiliki jalur UX yang berbeda.

Bacalah isi payload dan navigasikan secara sengaja

Berikut adalah pola yang praktis untuk mengatasi 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');
}

Polah ini tetap stabil karena payload mengandung 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 di latar depan harus sesuai dengan konteks pengguna

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

Itulah mengapa pendengar latar depan Anda harus bercabang berdasarkan rute dan jenis peringatan. Misalnya:

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

Saatnya yang 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 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.

Kenyataannya, asumsi itu tidak bertahan di produksi.

Token adalah sementara, bukan catatan identitas

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

Model backend yang praktis menyimpan:

• ID pengguna
• platform
• metadata yang dipasang
• token saat ini
• timestamp terakhir dilihat
• status seperti aktif, ketinggalan, atau dibatalkan

Jangan menyimpan satu bidang token di tabel pengguna dan bilang 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 nyata di sini. Konten pemberitahuan Expo yang ada sering tidak menjelaskan bagaimana menjaga validitas token di seluruh Periode tinjauan 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 di Dokumentasi pemberitahuan 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
• 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 yang terkait dengan kesehatan, fintech, atau produk perdagangan yang terregulasi.

Diskusi Couriers yang berfokus pada bisnis tentang celah pemberitahuan Expo menunjukkan kekurangan panduan praktis tentang pencatatan persetujuan, jejak audit, dan pengurangan paparan payload sensitif. Ambilannya langsung dari sisi insinyur adalah sederhana:

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

Untuk tim yang menyinkronkan operasi rilis dengan disiplin yang lebih luas aplikasi toko dan API praktik keamananPush harus dimasukkan dalam disiplin tinjauan yang sama seperti auth, analytics, dan logging event backend.

Pemberitahuan push adalah pesan yang menghadap pengguna, tetapi juga masalah sistem yang terdistribusi. Tatalah mereka dengan perawatan yang sama yang Anda berikan pada keadaan autentikasi dan event pembayaran.

Apa yang biasanya berfungsi dan apa yang biasanya rusak

Pengaturan push Expo yang solid 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 menunggu tinjauan toko, yang sangat berguna ketika aliran pemberitahuan, logika routing, atau perbaikan sisi klien perlu mencapai pengguna dengan cepat.