Yeni bir uygulama sürümü olmadan neleri değiştirebilirsin: Apple ve Google karşılaştırması
Bir mağaza listesine dokunmadan önce cevaplaman gereken bir soru var: bu düzenleme sana tam bir gönderim mi mal olacak, yoksa sessizce yayına mı girebilir? Bunu yanlış anlarsan ya bütçelemediğin bir inceleme kuyruğunda beklersin ya da hâlâ onay bekleyen bir değişikliğin yayında olduğunu sanırsın. İki mağaza bu soruyu birbirine zıt şekillerde yanıtlıyor ve aradaki fark, listeleri her iki mağazada senkron tutmanın neden can sıkıcı olduğunun asıl nedeni.
İşte alan alan, dürüst versiyon — önce tablo, ardından her mağazanın kurallarının arkasındaki mantık, böylece bu tablonun açıkça belirtmediği durumları da öngörebilirsin.
Tablo
Her yaygın liste alanı ve onu değiştirdiğinde her mağazanın ne talep ettiği. "Yeni sürüm / sürüm çıkışı", mağazanın düzenlemeyi göndermen gereken bir gönderimin parçası olarak ele aldığı anlamına gelir; "incelendi" ise yayına girmeden önce insan ya da otomatik bir kontrolün çalıştığı anlamına gelir.
| Uygulama simgesi | Birincil simge binary içinde gönderilir — değiştirmek yeni bir build gerektirir. Bu build ile birlikte incelenir. | Mağaza simgesi bir liste öğesidir. Yeni bir sürüm çıkışı gerekmez. İncelenir. |
İki şey dikkat çekiyor. Apple neredeyse her şeyi bir sürüm kaydından geçiriyor. Google ise tüm listenin kendi başına hareket etmesine izin veriyor. Hiçbir mağaza önemli varlıklarda incelemeyi atlamıyor — "incelendi" kelimesi neredeyse her hücrede karşımıza çıkıyor. Yani asıl soru nadiren "bu incelenecek mi", daha çok "bu düzenleme beraberinde bir gönderim mi sürüklüyor" oluyor.
Apple: yeni bir sürüm kaydı, yeni bir build ile aynı şey değildir
İnsanları şaşırtan ayrım tam da burada. App Store'da ekran görüntülerini, adını, alt başlığını, anahtar kelime alanını ya da açıklamanı düzenlemek listenin yeni bir sürümünü oluşturur. Bu, seni Xcode'a geri döndürecekmiş gibi görünür. Ama öyle değil. Apple mevcut meta verilerini otomatik olarak yeni sürüme taşır ve yalnızca meta veri değişikliği yeni uygulama kodu gerektirmez — bir build eklersin (App Store Connect sürümde yine de bir build ister) ve uygulamanın ne yaptığında hiçbir şey değiştirmezsin. Sıradaki alanları düzenler, gönderir ve tek bir inceleme döngüsü hepsini kapsar.
Yani aklında tutman gereken doğru ifade "yeni kod yok, ama yine de inceleniyor". Derleme adımı yok, yeni özellik yok — ama düzenleme yine de App Review'a giriyor ve yayınlanmadan önce sırasını bekliyor. Değişikliklerini topluca yap: tek bir sürüm kaydı yeni ekran görüntülerini, yeniden yazılmış açıklamanı, yeni bir alt başlığı ve güncellenmiş anahtar kelimeleri aynı anda barındırabildiği için, her biri için ayrı bir inceleme döngüsü harcamanın anlamı yok.
Uygulama simgesi, gerçekten build gerektiren istisnadır. Birincil simgen binary içine gömülüdür ve oradan çizilir, yani gerçekten yeni bir simge yeni bir build demektir. Alternatif simgeler için de aynı durum geçerlidir — kullanılabilmeleri için uygulamaya paketlenmiş olmaları gerekir, dolayısıyla yeni bir simge eklemek bir liste düzenlemesi değil, bir build'dir.
Apple'ın iki kaçış kapısı
Tanıtım metni. Bu, ne sürüm ne de inceleme gerektirmeden değiştirebileceğin tek alan. 170 karakter uzunluğunda, açıklamanın üstünde yer alır ve istediğin zaman güncellenir — bir indirim, bir lansman notu ya da zamana duyarlı bir metin için kullanışlıdır. Arama sıralamasını etkilemez ve herhangi bir gönderimin parçası değildir; mağazada en hızlı değiştirilebilen alan olmasının nedeni tam olarak budur. Bugün yayında bir şeye ihtiyacın varsa, bunu yapabilecek alan budur.
Ürün Sayfası Optimizasyonu. PPO, ekran görüntülerinin, uygulama önizlemelerinin ve simgenin canlı ürün sayfana karşı en fazla üç varyasyonunu — yeni bir uygulama sürümü göndermeden — test etmene olanak tanır. Apple'ın normal bir gönderim dışında görselleri değiştirmeye en çok yaklaştığı özellik budur. İki uyarı işi dürüst tutuyor: test öncesinde varyasyon meta verisinin yine de onaylanması gerekir (yani anlık değil, incelenerek), ve test etmek istediğin herhangi bir simgenin zaten mevcut uygulama binary'sinin parçası olması gerekir. PPO ziyaretçilerin gördüğünü değiştirir; incelemeyi atlatmaz.
Google Play: sürüm çıkışı olmadan listeyi yayınla
Play tam tersi şekilde çalışır. Mağaza listen — başlık, kısa açıklama, tam açıklama, ekran görüntüleri, öne çıkan grafik, simge, tanıtım videosu — herhangi bir yeni uygulama sürümü eklenmeden kendi başına düzenlenip yayınlanabilir. Düzenlemeleri yaparsın ve bunlar Yayınlama genel görünümünde incelemeye gönderilmeye hazır değişiklikler olarak görünür. Gönderirsin, Google'ın incelemesinden geçer ve herhangi bir build'den bağımsız olarak yayına girer.
Bunu abartmamak için netleştirmen gereken birkaç şey var. Değişiklikler yine de incelenir — Play'in incelemesi liste düzenlemelerinde de çalışır ve uygulama adı ile simge gibi öğeler kontrol edilir, yani sessiz ve anında bir değişim değildir. Ve liste, yayınlanmış bir uygulamadan bağımsız kalamaz: Play, düzenlenecek bir genel liste olması için uygulamanın daha önce bir sürüm çıkışı yapmış olmasını ister. Hiç yayınlanmamış bir şey için tek başına bir mağaza sayfası yayınlayamazsın. Yönetilen yayınlama bilinmesi gereken bir kıvrım daha ekler — açıksa, onaylanan değişiklikler sen aktif olarak yayınlayana kadar bekler; bunu beklediğinde bu bir gecikme değil, bir özelliktir.
Asimetri ve neden zamanına mal olduğu
İki modeli yan yana koyunca ayrım netleşiyor. Apple neredeyse her metin ve görsel düzenlemesini bir sürüm kaydına ve bir inceleme geçişine bağlıyor; bunun tek istisnası tanıtım metni ve PPO. Google ise listeyi sürüm çıkışından tamamen ayırıyor, düzenlemeleri inceliyor ve uygulama zaten var olduğu sürece kendi takvimine göre yayınlıyor.
Bu asimetri, her iki mağazayı da yönettiğinde sessizce pahalıya patlıyor. Aynı ekran görüntüsü yenilemesi bir mağazada sürüm kaydı gönderimi, diğerinde tek başına bir liste güncellemesi oluyor. Açıklama yeniden yazımı Apple'da incelenen bir sürüm, Google'da incelenen bir liste değişikliği oluyor. İçerik aynı; mekanik aynı değil — bu yüzden Play'de tek bir işlem olan bir değişiklik, App Store'da farklı bir işleme dönüşüyor ve birini yayınlayıp diğerini unutmak ya da Apple'da hâlâ incelemedeyken bir şeyin yayında olduğunu sanmak çok kolay.
Mokbi nereye oturuyor
Bu mağazalar arası asimetri, bir yayınlama aracının varlık nedeninin tam da kendisi. Mokbi bir ekran görüntüsü editörü olarak başladı, ama bir liste metin ve görsellerin bir aradaki hali — bu yüzden ekran görüntüsü setini tasarlıyor ve her iki mağaza için de liste metnini tek bir yerde hazırlıyor: App Store adı, alt başlığı, anahtar kelime alanı ve açıklaması; Play başlığı, kısa açıklaması ve tam açıklaması. Her mağazanın gerçekten dizinlediği alanları, o mağazaya göre şekillendirilmiş şekilde alırsın, iki kez yapıştırdığın tek bir metin bloğu yerine.
Sonra tüm listeyi — ekran görüntüleri ve metni — 50 dile çeviriyor, böylece bir kez yaptığın değişiklik her pazarda doğru alana yerleşiyor, geri kalanı yerelleştirilmiş bir listede İngilizce kalmak yerine. Ve yayınlıyor: Mokbi tamamlanmış listeyi Play Developer API üzerinden doğrudan Google Play'e gönderiyor ve App Store Connect'te gönderime hazır şekilde bekletiyor — Apple kendi tarafında son Gönder ve inceleme geçişini yine de zorunlu tutuyor; bu bir Apple kuralı ve tam olarak bu yazının konusu olan mağazalar arası asimetrinin ta kendisi. Bu son inceleme, aynı zamanda bu yazıdaki saatlerin işlemeye başladığı yer.