iOS ve Android push bildirimleri için APNs vs FCM

Karşılaştırdığınız şey (ve neden önemli)\n\nAPNs (Apple Push Notification service) ve FCM (Firebase Cloud Messaging), bir mesajı sunucunuzdan telefona taşıyan teslim borularıdır. Mesajla uygulamanızın ne yapacağını belirlemezler, ama mesajın gelip gelmeyeceğini, ne kadar hızlı geleceğini ve hangi biçimde olması gerektiğini büyük ölçüde etkilerler.\n\n“Push bildirim Android'de çalışıyor ama iOS'ta çalışmıyor” (veya tersi) dendiğinde, genellikle tek bir hata yoktur. iOS ve Android arka plan işleri, güç tasarruflarını, izinleri ve mesaj önceliğini farklı şekilde ele alır. Aynı mesaj gecikebilir, daha yenisiyle değiştirilebilir, sessiz gösterilebilir veya uygulama onu işlemek için uyanamadığı için hiç görüntülenmeyebilir.\n\nBu karşılaştırma, gerçek dünyada en çok şaşırtan bölümlere odaklanır: cihaz tokenlerinin zaman içinde nasıl değiştiği, payloadun ne kadar büyük olabileceği ve nasıl yapılandırılması gerektiği, hangi teslim beklentilerinin gerçekçi olduğu ve bildirimlerin eksik görünmesine neden olan yaygın sebepler.\n\nBu, bir push sağlayıcı arayüzünü seçmeyi, pazarlama stratejisini veya tam bir analitik hattı kurmayı kapsamaz. Buradaki amaç güvenilirlik ve daha hızlı hata ayıklamadır.\n\nSık kullanılan birkaç terim:\n\n- Token: APNs veya FCM tarafından verilen, gönderdiğiniz cihaz-spesifik adres.\n- Topic: birçok cihazın abone olduğu grup adresi (genelde FCM ile kullanılır).\n- Kanal: Android bildirim kategorisi; ses, önem ve davranışı kontrol eder.\n- Collapse key: bekleyen eski mesajların yeni bir mesajla değiştirilmesini sağlayan yöntem.\n- TTL (time to live): bir mesajın teslim için ne kadar süre bekleyebileceği.\n\nBu temelleri doğru yapmak, “basit bir push” farklı platformlarda beklenmedik şekilde davrandığında saatlerce tahmin yürütmeyi önler.\n\n## APNs ve FCM yüksek seviyede nasıl çalışır\n\nAPNs ve FCM, sunucunuz ile kullanıcının telefonu arasındaki aracı hizmetlerdir. Uygulamanız internet üzerinden doğrudan güvenilir şekilde bir cihaza push gönderemez; bu işi Apple (APNs) veya Google (FCM) üstlenir, çünkü onlar cihazlarla güvenilir bağlantıları zaten koruyor.\n\nGenel akış benzerdir: uygulamanız bir token alır, backendiniz bu tokeni kullanarak push servisine bir mesaj gönderir ve servis mesajı cihaza yönlendirir.\n\n### APNs sade anlatımıyla\n\niOS'ta uygulama uzak bildirimler için kayıt olur ve (çoğunlukla) kullanıcıdan izin ister. Apple sonra bir cihaz tokeni sağlar. Backendiniz (genelde “provider” olarak adlandırılır) bu tokeni ve payloadunuzu içeren bir push isteğini APNs'ye gönderir. APNs teslim edip edemeyeceğine karar verir ve bildirimi cihaza iletir.\n\nBackendiniz APNs'ye genellikle token tabanlı kimlik doğrulama (imzalama anahtarı) ile bağlanır. Eski kurulumlar sertifikalar kullanır.\n\n### FCM sade anlatımıyla\n\nAndroid'de uygulama örneği FCM'ye kayıt olur ve bir kayıt tokeni alır. Backendiniz FCM'ye bir mesaj gönderir ve FCM doğru cihaza yönlendirir. Uygulamanın durumuna ve mesaj türüne göre FCM, bildirimi otomatik olarak gösterebilir veya veriyi uygulamaya iletip uygulamanın işlem yapmasını sağlayabilir.\n\nBackendiniz FCM'ye sunucu kimlik bilgileri (API anahtarı veya servis hesabı) ile kimlik doğrulaması yapar.\n\nSiz kontrol edersiniz: uygulama kodu, izin isteme zamanlaması, token depolama, backend mantığı ve gönderdiğiniz payload. Apple ve Google kontrol eder: teslim ağı, erişilebilirlik, hız sınırlama kuralları ve güç tasarrufu ve sistem politikaları gibi birçok son kilometre koşulu.\n\n## Token yaşam döngüsü: tokenler nasıl verilir, yenilenir ve geçersiz kılınır\n\nAPNs vs FCM arasındaki günlük en büyük fark, tokenlerin “bir kez ayarlanıp sonsuza dek kalmayacağıdır.” Onları uyarı adresleri gibi düşünün; haber vermeden değişebilirler.\n\niOS'ta APNs cihaz tokeni cihazla, uygulamanızla ve Apple geliştirici ayarlarınızla bağlıdır. Yeniden yükleme, cihazın geri yüklenmesi, bazı OS güncellemeleri veya geliştirme sırasında push ortamını (sandbox vs production) değiştirmek tokeni güncelleyebilir.\n\nAndroid'de FCM kayıt tokeni, uygulama yeni bir cihaza taşındığında, kullanıcı uygulama verilerini temizlediğinde, Google tokeni döndürdüğünde veya uygulama yeniden yüklendiğinde yenilenebilir. Uygulamanız yenileme olaylarını beklemeli ve yeni tokeni sunucunuza hızlıca göndermelidir.\n\nBasit bir kural: tokenleri her zaman upsert edin, “ekle ve unut” yapmayın. Tokenleri depolarken çoğaltmaları ve yanlış hedefleri önlemek için yeterli bağlamı tutun:\n\n- Kullanıcı veya hesap ID'si (varsa)\n- Uygulama bundle/package ve ortam\n- Platform (iOS/Android)\n- Token değeri ve son görülme zaman damgası\n- Opt-in durumu (izin verildi/verilmedi)\n\nSilmeler de önemlidir. Genelde bir tokenin ölü olduğunu teslim hatalarından öğrenirsiniz; temiz bir “kaldırma” sinyali nadirdir. APNs bir Unregistered hatası (çoğunlukla 410 statüsü) dönerse veya FCM NotRegistered/Unregistered derse, o tokeni derhal silin ki sonsuza dek tekrar denemeyi bırakın.\n\nÖzel bir hataya yol açmanın kolay yolu: bir müşteri çıkış yapıp aynı telefonda başka biri giriş yaptığında tokeni temizlemez veya yeniden eşlemezseniz, doğru olmayan kişiye bildirim gönderebilirsiniz; teslimat “çalışıyor” gibi görünse bile hedef yanlış olur.\n\n## Payload kısıtları ve mesaj yapısı farkları\n\nAPNs ve FCM arasındaki en büyük pratik fark, bir mesajda ne kadar yer olduğudur ve telefon mesajı aldığında nasıl ele aldığıdır.\n\nÇoğu ekip küçük bir alan setine güvenir:\n\n- Başlık ve gövde metni\n- Rozet sayısı (iOS)\n- Ses (varsayılan veya özel)\n- Özel anahtar-değer verileri (ör. order_id, status)\n\n### Boyut limitleri: pushu küçük tutun\n\nHer iki servis de payload boyutu limitine sahiptir ve limit özel verilerinizi de kapsar. Limite ulaşınca teslim başarısız olabilir veya mesaj beklediğiniz gibi davranmayabilir.\n\nGüvenilir bir desen, kısa bir bildirim artı bir ID göndermek ve ardından detayları backendinizden çekmektir.\n\nÖrnek: tam bir sipariş özetini göndermek yerine { "type": "order_update", "order_id": "123" } gönderin ve uygulamanın en son durumu API'nizden almasını sağlayın.\n\n### Data-only vs bildirim davranışı\n\nAndroid'de, bir FCM mesajı “notification” payloadu içeriyorsa sistem genellikle arka plandayken bunu gösterir. Data-only bir mesaj uygulama koduna verilir, ama arka plan limitleri ve pil ayarları nedeniyle gecikebilir veya engellenebilir.\n\niOS'ta alertler (başlık/gövde) doğrudandır, ancak arka plan güncellemeleri daha katıdır. Bir arka plan pushu kodunuzun hemen çalışacağını garanti etmez. Bunu anında iş yapacak bir tetik değil, yenileme için bir ipucu olarak görün.\n\nGüvenilirlik gerekliyse, payloadu minimal tutun, stabil bir tanımlayıcı ekleyin ve uygulamanızı açıldığında veya yeniden etkinleştiğinde durumu uzlaşacak (reconcile) şekilde tasarlayın.\n\n## Teslim beklentileri ve bildirimi durdurabilecek durumlar\n\nAPNs ve FCM ile teslimat “en iyi çaba” şeklindedir. Sağlayıcı mesajınızı teslim etmeye çalışır, fakat cihazın mesajı göstereceğini garanti etmez.\n\nErişilebilirlik ilk sınırlayıcıdır. Bir bildirimi TTL veya expiry ile gönderirsiniz. Cihaz o pencere içinde çevrimiçi olmazsa push düşürülür. TTL çok uzun olursa, kullanıcı eski bir uyarıyı daha sonra görebilir; bu da bir hata gibi algılanır.\n\nÖncelik zamanlamayı etkiler, ama ücretsiz bir yükseltme değildir. Yüksek öncelik, özellikle cihaz uyurken zaman duyarlı mesajların daha çabuk ulaşmasına yardımcı olabilir. Fazla kullanımı hız sınırlamaya, pil tüketimine veya OS'un uygulamanızı gürültülü olarak etiketlemesine yol açabilir.\n\nHer iki sistem de çökme (collapse) destekler; böylece yeni bir mesaj eski bekleyen mesajın yerini alır. APNs çökme tanımlayıcısı (collapse identifier), FCM ise collapse key kullanır. Eğer order_status gibi bir şeyde çökme yaparsanız, kullanıcı her adımı değil en son durumu görebilir.\n\nSağlayıcı başarıyla teslim etse bile, telefon yine de kullanıcının görmesini engelleyebilir:\n\n- Rahatsız Etmeyin veya Odak modları uyarıları sessize alabilir veya gizleyebilir\n- Uygulama bildirim ayarları kapatılmış ya da sessiz teslim olarak ayarlanmış olabilir\n- Android bildirim kanalları belirli bir kategori için kapatılmış olabilir\n- Arka plan kısıtlamaları veya pil tasarrufları teslimatı geciktirebilir\n- OS, uygulamanız birçok benzer uyarı gönderiyorsa tekrarları bastırabilir\n\nPush'u güvenilmez bir taşıma protokolü olarak görün: önemli durumu backendinizde tutun ve uygulamanın açıldığında veya kullanıcı geri döndüğünde en güncel durumu yenilemesini sağlayın, bildirim hiç gösterilmemiş olsa bile.\n\n## Teslimatı etkileyen izinler ve cihaz ayarları\n\nBirçok “teslimat sorunu” aslında izin ve ayar sorunudur.\n\niOS'ta ilk izin istemi önemlidir. Kullanıcı “İzin Verme”ye dokunursa, bildirimler kullanıcı Ayarları'nda değiştirene kadar görünmez. İzin verildikten sonra bile Kilit Ekranı, Bildirim Merkezi, bannerlar, sesler veya rozeti (badge) kapatabilirler. Odak modları ve Planlanmış Özet de uyarıları gizleyebilir veya geciktirebilir.\n\nAndroid'de gereksinimler OS sürümüne bağlıdır. Yeni sürümler çalışma zamanı bildirim izni gerektirebilir; bu nedenle bir uygulama güncellemesi bildirimlerin gösterilmesini aniden durdurabilir ta ki kullanıcı tekrar onay verene kadar. Görünürlük ayrıca bildirim kanallarına bağlıdır. Kanal sessize alınmış veya düşük önemdeyse, pushlar gelir ama cihazı rahatsız etmez.\n\nArka plan kısıtlamaları beklentileri bozabilir. iOS'ta Düşük Güç Modu ve Android'de pil optimizasyonları arka plan işi geciktirebilir, arka plan veriyi durdurabilir veya data-only mesajların işlenmesini engelleyebilir.\n\nNe olduğunu doğrulamak için, sadece backend'in ne gönderdiğini değil, cihazın ne gördüğünü kaydedin:\n\n- Uygulama içi loglar: “izin verildi”, “token kaydedildi”, “bildirim alındı”, “bildirim gösterildi”\n- OS göstergeleri: bildirim ayar durumu (etkin/sessize alınmış/kanal önemi) ve pil modu\n- Push geri çağrıları: uygulamanızın foreground/background durumunda mesajı alıp almadığı\n\nBackend no-code bir araçla yapılsa bile, istemci tarafı loglama “mesaj alınmadı” ile “alındı ama bastırıldı”yı ayıran şeydir.\n\n## Adım adım: kaybolan bildirimleri nasıl hata ayıklarsınız\n\nBir push kaybolduğunda, onu bir zincir gibi ele alın: token, sağlayıcı, payload ve uygulama davranışı. Semptomlar iOS ve Android'de aynı görünebilir, bu yüzden aynı birkaç noktayı sırayla kontrol edin.\n\n- Geçerli bir tokena gönderdiğinizden emin olun. Sunucunuzdaki token ile uygulamanın en son bildirdiği tokeni karşılaştırın. Her tokeni ne zaman aldığınızı loglayın.\n- Göndermeden önce payloadu doğrulayın. Platform limitleri içinde tutun, gerekli alanları kullanın ve bozuk JSON'dan kaçının. Data-only mesajlar gönderiyorsanız uygulamanın bunları işlemek üzere inşa edildiğinden emin olun.\n- Sağlayıcı kimlik bilgilerini ve ortamı kontrol edin. APNs için anahtar/sertifika, team, bundle ID ve sandbox vs production hedefini doğrulayın. FCM için doğru proje kimlik bilgilerini kontrol edin.\n\nSonra bunun mesaj içeriği mi yoksa cihaz/uygulama davranışı mı olduğunu daraltın:\n\n- Minimal bir test bildirimi gönderin. Küçük bir başlık/gövde payloadu taşımanın işe yarayıp yaramadığını kontrol edin.\n- Uygulama tarafı işleyicilerini ve foreground davranışını doğrulayın. Birçok “kaybolan” push aslında alınır ama gösterilmez. Bazı uygulamalar foregrounddayken bannerları bilerek bastırır.\n- Her seferinde bir değişkeni değiştirin. Farklı bir cihaz, farklı bir OS sürümü, Wi-Fi vs mobil veri ve farklı bir kullanıcı hesabı deneyin. Sadece bir hesapta sorun varsa genelde eski tokenler veya sunucu tarafı hedefleme kaynaklıdır.\n\nPratik bir desen: iOS kullanıcıları kaçırıyorsa ama Android iyiyse, iOS'ta minimal bir uyarı göndererek başlayın. Eğer bu işe yararsa, payload yapısı ve uygulama işleyişine odaklanın. Eğer işe yaramazsa, tokenler ve APNs kimlik bilgileri/ortamına odaklanın.\n\n## Sessiz başarısızlıklara neden olan yaygın hatalar\n\nÇoğu push sorunu servis kesintisi değildir. Beklenen ile APNs veya FCM'nin kabul edeceği şey arasında küçük uyumsuzluklardır, ya da telefonun izin vermemesi gibi durumlar.\n\nEn yaygın olanı artık geçerli olmayan bir tokena göndermektir. Tokenler yeniden yükleme, geri yükleme veya yenileme sonrası değişir. Sunucunuz eski değeri kullanmaya devam ederse pushlar hiçbir yere gitmez.\n\nBir diğer hata, push teslimatını garantili olarak varsaymaktır. En iyi çaba teslimatı, cihazlar çevrimdışı veya güç tasarrufu kuralları altındayken gecikmeler veya eksikler anlamına gelir. Önemli olaylar (sipariş güncellemeleri, güvenlik uyarıları) için uygulama içi bir yedek; örneğin açıldığında son durumu çeken bir mekanizma gerekir.\n\nEksik bildirimlere yol açan yaygın nedenler: \n\n- Yeniden yükleme/yenileme sonrası saklanan eski iOS veya Android tokenleri\n- Push payload limitlerinin aşılması (çok fazla özel veri, çok büyük resimler, uzun stringler)\n- Sessiz güncellemeler için arka plan teslimata güvenmek ve OS arka plan limitleri tarafından sınırlanmak\n- iOS ortamlarının karıştırılması (geliştirme vs üretim), böylece token ve APNs uç noktası uyuşmuyor\n- Kullanıcı opt-out'ünü, Odak/Rahatsız Etmeyin, kapatılmış bildirim kanallarını (Android) veya uygulama düzeyindeki bildirim izinlerini göz ardı etmek\n\nÖrnek: bir perakende uygulaması “sipariş gönderildi” bildirimi gönderir ama büyük bir JSON iz geçmişi ekler. Gönderim çağrısı düzgün görünür, ama payload reddedilir veya kırpılır ve kullanıcı hiçbir şey görmez. Pushu küçük tutun ve detayları bir API çağrısıyla alın.\n\n## APNs veya FCM'yi suçlamadan önce hızlı kontrol listesi\n\nSağlayıcıyı sorun saymadan önce bir mantık kontrolü yapın: \n\n- Tokenin kullanıcı ve cihaz için doğru olduğunu doğrulayın. Mevcut olmalı, yakın zamanda güncellenmiş olmalı ve doğru oturumla eşleştirilmiş olmalı.\n- Sağlayıcı kimlik bilgilerinin şu anda geçerli olduğunu doğrulayın. APNs anahtar/sertifikası ve FCM kimlik bilgileri doğru uygulama/proje ile eşleşmeli.\n- Payload biçimini ve boyutunu doğrulayın. Limitlerin altında kalın ve doğru alanları kullanın.\n- TTL, öncelik ve çökme ayarlarını amaçlayarak belirleyin. Düşük TTL cihaz çevrimiçi olmadan önce süresinin dolmasına neden olabilir. Düşük öncelik teslimatı geciktirebilir. Çökme eski mesajları değiştirebilir.\n- “Sunucu kabul etti” ile “cihaz gösterdi”yi ayırın. Sunucu loglarını (istek/yanıt/mesaj ID) istemci loglarıyla (kullanılan token, çağrılan handler) karşılaştırın.\n\nSonra hızlı bir cihaz kontrolü yapın: uygulama için bildirimler izin verilmiş mi, doğru kanal/kategori yapılandırılmış mı (Android kanalları sık yapılan bir hata noktasıdır), Odak/Rahatsız Etmeyin modları ve arka plan kısıtlamaları.\n\n## Örnek: kaybolan bir sipariş güncellemesi bildirimini teşhis etme\n\nBir destek görevlisi “Sipariş güncellemesi gönder”e tıklar (Sipariş #1842). Backend loglarında “bildirim gönderildi” görünür, ama müşteri ne iPhone'unda ne de Android telefonda hiçbir şey görmez.\n\nBackend ile başlayın. Çoğu “kaybolan” bildirim ya push servisi tarafından kabul edilmemiştir ya da kabul edilmiş ama daha sonra cihazın göstermesinin mümkün olmadığı bir durumda düşürülmüştür.\n\n### Önce backend kontrolleri\n\nTek bir izlenebilir gönderim girişimi arayın (bir sipariş güncellemesi bir push isteği üretmelidir). Ardından doğrulayın: \n\n- Kullanılan token, o kullanıcı ve cihaz için sunucuda saklanan en güncel token mi?\n- Push sağlayıcı yanıtı başarılı mı ve hataları kaydettiniz mi?\n- Payload platform kurallarına uyuyor mu (boyut limitleri, gerekli alanlar, geçerli JSON)?\n- Kimlik doğrulama geçerli mi (APNs anahtarı/sertifikası ve team/bundle IDler, veya FCM kimlik bilgileri)?\n- Doğru iOS ortamını (sandbox vs production) hedeflediniz mi?\n\nLoglarınız “unregistered/invalid token” gibi bir reddi gösteriyorsa, bu token yaşam döngüsü sorunudur. Sağlayıcı mesajı kabul ediyorsa ama hiçbir şey gelmiyorsa, payload türü ve OS davranışına odaklanın.\n\n### Telefonda kontroller\n\nŞimdi telefonun uyarıyı gösterebilecek durumda olduğunu doğrulayın: \n\n- Uygulama için bildirimler etkin mi (Kilit Ekranı/Banner'lar izinli mi)?\n- Odak/Rahatsız Etmeyin veya bildirim özetleri onu gizlemiyor mu?\n- Pil tasarruf modları arka plan işlerini kısıtlamıyor mu (Android'de daha yaygın)?\n- Mesaj türüyle uygulama durumu uyuşuyor mu (foreground işleme uyarıyı yutuyor olabilir)?\n\nSık görülen sonuç: token iyidir ama mesaj data-only (Android) veya arka plan işleme için doğru iOS ayarları eksik olduğundan OS uyarıyı asla göstermemiştir. Çözüm, ne istediğinize göre doğru payload türünü göndermek (görünür uyarı vs arka plan güncellemesi) ve token güncellemelerini ile sağlayıcı yanıtlarını temiz loglamaktır.\n\n## Sonraki adımlar: ürününüzde pushu daha güvenilir hale getirin\n\nPush bildirimleri basit hissi verir ta ki onlar merkezî bir özellik olana kadar. Güvenilirlik, sizin kontrolünüzdeki parçalardan gelir: token hijyeni, payload disiplini ve bir yedek yol.\n\nKaçırmaları planlayın. Push “şimdi bak” anları için harikadır, ama kritik olaylar için tek yol olmamalıdır. Uygulama içi bir gelen kutusu kullanıcılara daha sonra yakalama imkânı verir; e-posta veya SMS ise parola sıfırlama veya ödeme sorunları gibi yüksek değerli işlemler için kullanılabilir.\n\nPayloadu ince tutun. Push payloadunu tam mesaj olarak değil bir tetik olarak görün. Bir event tipi ve ID gönderin, sonra uygulama açıldığında veya uygun bir arka plan güncellemesi alındığında backend API'nizden detayları çekin.\n\nEkip için kısa bir runbook yazın ki hata ayıklama tutarlı kalsın: opt-in durumu, token tazeliği, sağlayıcı yanıt kodları, payload boyutu/şekli ve ortam/kimlik bilgileri.\n\nEğer AppMaster (appmaster.io) ile inşa ediyorsanız, token depolamayı, denetim loglarını ve push tetikleyen iş mantığını aynı backendde tutmak kullanışlı olabilir; yine de native iOS ve Android uygulamalar APNs ve FCM'yi doğru şekilde ele almalıdır.