iOS uygulaması yayınlayan her ekibin bir ret hikâyesi vardır. Genellikle şöyle gelişir: sürüm biter, yayın tarihi belirlenir, uygulama incelemeye gider ve iki gün sonra App Store Connect'e, ekipte kimsenin okumadığı bir madde numarasını gösteren bir mesaj düşer.
Çözüm nadiren birkaç satır koddur. Çoğu zaman kapsamda, ödemelerde ya da verinin işlenme biçiminde bir değişiklik gerekir; bu da tam olarak projenin sonunda pahalı, başında ucuz olan türden bir değişikliktir.
70'ten fazla uygulamayı App Review'dan geçirdik. Aklımızda kalan ders basit: App Review Guidelines'ı bir gereksinim belgesi gibi ele alın ve tasarım kesinleşmeden önce okuyun. Aşağıda, artık her iOS projesinin başında cevapladığımız soruları bulacaksınız.
Aşağıdaki madde numaraları bu yazıyı yazdığımız sırada kullanılanlardır. Apple bölümlerin numarasını ve ifadesini zaman zaman değiştirir; bunlardan herhangi birine güvenmeden önce güncel metni okuyun.
1. Bu uygulama bir web sitesinin yapamadığı neyi yapıyor?
Minimum işlevselliği düzenleyen 4.2 maddesi, pek çok ilk uygulamanın takıldığı yerdir. Büyük ölçüde bir web sitesini bir web görünümünün içine saran ya da sitenin ötesinde çok az şey sunan bir uygulamanın reddedilmesi kuvvetle muhtemeldir.
Bu yüzden kapsamla ilgili ilk soru, yerel (native) bir değer sunup sunmadığıdır. Bildirimler, çevrimdışı kullanım, kamera, konum, widget'lar ya da insanların her gün tekrarladığı bir iş için çok daha hızlı, yerel bir arayüz. Dürüst cevap "hiçbir şey" ise doğru ürün bir uygulama değil, iyi bir mobil web sitesi olabilir.
2. Bu tek bir uygulama mı, yoksa birbirinin aynısı on uygulama mı?
4.3 maddesi spam kuralıdır. Uygulamaları yalnızca ad, renk ya da birkaç metinle birbirinden ayrılan yayıncıları yakalar. Bu durum şubeleri, franchise'ları ya da birden fazla markası olan işletmeler ve kodu uygulamalar arasında yeniden kullanan stüdyolar için önemlidir.
Kodu yeniden kullanmakta bir sakınca yoktur. Sakıncalı olan, incelemecinin birbirinden ayıramadığı uygulamalar yayınlamaktır. İki soru yardımcı olur:
- Konum ya da marka seçicisi olan tek bir uygulama, kullanıcılara şube başına ayrı birer uygulamadan daha iyi hizmet eder mi?
- Uygulamalar aynı şablonu paylaşıyorsa, her birinin kendi amacı, içeriği ve deneyimi var mı?
3. Bu uygulama nasıl para kazanacak?
3.1.1 maddesi uygulama içi satın almayı kapsar. Kabaca şöyle: kullanıcının ödeme yaptığı şey uygulamanın içinde açılıp kullanılıyorsa Apple bunun kendi ödeme sisteminden geçmesini bekler; fiziksel bir ürünse ya da taksi yolculuğu veya ev temizliği gibi gerçek dünyada sunulan bir hizmetse beklemez. Bazı bölgeler artık belirli programlar çerçevesinde harici ödeme bağlantılarına izin veriyor; bu kurallar ülkeden ülkeye değiştiği için projenin yapıldığı dönemde kontrol edilmeleri gerekir.
Bu soru yalnızca ödeme ekranını değil, ürünün kendisini değiştirir. Fiyatlandırmayı (mağaza komisyonları), hesap modelini, satın alımların nasıl geri yükleneceğini ve ödeme duvarının (paywall) kendisini etkiler; ödeme duvarı kullanıcının ne ödediğini, ne sıklıkla ödediğini ve aboneliğin kendiliğinden yenilendiğini açıkça söylemek zorundadır. Bu kararı baştan vermek, yayından bir hafta önce ödeme duvarını yeniden tasarlamak zorunda kalmanın önüne geçer.
4. Hangi veriyi topluyoruz ve neden?
5.1 maddesi gizliliği ve veri toplamayı kapsar. Erkenden netleştirilmesi gereken sorular:
- Uygulamanın gerçekten hangi izinlere ihtiyacı var? Her izin isteğinin belirli ve dürüst bir amaç açıklaması olmalı.
- Kullanıcı bir izni reddederse ne oluyor? Uygulamanın geri kalanı çalışmaya devam etmeli.
- Kayıt uygulamanın içinden yapılıyorsa, hesap silme de oradan yapılabiliyor mu?
- Bir gizlilik politikası var mı ve App Store'daki gizlilik bilgileri, analiz ve reklam için kullanılan üçüncü taraf SDK'lar dahil, uygulamanın gerçekte yaptığıyla örtüşüyor mu?
Yapay zekâ özellikleri olan uygulamalar için bir soru daha ekleyin: hangi veri hangi sağlayıcıya gönderiliyor ve kullanıcıya bu söyleniyor mu? Sağlayıcı anahtarlarını ve istemleri (prompt) uygulamanın içinde değil kendi sunucunuzda tutmak, bu soruyu dürüstçe cevaplamayı ve ileride sağlayıcı değiştirmeyi de kolaylaştırır.
5. İncelemeci her özelliğe gerçekten ulaşabiliyor mu?
Uygulamanın eksiksiz olmasıyla ilgili 2.1 maddesi, en sık karşılaşılan ret sebeplerinden biridir. Bir çökmeye, hiç bitmeyen bir yükleme simgesine ya da bir giriş duvarına takılan incelemeci sürümü reddeder.
İncelemeciyi en baştan bir kullanıcı gibi düşünüp planlayın:
- İçinde hâlihazırda veri bulunan bir demo hesabın test giriş bilgileri; böylece incelemeci boş ekranlarla karşılaşmaz.
- İnceleme süresince ayakta kalan bir sunucu; geceleri uykuya geçen bir test sunucusu değil.
- Özel donanım, belirli bir konum ya da ikinci bir cihaz gerektiren özellikler için kısa bir not ya da bir demo videosu.
- Yalnızca simülatörde değil, eski bir iPhone'da ve en yeni modelde yapılan bir TestFlight turu.
6. Ekran görüntüleri ve açıklama sürümle örtüşüyor mu?
Meta veriler de incelenir. Sürümde olmayan özellikleri gösteren ekran görüntüleri ya da uygulamanın sunduğundan fazlasını vaat eden bir açıklama, meta verilerin doğruluğuyla ilgili kurallar gereği redde yol açabilir.
En ucuz çözüm, mağaza sayfasını özellik dondurmasından sonra, incelemecinin göreceği sürümden hazırlamak ve hâlâ yol haritasında duran bir şeyi gösteren her ekran görüntüsünü çıkarmaktır.
7. İnceleme sonucu geldiğinde kim cevap veriyor?
İyi hazırlanmış uygulamalara bile bazen soru gelir. Resolution Center mesajlarını kimin okuyup cevaplayacağına ve bunun ne kadar hızlı olacağına karar verin. Kısa ve net bir cevap, gerekirse bir ekran kaydıyla birlikte, pek çok durumu yeniden gönderimden daha iyi çözer. Yalnızca mağaza sayfasında olan sorunlar için yeni bir derleme (binary) gerekmez. Ekip kararın yanlış olduğunu düşünüyorsa Apple'ın resmi bir itiraz yolu da vardır.
Son söz
App Review, son gece sabahlayarak çalışılan bir final sınavı değildir. Kurallarının çoğu aslında ürün kararlarını tarif eder: uygulama neden var, nasıl para kazanıyor, hangi verilere dokunuyor ve uygulamayı hiç görmemiş biri onu ilk denemede kullanabiliyor mu? Bunları baştan cevaplayın, gönderim günü sıradan bir iş gününe dönüşsün.
BernSoftware'de bu soruları her iOS ve Android projesinin başında, ilk sürümle beraber hazırladığımız mağaza meta verilerinin ve ekran görüntülerinin yanında kullanıyoruz.
Böyle bir proje mi planlıyorsun?
10 adımda planla