Birkaç yıl önce, ajans tarafında çalışırken bir müşterimiz lansman etkinliği için otel salonu tutmuştu. Davetiyeler basıldı, basın bülteni hazırlandı, tarih sosyal medyada duyuruldu. Tek küçük sorun: uygulama, etkinlikten üç gün önce App Store incelemesinden ret yedi. Sebep ne devasa bir güvenlik açığıydı ne de çöken bir ekran — inceleme ekibine çalışan bir demo hesabı verilmemişti. Girişli bir uygulamayı, içine giremeyen bir inceleme uzmanı onaylayamıyor; gayet mantıklı bir kural, ama o hafta salonu dolduran davetlilere bunu anlatamazsınız. (Etkinlik "yakında sizlerle" sunumuyla kurtarıldı; keyif kaçmıştı.)
O günden beri ekipçe şuna inanıyoruz: mobil projede kod bitince iş bitmez, asıl engelli koşu mağaza kapısında başlar. Yüzlerce yayın sürecinden geçmiş biri olarak elimdeki istatistik net — ret sebeplerinin büyük çoğunluğu teknik değil, prosedürel. Ve neredeyse tamamı, yayına haftalar kala küçük bir özenle önlenebilir. Bu yazıda iki mağazanın da bize en çok mesai kaybettiren tuzaklarını tek tek anlatacağım.
Apple'ın ret mektuplarını neredeyse ezbere biliyoruz
Demo hesabı klasiğiyle başladım, oradan devam edeyim: hesabı vermek yetmez, hesabın dolu olması gerekir. Boş bir panele giren inceleme uzmanı uygulamanın ne yaptığını göremez ve "minimum işlevsellik" gerekçesiyle ret yazabilir. Biz inceleme hesaplarını gerçekçi test verisiyle doldurup, giriş adımlarını da inceleme notlarına tek tek yazıyoruz — hangi ekranda ne görecekleri dahil. Küçük bir zahmet; ama inceleme süresini gözle görülür biçimde kısalttığını yıllardır ölçüyoruz.
İkinci klasik, izin metinleri. Konum veya kamera izni isterken sistemin gösterdiği açıklama "Bu izin uygulamanın çalışması için gereklidir" gibi boş bir cümleyse, ret gelme ihtimali yüksek. Apple, kullanıcı faydası duymak istiyor. Yıllar önce bir servis takip uygulamasında metni "Servis aracının size yaklaştığını bildirebilmek için konumunuza erişiyoruz" diye yazmıştık; hem inceleme sorunsuz geçti hem de kullanıcıların izin verme oranı belirgin arttı. Tek taşla iki kuş — inceleme uzmanı da kullanıcı da aynı şeyi merak ediyor çünkü: "neden?"
Üçüncüsü ödeme kuralları, ve burası gerçekten mayınlı arazi. Dijital içerik veya dijital hizmet satıyorsanız Apple'ın uygulama içi satın alma sistemini kullanmak zorundasınız; harici ödeme sayfasına gizlice yönlendirme koymak, retle kalmayıp geliştirici hesabınızı riske atacak kadar ciddiye alınıyor. Fiziksel ürün ya da fiziksel hizmet satıyorsanız (yemek siparişi, kargo, servis randevusu) kendi ödeme altyapınız tamamen serbest. Bu ayrımı bilmeyen bir geliştiricinin haftalarca inceleme ekibiyle yazıştığına şahit olduk; sattığı hizmet fiziksel olduğu hâlde İAP'a zorlandığını sanıyor, komisyon hesabı yapıp duruyordu. Kuralı doğru okumak, o haftaları masadan kaldırıyor.
Bir de WebView meselesi var. Mevcut web sitesini olduğu gibi bir WebView'a sarıp "uygulamamız" diye göndermek, Apple'ın en sevmediği şeylerden biri. Mağazada var olmak istiyorsanız yerel bir deneyim sunmanız gerekiyor — bildirimler, cihaz özellikleri, uygulamaya özgü akışlar. "Sitemiz responsive zaten, saralım gitsin" diyenleri yıllardır uyarıyorum; kısa yol gibi görünen şey, ret döngüsünde geçen haftalarla birlikte en uzun yol çıkıyor.
Google tarafında kapı daha geniş, sürprizler daha sinsi
Play Store'un inceleme süreci Apple'a göre daha yumuşak bilinir; doğrudur da. Ama Google'ın sürprizleri yayın gününde değil, sonrasında gelir. En büyüğü Veri Güvenliği (Data Safety) formu: uygulamanızın hangi veriyi toplayıp nereye gönderdiğini beyan ediyorsunuz ve bu beyanın uygulamanın gerçek davranışıyla uyuşması gerekiyor. Kritik ayrıntı şu — "gerçek davranış" kavramına sizin yazdığınız kod kadar, projeye eklediğiniz SDK'lar da dahil. Reklam veya analitik SDK'nızın arka planda ne topladığını bilmiyorsanız formu doğru dolduramazsınız; "haberim yoktu" savunması Google nezdinde bir anlam ifade etmiyor, çünkü SDK'yı projeye siz eklediniz. Biz her yayın öncesi üçüncü parti SDK envanterini formla madde madde karşılaştırıyoruz; iki kez, SDK güncellemesiyle sessizce değişen veri toplama davranışı yakaladık.
İkinci sinsi konu, hedef API seviyesi. Google her yıl çıtayı yükseltiyor: uygulamanız güncel Android API seviyesini hedeflemiyorsa mağazadan silinmiyor ama yeni kullanıcılara görünmez oluyor. Sessiz bir ölüm — indirme grafiğiniz yavaş yavaş sıfıra iner ve kimse size uyarı e-postası atmaz (atar aslında, ama o gelen kutusunu kim okuyor). Bu yüzden hedef API güncellemesi bizde yıllık bakım takviminin sabit kalemi; "uygulama bitti, bakıma gerek yok" diyen ekipler, bir yıl sonra bu maddeyle tanışıyor.
Üçüncüsü, yeni bireysel geliştirici hesaplarındaki kapalı test şartı. Google, taze hesaplardan üretime çıkmadan önce belirli sayıda gerçek test kullanıcısıyla, belirli bir süre kapalı test yürütülmesini istiyor. Teknik bir engel değil, takvim engeli: lansmanınızı bu şartı bilmeden planlarsanız, "yarın çıkıyoruz" dediğiniz gün önünüze haftalar çıkar. Kurumsal hesap kullanmak ya da kapalı testi geliştirme sürerken erkenden başlatmak, bu tuzağın iki basit çözümü. Biz sürüm takvimine bunu ilk günden yazıyoruz.
Yayın günü bizde nasıl işliyor
Uygulama onay aldıktan sonra ekipte kimse "yüzde yüz, tam gaz" butonuna basmaz. Aşamalı çıkış kullanırız: önce kullanıcıların %10'u, çökme oranları ve kritik akışlar temizse %50, sonra %100. Bu sabır bir kez bile işe yaradıysa kendini sonsuza kadar amorti etmiş demektir — ve yaradı: %10 diliminde yakaladığımız bir ödeme hatası, tam çıkışta binlerce kullanıcının sepette takılması demekti. Yarım günlük gecikmeye mal oldu; alternatifi, yorum bölümünde bir yıldızlı enkazdı.
İlk 48 saat boyunca çökme oranı ve kullanıcı yorumları ekibin masasındadır; çökme takibi için mağazaların kendi konsolları başlangıç olarak yeterli, ama biz genellikle bağımsız bir crash raporlama aracını da yanına koyarız — mağaza konsolları bazen saatler geriden gelir, kriz anında o saatler pahalıdır. geri alma planı — bir önceki sürüme dönüş ya da acil yama — yazılı olarak hazırdır. Mağaza görsellerini ve açıklama metnini de sabit görmeyiz; dönüşüm oranına göre A/B testine açarız. Mağaza sayfası bir vitrindir ve vitrinler bakılmadıkça bayatlar.
Ve yılların bize öğrettiği altın kural: ilk sürümü mükemmelleştirmeye çalışmayın, güncellenebilir yapın. Kusursuz ilk sürüm hayaliyle üç ay geciken lansman, mağazada var olup gerçek kullanıcı yorumlarıyla öğrenen ve iki haftada bir güncellenen uygulamaya her zaman kaybeder. Mağaza bir sınav değil; uzun bir sohbetin ilk cümlesi.
Yayın sürecine yaklaşan bir uygulamanız varsa, bu listeyi yayına haftalar kala bir kez baştan sona gezin — kontrolün kendisi çoğu zaman bir günlük iş; kazandırdığı, bazen bir lansman etkinliğinin kendisi. Store maceralarını konuşmayı severim; iletişim sayfası açık.