Uygulama yaptırmayı düşünen herkesin er geç sorduğu soru şu: "Apple onaylamazsa ne olacak?"
Bu sorunun dürüst cevabı "biz iyi yapıyoruz, reddedilmez" değil. Reddedilir. Bizim 2026 yazında App Store'a taşıdığımız iki uygulamanın ikisi de reddedildi, ikisi de sonra onaylandı. Bu yazı o iki yazışmanın ne olduğunu, ne cevap verdiğimizi ve kaç gün sürdüğünü anlatıyor — çünkü bu bilginin Türkçesi ortada yok ve müşteri bunu bilmeden karar veremiyor.
Kısa cevap: ret bir felaket değil, sürecin normal bir adımı. Süreyi belirleyen şey reddin kendisi değil, cevabı ne kadar hazır verdiğiniz.
Ret 1 — Kural 2.1: "Information Needed"
Reis Yachting için geliştirdiğimiz SeaApp'in ilk sürümü (1.0, build 2) Apple'dan 2.1 Information Needed ile döndü. Bu ret türü, "uygulamanız kötü" demez. "Ne yaptığını göremedim, anlat" der.
Bu ayrım önemli, çünkü panik tepkisi kod değiştirmektir. Oysa 2.1'de değiştirilecek bir şey olmayabilir; eksik olan gösterimdir. SeaApp bir yat servis ve teklif yönetimi uygulaması — inceleyen kişi denemek için içeriye girmeli, bir teklif oluşturmalı, PDF'in üretildiğini görmeli. Bunu kendi başına keşfetmesi beklenemez.
Verdiğimiz cevap üç parçaydı:
- Yazılı cevap — hangi ekranda ne yapılacağı, sırayla. (Reply alanı 4.000 karakter.)
- App Review Notes — demo hesabı ve akışın özeti. (Bu alan da 4.000 karakter ve ayrı bir alan; ikisini birden doldurmak gerekiyor.)
- 7 dakikalık ekran kaydı — uygulamanın baştan sona kullanıldığı, konuşmasız bir video.
Video, işi bitiren parçaydı. Bir 2.1 reddinde inceleyene "şuraya bak" demenin en kısa yolu, ona baktırmaktır.
Video eklerken kaybettiğimiz saatler
Videoyu yüklemek, çekmekten uzun sürdü. Öğrendiklerimiz, aynı yerde takılacaklar için:
.m4vuzantısı reddediliyor. App Store Connect web arayüzü "An error has occurred" diyor, API 500 dönüyor. Aynı dosyayı.mp4adıyla yüklediğimizde ikisi de kabul etti. Hata mesajı bunu söylemiyor.- Sıkıştırma: dikey iPhone kaydını
avconvert --preset PresetAppleM4V1080pHDile 500×1080 H.264'e indirdik; 7 dakika ≈ 112 MB ve ekrandaki metin okunabilir kaldı. 720p ön ayarı 332×720 veriyor — kullanmayın, yazılar okunmuyor. HEVC 1920×1080 ön ayarı yeterince küçültmüyor. - Büyük ekler için API:
POST /appStoreReviewAttachmentsile kayıt açılıyor, dosyauploadOperations'a 5 MB'lık parçalar hâlinde PUT ediliyor, sonraPATCH uploaded=truevesourceFileChecksum=md5. Tarayıcı üzerinden yüklemenin tıkandığı yerde bu yol çalışıyor.
Ve "Resubmit" düğmesinin pasif olması
Cevabı yazdıktan sonra beklenen şey, gönderim sayfasındaki Resubmit to App Review düğmesine basmaktır. Ret sonrası o düğme pasif geliyor ve neden olduğu hiçbir yerde yazmıyor.
Çalışan sıra şu: sürümde herhangi bir düzenleme yapın — App Review Notes'u değiştirmek yeter — sonra sürüm sayfasındaki Update Review'a basın. Sürüm Ready for Review'a döner ve gönderim sayfasındaki Resubmit düğmesi açılır.
Bunu API ile kestirmeden yapmayı denedik: PATCH /reviewSubmissions {submitted:true} otomatik istemci sınıflandırıcısı tarafından engellendi. Bu adım tarayıcıdan yapılıyor.
Sonuç
Cevap ve ekler gittikten sonra sürüm 09:00 UTC'de yeniden incelemeye girdi ve ertesi gün onaylandı. Toplam kayıp: bir gün ve bir video.
Ret 2 — Kural 3.1.2: abonelik
İkinci ret ULAK'ta geldi ve tamamen farklı bir cinsti. 3.1.2, abonelikli uygulamaların uyması gereken sunum kurallarıyla ilgili — burada gerçekten eksik bir şey vardı, anlatım sorunu değildi.
Abonelik satan bir uygulamayı göndermeden önce Apple'ın istediği liste, o retten sonra bizde kalıcı bir kontrol listesine dönüştü:
- App Store açıklama metninde EULA (kullanım koşulları) ve gizlilik politikası bağlantısı bulunmalı — uygulama içinde olması yetmiyor.
- Abonelik grubunun yerelleştirmesi (grup görünen adı) doldurulmuş olmalı.
- Her abonelik için ayrı inceleme görüntüsü yüklenmeli.
Üçü de "form doldurma" işi ve üçü de unutuluyor, çünkü uygulamanın kendisiyle ilgili değiller. Retten öğrenilen şey teknik değildi: abonelikli bir uygulamada gönderim işi, geliştirme işinden ayrı bir iştir.
Bunu müşteriye nasıl anlatıyoruz
Teklif aşamasında konuşurken şunu söylüyoruz, çünkü doğru olan bu:
Uygulamanız büyük ihtimalle ilk gönderimde onaylanmayacak. Bu bir kalite işareti değil; Apple'ın süreci böyle işliyor. Önemli olan cevabın ne kadar hızlı gittiği — bizde gecikme genellikle bir gün, bir hafta değil.
Pratikte işleyen üç alışkanlık:
- App Review Notes'u ilk gönderimde doldurun. Demo hesabı, giriş bilgileri, "şu düğmeye basınca şu olur". 2.1 retlerinin çoğu buradan gelmiyor diye değil — tam olarak buradan geldiği için.
- Videoyu ret gelmeden hazırlayın. Uygulamayı zaten baştan sona test ediyorsunuz; o oturumu kaydedin. Ret geldiğinde elinizde hazır olsun.
- Yayını "Manually release this version" ile gönderin. Onay, yayın demek değil. Onaylanmış ama sizin basmanızı bekleyen bir sürüm, her zaman elinizde kalan bir karar demektir — hem lansman zamanlaması hem ticari sebeplerle.
Kaç gün sürüyor?
Bizim iki dosyamızdaki gerçek rakamlar:
| Uygulama | Ret | Sonuç |
|---|---|---|
| SeaApp 1.0 (2) | 2.1 — Information Needed | Cevap + video → ertesi gün onay |
| ULAK | 3.1.2 — abonelik sunumu | Eksik alanlar tamamlandı → onay |
| ULAK 1.1 (6) | — | Doğrudan onay |
| Garage Book 1.0.3 | — | Doğrudan onay |
Yani: ilk sürümler zorlanıyor, sonraki sürümler akıyor. İlk gönderimde harcadığınız özen, sonraki her güncellemede geri geliyor.
Uygulama yaptırmayı düşünüyorsanız ve bu sürecin sizin işinizde nasıl görüneceğini konuşmak isterseniz — yazın. Süreyi ve riski baştan söylemeyi tercih ediyoruz.