Review süreci sandığınız kadar mekanik değil
Video chat ve eşleşme odaklı bir uygulamayı App Store'a gönderirken sürecin “build yükle, bekle, yayınla” kadar basit olmadığı pratikte netleşiyor. Apple tarafında otomatik kontroller var; ancak son kararı çoğu zaman insan reviewer veriyor. Türkiye'den geliştirici olarak fark edilen nokta, kullanıcı sözleşmesi, gizlilik politikası, yaş sınırı ve uygulama içi metinlerin Türkçe/İngilizce tutarlılığının da aynı ölçüde incelenmesi. Özellikle sosyal, video veya finans kategorilerinde bu detaylar kritik — kod hazır olsa bile metadata ve policy eksikliği red getirir.
En sık görülen red sebepleri
Gizlilik politikası URL'si çalışmıyor veya uygulama içinden erişilemiyor — en sık karşılaşılan maddelerden biri. Uygulama açıklaması ile gerçek özellikler uyuşmuyor; reviewer ekranda gördüğüyle App Store Connect'teki metni karşılaştırıyor. Demo hesabı veya test akışı review notlarında net değilse reviewer uygulamayı açamıyor ve red geliyor. Video chat, eşleşme veya kullanıcı içeriği sunan uygulamalarda moderasyon planı belirsizse Guideline 1.2 ve ilgili maddeler devreye girer. Sign in with Apple kuralları ile üçüncü parti login kombinasyonu hatalıysa — özellikle Google veya e-posta login yan yana kullanıldığında — policy ihlali sayılır. Uygulama içi satın alma veya abonelik akışı App Store kurallarıyla çelişiyorsa, dijital içerik harici ödeme yönlendirmesi de ayrı bir risk alanıdır.
Tekrar göndermeden önce kontrol listesi
Her red sonrası aynı çerçeveyi kullanmak süreyi ciddi kısaltır. Review notlarına test kullanıcısı, adım adım akış ve varsa kısıtlı özelliklerin neden kapalı olduğunu yazın. Screenshot'ların gerçek UI ile eşleştiğini doğrulayın; marketing görseli ile inceleme build'i farklıysa güven kaybolur. Backend'de feature flag kullanılıyorsa review build'inde hangi özelliklerin açık olduğunu özellikle belirtin. Video altyapısında (LiveKit, Agora vb.) test ortamı ile prod ortamı ayrımı review sırasında kafa karıştırıcı olabilir — reviewer'ın hangi ortama bağlandığını anlaması gerekir. Red mesajındaki madde numarasını okuyup yalnızca o konuyu hedefleyen düzeltmeyi yapın; alakasız değişiklikler yeni red riski taşır.
Sahadan not: red, projenin bittiği anlamına gelmez
Red yemek çoğu zaman ürün kalitesinden değil; metadata, policy ve review iletişiminden kaynaklanır. Bunu proje başında planlamak launch süresini haftalarca kısaltır. İlk gönderimde her şeyi mükemmel beklemek yerine, policy dokümanlarını, demo akışını ve review notlarını kod kadar ciddiye almak gerekir. Özellikle yeni kategorilere giren ürünlerde — video, eşleşme, finans — Apple'ın önceki uygulamalardan edindiği şablon beklentileri devreye girer; “biz farklıyız” demek reviewer'ı ikna etmez, kanıt sunmak gerekir.
Review sürecini proje planına dahil edin
App Store tarihini “kod bitti + bir hafta” diye vermek gerçekçi değil. Policy hazırlığı, test build'leri, olası red döngüsü ve metadata işleri için buffer şart — özellikle fintech, dating ve video chat projelerinde. Keşif aşamasında review risklerini konuşmak, müşteri beklentisini doğru yönetmenin parçasıdır. Kod teslimi ile mağaza onayı aynı milestone değildir; ikisini ayırmayan planlar hem ekip hem müşteri tarafında hayal kırıklığı yaratır. Review sürecini proje planının bir fazı olarak ele almak, iOS ürünlerinde en az mimari karar kadar önemlidir.