Kurulu Web Uygulaması Güncellemesi Chrome'da Nasıl Test Edilir?

Kurulu web uygulaması güncellendiğinde kullanıcı ne görür?

Kurulu bir web uygulamasında kodu yayımlamak, uygulamanın adı veya simgesini değiştirmekle aynı işlem değildir. Chrome 144 ile kurulu uygulamanın manifest güncellemeleri daha öngörülebilir işlenir; ad ve simge gibi kimlik değişiklikleri ise kullanıcıya ayrı bir inceleme seçeneği olarak sunulur. Bu nedenle bir PWA yayını için yalnızca sunucuya yeni dosya göndermek yeterli kabul edilmemeli: manifest, simge adresi, önbellek ve gerçek kurulu uygulama ayrı ayrı test edilmelidir. Bu rehber özellikle işletme içi portal, müşteri paneli veya kurumsal web uygulamasını cihazına kuran ekiplere yöneliktir.

Google'ın Chrome 144 güncelleme açıklaması, manifestin kimlik dışı alanları ile ad ve simge alanlarının farklı değerlendirildiğini anlatır. MDN'nin kurulabilir PWA rehberi ise manifestin hangi işlevi gördüğünü ve tarayıcılar arasındaki kurulum farklarını açıklar. Bir tarayıcıda gözlenen davranışı bütün cihazlar için otomatik olarak geçerli saymamak gerekir.

Önce güncellemenin türünü ayırın

Bir işletme portalında üç farklı yayın durumu olabilir. İlkinde sunucu kodu değişir, fakat uygulamanın adı, simgesi ve manifest kimliği aynı kalır. İkincisinde manifestin görünüm veya başlatma davranışı değişir. Üçüncüsünde kullanıcıların cihazında tanıdığı ad veya simge değişir. Bu üç durum için kabul testi aynı olmamalıdır. Kullanıcı yalnızca yeni ekranı görecekse işlevsel test öne çıkar; kimlik de değişiyorsa cihazdaki uygulamanın güven ve tanınabilirlik etkisi ayrıca değerlendirilir.

Örnek olarak saha ekibinin kurduğu bir iş emri panelini düşünün. Yeni sürümde görev ayrıntı ekranına belge bağlantısı eklemek başka bir değişikliktir; uygulamanın simgesini ve adını değiştirmek başka. Çalışanlar simgeyi cihazlarında bulamazsa teknik olarak başarılı bir dağıtım bile operasyonu aksatabilir. Bu yüzden sürüm notunda hangi parçanın değiştiğini açık yazın ve kurulu uygulamayı güncellemeyi web sayfasını yenilemekle eşitlemeyin.

Chrome 144 manifest sürecinde ne değişti?

Google'ın 21 Ocak 2026 tarihli açıklamasına göre Chrome, manifestte icons alanı değişmemişse simgeleri görsel karşılaştırma için tekrar indirmemeye yöneliyor. Gerçek bir simge değişikliğinde simge URL'sini veya ilgili metaveriyi değiştirmek gerekir. Aynı kaynakta, ad ve simge güncellemesinin kullanıcı tarafından incelenebilen bir seçim olarak sunulduğu belirtilir. Böyle bir değişikliği sessizce ve her cihazda aynı anda gerçekleşecek bir işlem gibi planlamayın.

Bu ayrım sürümleme yöntemini etkiler. Aynı URL altında farklı görsel içeriği servis etmek, manifestteki simge alanı değişmediğinde beklenen yenilemeyi sağlamayabilir. Öte yandan her dağıtımda gereksiz yeni simge URL'si üretmek kullanıcıya gereksiz kimlik değişikliği akışı gösterebilir. Yayın planında, gerçekten değişen alanları ve bunların kullanıcıya etkisini kayıt altına almak daha sağlam bir tercihtir.

Chrome açıklaması eski günlük güncelleme kontrol kısıtının kaldırıldığını da bildirir. Bu, kurulu her uygulamanın her platformda anında aynı ekrana geçeceği garantisi değildir. Manifest güncellemesi, ağ önbelleği, uygulama kabuğu ve sunucu kodu farklı katmanlardır. Özellikle çevrimdışı çalışabilen bir uygulamada eski kaynakların ne zaman bırakılacağı ayrıca tasarlanmalıdır.

Yayın öncesi kontrol planı

İlk adım mevcut manifesti saklamaktır. name, short_name, id, start_url, scope ve icons alanlarının eski ve yeni değerlerini yan yana koyun. Böylece yanlışlıkla ikinci bir kurulu uygulama kimliği oluşturup oluşturmadığınızı görebilirsiniz. Bir değişiklik isteğinde yalnızca “yeni logo” yazması yeterli değildir; hangi dosya adresinin, hangi manifest alanının ve hangi cihaz görünümünün etkileneceğini belirtin.

İkinci adım kurulum ortamlarını ayırmaktır. Masaüstü Chrome, Android Chrome ve kullanılan diğer tarayıcılarda aynı sonuca güvenmeyin. MDN, PWA kurulumunun tarayıcı ve platforma göre değiştiğini özellikle vurgular. Kurulu uygulaması olmayan yeni kullanıcı, daha önce kuran kullanıcı ve uzun süredir uygulamayı açmayan kullanıcı için ayrı deneme yapın. Test cihazında önbelleği temizleyip yalnızca taze kurulum denemek, mevcut kullanıcıdaki sorunu gizler.

Üçüncü adım görünür davranışı yazılı kabul ölçütüne çevirmektir. Kullanıcı yeni işlevi açabiliyor mu? Uygulama kısa yolundan açıldığında doğru ekrana gidiyor mu? Ad veya simge değişikliği varsa gözden geçirme seçeneği anlaşılır mı? Kullanıcı değişikliği kabul etmezse eski kimlikle işlevsel erişim sürüyor mu? Kullanıcı adımlarını ekran kaydı veya test tutanağıyla belgeleyin; gerçek müşterinin verisiyle deney yapmayın.

Son adım geri dönüş planıdır. Yeni manifest sorun çıkarırsa eski dosyanın geri alınması ve uygulama önbelleğinin davranışı ayrı kararlardır. Ekibin hangi belirtiyi gördüğünde yayını durduracağı, kimin karar vereceği ve müşteriye nasıl bilgi verileceği önceden belli olmalıdır. Geri alma işlemini yalnızca kaynak kodunu eskiye döndürmek olarak tanımlamayın.

Sık görülen hatalar ve çözüm yolu

“Logo değişti ama kurulu uygulamada görünmüyor” şikâyetinde önce manifestteki simge adresinin gerçekten değişip değişmediğini ve yeni dosyanın erişilebilirliğini kontrol edin. “Yeni ekran geldi ama eski veri gösteriliyor” durumunda manifestten önce servis çalışanı ve veri önbelleği politikasını inceleyin. “Uygulama iki kez kuruldu” belirtisi varsa kimlik ve başlangıç URL'sinin dağıtımlar arasında tutarlı kalıp kalmadığını araştırın. Bu belirtiler birbirinin yerine geçen tek bir hata sınıfı değildir.

Kullanıcıyı uygulamayı kaldırıp yeniden kurmaya yönlendirmek en son seçenek olmalıdır; bu işlem yerel veriyi ve alışkanlığı etkileyebilir. Önce tekrar üretilebilir bir test, cihaz ve tarayıcı bilgisi, eski-yeni manifest karşılaştırması ve uygulamanın kendi güncelleme davranışı kaydedilmelidir. Chrome için geçerli bir çözümü iOS veya başka bir tarayıcıya kesin çözüm diye taşımayın.

Bu konu hangi hizmete bağlanır?

Kendi iş akışına göre kurulu web uygulaması geliştiren işletmeler için konu, yalnızca ikon güncellemesi değil sürdürülebilir yayın operasyonudur. Webinle web yazılım hizmeti kapsamında portalın kurulum, sürümleme ve kabul senaryoları birlikte tasarlanabilir. Web uygulaması yerine WordPress tabanlı özel modül işletiyorsanız staging ve geri dönüş planı ayrı bir başlangıç noktasıdır; PWA manifestinin yerini almaz.

Teklif görüşmesine başlamadan önce kurulu uygulamanızın manifest örneğini, kullanılan tarayıcıları ve gözlenen hatayı paylaşmanız yeterli bir teknik çerçeve oluşturur. Webinle, doğrulanmış test sonuçlarına göre yayını aşamalara bölen bir uygulama planı hazırlayabilir; her cihazda aynı anda güncelleme veya performans artışı garantisi verilmez.