Silent Push — esensi, tugas latar belakang dan konfigurasi pengiriman

Apa itu Silent Push — esensi dan tujuan

Silent Push (pemberitahuan push diam) adalah mekanisme iOS yang mengirimkan data ke perangkat tanpa pemberitahuan visual apa pun kepada pengguna. Tidak seperti push standar yang menampilkan banner, memutar suara, dan masuk ke Notification Center, silent push “menbangunkan” aplikasi di latar belakang dan mengirimkan data untuk diproses. Pengguna tidak pernah tahu tentang pengiriman pemberitahuan semacam itu — hasilnya adalah konten yang diperbarui saat pembukaan berikutnya.

Perbedaan dari pemberitahuan push biasa

Perbedaan utama terletak pada payload JSON: silent push berisi flag content-available: 1 dan TIDAK berisi alert, sound, atau badge. Pemberitahuan standar dengan alert selalu ditampilkan kepada pengguna, terlepas dari content-available. Silent push hanya bekerja dengan content-available: 1 dan tanpa alert — jika alert ditambahkan, sistem akan menampilkan pemberitahuan meskipun ada flag pengiriman latar belakang.

Kapan menggunakan Silent Push

Pemberitahuan diam sangat diperlukan untuk skenario di mana data harus segar saat aplikasi dibuka, tetapi pengguna tidak boleh terganggu. Contoh: memperbarui feed berita di latar belakang, menyinkronkan langganan, mengunduh konten baru untuk akses offline, memperbarui widget, membatalkan cache. Silent Push juga digunakan untuk “menghangatkan” aplikasi sebelum tindakan pengguna yang diharapkan.

Bagaimana cara kerja pengiriman pemberitahuan diam

Pengiriman Silent Push sangat berbeda dari pemberitahuan biasa dan tunduk pada aturan optimalisasi konsumsi energi. Sistem iOS menerima permintaan push dari APNS, menentukan bahwa itu adalah silent push (content-available: 1), dan membuat keputusan tentang pengiriman berdasarkan beberapa faktor: tingkat daya baterai, mode hemat energi, frekuensi silent push sebelumnya, aktivitas aplikasi, dan beban CPU saat ini.

Peran Power Nap dan mode latar belakang

Pada perangkat dengan chip Apple M dan iOS 15+, silent push terintegrasi dengan mekanisme Power Nap, yang secara periodik membangunkan perangkat untuk tugas latar belakang. Power Nap menggabungkan beberapa silent push menjadi satu periode aktivitas, yang mengurangi konsumsi energi total. Pengembang tidak dapat mengelola Power Nap secara langsung — sistem membuat keputusan secara otomatis berdasarkan perilaku pengguna dan rivayat penggunaan aplikasi.

Jendela pemrosesan 30 detik

Ketika sistem mengirimkan silent push, aplikasi menerima panggilan application(_:didReceiveRemoteNotification:fetchCompletionHandler:) di AppDelegate. Pengembang wajib memanggil completion handler dalam waktu 30 detik dengan hasil yang benar (UIBackgroundFetchResult). Jika pemrosesan tidak selesai tepat waktu, sistem dapat membatasi frekuensi silent push untuk aplikasi ini atau menghentikan pengirimannya sama sekali.

// Memproses Silent Push di AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

Interval antar pengiriman

Apple tidak mempublikasikan interval pasti antar silent push, tetapi berdasarkan pengujian dan dokumentasi, disarankan untuk mengirim tidak lebih dari 2–3 pemberitahuan diam per jam per perangkat. Pada pengiriman yang lebih sering, sistem mulai mengabaikan silent push, dan data berhenti dikirim. Jika diperlukan sinkronisasi yang lebih sering, pertimbangkan penggunaan URLSession dengan konfigurasi latar belakang atau VoIP push.

Skenario penggunaan Silent Push

Silent Push diterapkan dalam berbagai tugas di mana data harus tetap terkini tanpa partisipasi aktif pengguna. Mari kita lihat skenario penggunaan paling efektif dari mekanisme ini di aplikasi iOS nyata.

Memperbarui konten untuk akses offline

Aplikasi berita, pembaca, dan aplikasi perjalanan menggunakan Silent Push untuk mengunduh konten baru di latar belakang. Ketika pengguna membuka aplikasi, data sudah diunduh dan tersedia bahkan tanpa internet. Pendekatan ini secara drastis meningkatkan pengalaman pengguna — layar pemuatan kosong menghilang dan konten ditampilkan secara instan. Server mengirimkan silent push saat artikel baru muncul, dan aplikasi di latar belakang mengunduhnya untuk dibaca offline.

Sinkronisasi status widget

iOS WidgetKit memperbarui widget sesuai jadwal, tetapi untuk pembaruan instan setelah perubahan data di server, Silent Push digunakan. Aplikasi di latar belakang memproses silent push, memperbarui penyimpanan data lokal untuk widget, dan memaksa pembaruan timeline melalui WidgetCenter. Pengguna melihat informasi terkini di widget tanpa membuka aplikasi — nilai tukar, prakiraan cuaca, status pengiriman.

Pembatalan cache dan pembersihan data usang

Ketika server memperbarui data kritis (misalnya, aturan tarif, daftar fitur yang tersedia untuk pengguna premium), Silent Push memungkinkan pembatalan cache lokal secara instan. Saat pembukaan berikutnya, aplikasi akan memuat data segar dari server, bukan menggunakan cache usang. Ini sangat relevan untuk aplikasi dengan konten berbayar atau langganan.

Memperbarui badge tanpa pemberitahuan terlihat

Dalam beberapa skenario, badge pada ikon aplikasi perlu diperbarui tanpa menampilkan pemberitahuan. Silent Push dengan bidang badge di payload memungkinkan pengaturan nilai penghitung tanpa mengganggu pengguna dengan banner. Misalnya, aplikasi chat dapat memperbarui badge dengan jumlah pesan yang belum dibaca tanpa menampilkan setiap pesan baru sebagai pemberitahuan jika pengguna berada di dalam aplikasi.

Konfigurasi silent push: payload dan capabilities

Untuk pengoperasian Silent Push yang benar, diperlukan konfigurasi di tiga tingkat: proyek Xcode, payload JSON di server, dan kode pemrosesan di aplikasi. Setiap tingkat sangat penting: melewatkan langkah apa pun menyebabkan pemberitahuan dikirim sebagai biasa atau tidak terkirim sama sekali.

Konfigurasi capabilities di Xcode

Di Xcode, Anda perlu mengaktifkan capability Push Notifications dan Background Modes dengan opsi Remote notifications dicentang. Push Notifications menghasilkan sertifikat untuk APNS, dan Remote notifications di Background Modes memungkinkan sistem membangunkan aplikasi saat menerima silent push. Tanpa Remote notifications, silent push akan terkirim, tetapi aplikasi tidak akan aktif di latar belakang, dan data tidak akan diproses.

Struktur payload JSON

Payload Silent Push harus berisi kunci aps dengan content-available: 1 dan TIDAK berisi alert, sound, atau badge. Bidang kustom dikirimkan pada tingkat yang sama dengan aps dan berisi data untuk diproses: jenis operasi, pengidentifikasi objek, metadata. Payload tanpa content-available akan diproses sebagai pemberitahuan biasa; dengan alert — sebagai pemberitahuan biasa, meskipun dengan content-available.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

Pemrosesan di sisi klien

Saat menerima silent push, iOS memanggil application(_:didReceiveRemoteNotification:fetchCompletionHandler:) sebelum aplikasi menjadi terlihat. Dalam metode ini, Anda perlu menganalisis userInfo, melakukan pekerjaan yang diperlukan (permintaan jaringan, menulis ke Core Data, memperbarui cache), dan wajib memanggil completionHandler dengan hasil yang benar dalam waktu 30 detik. Tidak memanggil completionHandler dianggap oleh sistem sebagai kesalahan dan mempengaruhi frekuensi silent push di masa depan.

Batasan dan praktik terbaik

Silent Push bukan saluran pengiriman data yang dapat diandalkan untuk operasi kritis — ini adalah mekanisme optimalisasi, bukan sinkronisasi yang dijamin. Pengembang harus memahami batasan dan merancang sistem sehingga aplikasi berfungsi dengan benar baik dengan maupun tanpa silent push.

Batasan pengiriman

iOS tidak menjamin pengiriman setiap silent push. Sistem dapat menunda atau membatalkan pengiriman saat daya baterai rendah (di bawah 20%), dalam mode Low Power Mode, pada frekuensi tinggi silent push sebelumnya, serta jika aplikasi sudah lama tidak digunakan oleh pengguna. Statistik pengiriman rata-rata menurut Apple: sekitar 70–80% silent push terkirim dalam 5 menit, sisanya dapat tertunda atau hilang.

Rekomendasi Apple untuk silent push

Apple merekomendasikan untuk mengikuti beberapa aturan untuk penggunaan silent push yang efektif. Jangan kirim lebih dari 2–3 silent push per jam per perangkat — melebihi batas menyebabkan pemblokiran. Gunakan compact payload: ukuran payload minimum mempercepat pemrosesan dan mengurangi beban jaringan. Panggil completionHandler selalu dan secepat mungkin: semakin lama pemrosesan berlangsung, semakin tinggi kemungkinan sistem akan membatasi silent push di masa depan.

Alternatif Silent Push

Untuk skenario yang memerlukan pengiriman terjamin atau lebih banyak waktu pemrosesan, pertimbangkan alternatif. VoIP push (PushKit) menjamin pengiriman dan memberikan lebih banyak waktu, tetapi hanya ditujukan untuk aplikasi VoIP. Background fetch (UIApplication background fetch) dijalankan oleh sistem sesuai jadwal, tetapi tidak dapat diprakarsai oleh server. WebSocket mempertahankan koneksi permanen, tetapi menghabiskan lebih banyak baterai dan tidak cocok untuk semua jenis aplikasi.

Pemantauan dan debugging

Untuk debugging Silent Push, gunakan Console.app di Mac dengan filter berdasarkan nama aplikasi. Sistem mencatat setiap silent push dengan tanda “tugas latar belakang” dan menunjukkan apakah pemrosesan berhasil. Pada perangkat, pemeriksaan dilakukan melalui Pengaturan → Pengembang → Pencatatan Mode Latar Belakang. Sisi server dipantau melalui APNS Feedback Service untuk mendeteksi pemberitahuan yang tidak terkirim.