Standart favicon 16×16 piksel için tasarlandı; iPhone Retina ekranı bu boyutu bulanık ve anlamsız kılıyor. Apple, bu sorunu 2007'den bu yana ayrı bir HTML etiketiyle çözüyor: apple-touch-icon. Mekanizma basit görünüyor ama ince ayrıntılar, tarayıcı davranışları ve eski iOS sürümleriyle uyumluluk noktaları çoğu zaman karşılaşılan sorunların asıl kaynağı oluyor.
Apple Touch Icon'un iOS Ekosistemindeki Rolü
iOS, bir web sitesini ana ekrana ekleme aksiyonunu yakaladığında Springboard oluşturulacak ikonu için belirli bir hiyerarşiyi takip eder. İlk kontrol noktası HTML <head> bölümündeki rel="apple-touch-icon" etiketleri; ikinci kontrol noktası Web App Manifest'in icons dizisi; üçüncüsü ise doğrudan alan adı kökünde /apple-touch-icon.png dosyasının varlığı. Bu hiyerarşinin sırasını bilmek, hangi dosyanın gerçekte kullanıldığını anlamak için gerekli. Yalnızca manifest yazan bir geliştirici, Safari'nin bu dosyayı görmediğini fark etmeden siteyi canlıya alabilir.
Safari, bir web sayfasını görüntülerken sekme ikonu olarak bu görseli kullanmaz; sekme ikonu standart favicon.ico veya <link rel="icon"> zincirinden beslenir. Apple touch icon yalnızca Springboard için geçerli. Bu ikisi birbirinin yerini tutmuyor; ikisini ayrı yönetmek gerekiyor.
iOS bu etiketi desteklemeden önce siteler birincil görsel olarak favicon.ico'ya yönlendiriliyordu. Ekran çözünürlükleri yükseldikçe bu dosya ana ekran ikonunda ölçek sorunlarına yol açtı ve Apple, kendi satıcıya özgü (vendor-specific) çözümünü 2007'de Safari 1.1 ile getirdi. Günümüzde etiket vendor-specific olmaktan çıktı; HTML Living Standard bu referansı açıkça belgeliyor, ancak rel="icon" gibi tam standart bir yaşam döngüsüne sahip değil.
180, 167, 152 Piksel: Hangi Boyut Hangi Cihaza Gidiyor?
iOS ikon seçiminde "en yakın küçük" değil, "en yakın büyük veya eşit" boyutu tercih eder. Bu ayrım pratikte şunu yaratıyor: sayfada yalnızca 152×152 bir ikon varsa, iPhone'un @3x Retina ekranı bu dosyayı alıp 180 piksel yuvasına ölçekliyor ve ölçekleme sırasında görüntü kalitesi düşüyor. Boyut yanlış. iOS 180 olanı bulamazsa 152'yi kullanır.
Mevcut Apple cihazlarındaki piksel yoğunluklarına bakıldığında üç boyut öne çıkıyor: 180×180 piksel @3x Retina iPhone için standart hedef; 167×167 piksel iPad Pro @2x için; 152×152 piksel standart @2x iPad ve eski iPhone modelleri için. Bu üç değer arasındaki fark yalnızca piksel sayısı değil, aynı zamanda ikon yaratma sürecindeki en küçük tasarım kararlarının ekrana yansıma biçimiyle ilgili. Çok ince köşe yuvarlamaları ve gölge detayları, 180 piksel versiyonunda görünürken 152 piksel versiyonunda bütünüyle kayboluyor.
Format kararı daha basit: PNG zorunlu değil ama pratik tercih o. WebP'yi iOS Safari 14+'dan itibaren desteklese de apple-touch-icon için geri dönüş mekanizması olmadığından, eski cihazları hâlâ kullanan ziyaretçi kitlesine sahip sitelerde PNG güvenli seçenek olmaya devam ediyor. Mevcut PNG'yi WebP'ye çevirmek istiyorsanız, görsel format dönüşümü için önce hedef iOS sürüm dağılımınızı netleştirin; dönüştürme sonrası fallback eksikse eski cihazlarda ikon boş kalır. Şeffaflık desteği teknik olarak mevcut; ama iOS ikon alanı şeffaf bölgeleri siyah zemin üstüne çizdiğinden, tasarım niyeti şeffaflık içeriyorsa sonuç genellikle beklenenden farklı çıkıyor. Arka plan rengi PNG içine gömülmeli.
Dosya boyutu açısından bu ikonlar nadiren bir performans darboğazına dönüşüyor; 180×180 optimizeli PNG'nin boyutu genellikle 10-20 KB bandında kalıyor. Asıl kost, birden fazla boyut için ayrı dosyayı sürdürme ve değişiklik sırasında tüm versiyonları güncelleme yükü. Bir favicon üreticisini kullanarak bu süreci tek adıma indirmek mümkün; tüm boyutları ve formatları tek seferde oluşturmak için bu tür araçlar özellikle değişiklik frekansı yüksek projelerde ciddi zaman kazandırıyor.
HTML Etiket Yazımı ve Kaynak Hiyerarşisi
Etiketin temel formu şu şekilde:
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180.png">sizes attribute teknik olarak zorunlu değil; tek bir dosya sunuluyorsa iOS bunu kullanır. Birden fazla boyut tanımlandığında sizes kritik hale geliyor çünkü iOS hangi dosyayı seçeceğine bu değere bakarak karar veriyor. Attribute'u yazmamak, iOS'un hangi dosyayı alacağını belirsizleştiriyor.
Çok boyutlu tanımlama şu şekilde kurgulanıyor:
<link rel="apple-touch-icon" sizes="180x180" href="/icons/apple-touch-icon-180.png">
<link rel="apple-touch-icon" sizes="167x167" href="/icons/apple-touch-icon-167.png">
<link rel="apple-touch-icon" sizes="152x152" href="/icons/apple-touch-icon-152.png">href değeri için mutlak yol tercih edilmeli. Göreli yol, sayfa URL'sine göre çözümleniyor; bu durum, özellikle alt dizinlerde çalışan sayfalarda ya da CDN'de barındırılan sayfalarda beklenmedik 404 durumu oluşturuyor. Etiketin <head> içinde nereye yerleştirildiği genellikle fark yaratmıyor, ama charset ve viewport meta etiketlerinin ardından gelmesi, erken parse aşamasında oluşabilecek yorumlama sorunlarını azaltıyor.
Sık karşılaşılan bir hata modu: href yolu doğru ama sunucuda dosya yok. iOS bu durumda sessizce fallback uyguluyor; geliştirici araçlarında görünür bir uyarı üretmiyor. Bunu tespit etmenin tek yolu, URL'yi doğrudan tarayıcıda açmak veya ağ isteklerini izleyerek 404 dönen favicon isteklerini yakalamak.
apple-touch-icon-precomposed: Eski Davranış ve Güncel Gerçeklik
Fark yok. precomposed ve standart etiket günümüz iOS sürümlerinde aynı görsel sonucu üretiyor. iOS 7 öncesinde sistem, standart apple-touch-icon'a otomatik olarak yansıma efekti, köşe yuvarlaması ve parlaklık gradyanı uyguluyordu; precomposed variantı bu efektleri devre dışı bırakıyor ve tasarımcının hazırladığı görseli olduğu gibi kullanıyordu. iOS 7'de Apple skeuomorphic tasarımı tamamen kaldırdı; o tarihten itibaren sistem hiçbir efekt uygulamıyor. İki etiket arasındaki davranış farkı artık sıfır.
Eski bir projede apple-touch-icon-precomposed görüyorsanız bunu güvenle apple-touch-icon'a dönüştürebilirsiniz. Buna karşılık, iOS 6 veya altını desteklemeniz gereken özel bir durum varsa precomposed etiketini korumak işlevsel fark yaratıyor; bu senaryolar 2024 sonrasında neredeyse sıfıra indi. Eski kodu koruma ya da güncelleme kararı büyük ölçüde ziyaretçi kitlesinin iOS sürüm dağılımına bakılarak verilmeli.
Kodun bakım maliyetini artıran bir durum: bazı projeler hem apple-touch-icon hem de apple-touch-icon-precomposed etiketlerini aynı anda ve aynı dosyayla tanımlıyor. Bu gereksiz çoğaltma hata riski yaratmıyor ama dosya yolu değiştiğinde her iki etiketi de güncelleme zorunluluğu doğuruyor. Tekil etiket yeterli.
Web App Manifest ile Örtüşme: Ne Zaman İkisi Birden Gerekiyor?
Sadece manifest yazmak yetmiyor. Safari, manifest.json içindeki icons dizisini ana ekrana ekleme sırasında ikon seçimi için kullanmaz; bu davranış Chrome ve Android tarafından uygulanan bir standarttır. Safari kendi özel hiyerarşisini takip etmeye devam ediyor ve HTML'deki apple-touch-icon etiketine öncelik veriyor.
Pratikte bu şu anlama geliyor: Progressive Web App geliştiriyorsanız, Chrome/Android için manifest içinde ikon tanımlamak yeterli; iOS Safari için HTML etiketini ayrıca yazmanız gerekiyor. İkisini eş zamanlı yönetmek, özellikle ikon güncellemelerinde her iki konumu da değiştirmeyi unutma riskini yaratıyor. Bu riski azaltmanın pratik yolu, aynı dosya yolunu her iki yerde de kullanmak ve güncellemeyi tek dosyada yapmak.
Web App Manifest'in purpose: "maskable" ile işaretlenen ikonları ayrı bir davranış üretiyor: tarayıcı bu ikonun güvenli alanının dışına taşan bölümlerini kırparak cihaza özgü şekle sığdırabiliyor. iOS Springboard bu özelliği desteklemiyor; maskable ikonlar iOS ana ekranında olduğu gibi görünüyor, kırpma uygulanmıyor. Tasarım dosyasını hem maskable uyumlu hem de iOS ana ekranında düzgün görünecek şekilde hazırlamak mümkün; bunun için önemli görsel elemanları merkezde ve safe zone olarak tanımlanan %80 yarıçap içinde tutmak gerekiyor.
Safari'nin ikon seçim sırasındaki davranışı, iOS sürümlerine göre küçük farklılıklar gösteriyor. Ekrana eklenen sitenin sonraki iOS güncellemesinde nasıl davranacağını tahmin etmenin tek güvenilir yolu, fiziksel cihazda test yapmak. Emülatörler bu davranışı her zaman doğru yansıtmıyor; özellikle ikon önbellek mekanizmaları gerçek cihazda farklı sonuçlar üretiyor ve önbelleği temizlemeden yapılan güncellemeler eski ikonu göstermeye devam edebiliyor. Eski ikonu görmek için ana ekrandan silip yeniden eklemek gerekiyor.
Sitenin birden fazla yerde barındırıldığı ya da CDN üzerinden sunulduğu senaryolarda apple-touch-icon dosyalarının önbellek başlıklarını doğru ayarlamak önem kazanıyor. Bu dosyalar sık değişmeyen statik varlıklar olduğundan uzun cache süreleri uygundur; ama ikon güncellendiğinde ziyaretçinin önbellekteki eski dosyayı çekmesi kaçınılmaz oluyor. Dağıtmadan önce PNG dosyasının boyutunu düşürmek için görsel sıkıştırma yapmak cache yükünü de azaltır. Dosya adına hash veya versiyon numarası ekleyip HTML etiketteki href'i güncellemek, önbellek geçersizleştirme sorununu doğrudan çözüyor ve sunucu tarafı müdahaleye gerek bırakmıyor.
HTML etiketini doğru yazdıktan, doğru boyutları oluşturduktan ve dosyaları sunucuya yükledikten sonra Google Search Console'da mobil kullanılabilirlik raporuna bakmak anlamsız; bu rapor apple-touch-icon ile ilgili bir uyarı üretmiyor. Gerçek doğrulama yöntemi şu: iOS Safari'de sayfayı açmak, paylaş menüsünden "Ana Ekrana Ekle"yi seçmek ve Springboard'da görünen ikonu incelemek. Görsel beklenen dosyayı gösteriyorsa yapılandırma çalışıyor demektir.