Apple editörün seçimi olmak: Bir indie geliştiricinin reddedilme ve kabul süreci

App Store’a göndermeye hazır olduğunuzu düşündüğünüz anla, Apple’ın gerçekten aynı fikirde olduğu an arasında ciddi bir mesafe var. Türkiye’de çalışan indie ekipler bu mesafeyi genelde ilk ret e-postasında fark ediyor. Uygulama stabil olabilir, tasarım temiz görünebilir, hatta ilk kullanıcı testlerinden iyi geri bildirim de almış olabilirsiniz. Yine de App Review masasında bambaşka bir gerçeklik var.

Apple editörün seçimi olmak: bir indie geliştiricinin reddedilme ve kabul süreci, dışarıdan bakıldığında vitrindeki bir başarı hikâyesi gibi görünür. İçeriden bakınca ise kayıt, doğrulama, guideline uyumu, KVKK, ASO, görsel anlatım, itiraz yönetimi ve kabul sonrası sürdürülebilir kalite zinciridir. Zincirin tek bir halkası zayıfsa, uygulama ya reddedilir ya da kabul edilse bile görünürlük üretmez.

Türkiye’de iş daha da yereldir. Sadece İngilizce kural setini okuyup ilerlemek çoğu zaman yetmez. Ödeme adımı, Apple ID enrollment sorunları, Türkçe mağaza sayfası dili, kullanıcıların beklentisi, izin akışlarının açıklığı ve veri toplama ekranlarının KVKK ile uyumlu kurgulanması sonucu doğrudan etkiler. Masadaki soru şudur: Uygulama çalışıyor mu değil. Uygulama, Apple’ın kalite çıtasını ve Türkiye pazarının hassasiyetlerini birlikte karşılıyor mu?

Giriş: Editörün Seçimi Hayalinden Gerçeğe Giden Yol

Bir indie geliştiricinin hayali genelde aynıdır. Uygulamanın App Store’da öne çıkması, ana sayfada görünmesi ve kullanıcıların “bunu denemeliyim” diyeceği bir kalite sinyali üretmesi.

Bu hayal romantik tarafı olan bir hedef gibi anlatılır. Pratikteyse operasyonel bir disiplindir. Apple’ın dikkatini çeken uygulamalar sadece iyi fikirler değildir. Net çalışan, güven veren, yerelleştirilmiş ve anlatımı güçlü ürünlerdir.

İlk duvar kayıt aşamasında çıkar

Türkiye’de indie geliştiriciler için Apple Developer Program üyeliği yıllık 749 TL’dir ve süreçte yaşanan teknik aksaklıklar nedeniyle ilk başvuruların %70’inden fazlası en az bir kez reddedilmektedir. Yaygın reddedilme nedenleri arasında %35 ile UI/UX uyumsuzluğu ve %25 ile gizlilik politikası eksiklikleri yer alır. Bu çerçeve, sürecin daha en başında ne kadar kırılgan olduğunu gösteriyor.

Kısacası ilk engel, uygulamanın kendisi bile olmayabiliyor. Hesap açılışı, doğrulama ve enrollment süreci bile sizi yavaşlatabiliyor.

Pratik gerçek: App Store başarısı çoğu zaman koddan önce operasyonla başlar.

Editörün Seçimi bir şans oyunu değil

Pek çok ekip, “önce bir yayınlayalım, sonra düzeltiriz” yaklaşımıyla ilerliyor. Bu yaklaşım Apple tarafında çoğunlukla pahalıya patlar. Çünkü ilk izlenim sadece kullanıcı için değil, inceleme ekibi için de belirleyicidir.

Editörün Seçimi hedefleyen bir uygulama şu soruların hepsine güçlü cevap vermelidir:

• Ne çözüyor

• Neden şimdi önemli

• Neden iPhone’da daha iyi çalışıyor

• Neden Türkiye’deki kullanıcı için güven veriyor

• Neden mağaza sayfası uygulamanın kalitesini doğru temsil ediyor

Bu yazıda odak noktası tam burada. Genel Apple kurallarını tekrar etmek yerine, Türkiye’de reddedilme ve kabul sürecini gerçekten etkileyen noktaları ele alacağım. Özellikle lokalizasyon, KVKK, görsel sunum, itiraz dili ve kabul sonrası görünürlük yönetimi arasındaki bağlantı kritik.

Başvurudan Önce Stratejik Hazırlık Aşaması

Kod bittiğinde hazırlık bitmiş olmuyor. Aslında en kritik kalite kararları koddan önce veriliyor. Uygulamanın nasıl hissettirdiği, hangi kullanıcı davranışını hedeflediği ve hangi yerel beklentilere cevap verdiği App Review sonucunu doğrudan şekillendiriyor.

Türkiye pazarında sadece çeviri yetmez

Türkiye App Store’da son 12 ayda indie uygulamaların %62’si UI/UX ve KVKK uyumsuzluğu nedeniyle reddedildi. Buna karşılık biyometrik doğrulama ve yerel regülasyonlara uyum gibi özellikler entegre edildiğinde kabul şansının %35 arttığı gözlemlenmiştir (Yandex özet içeriği).

Bu veri, yerelleştirmenin neden metin çevirisinden ibaret olmadığını net gösteriyor. Türkiye’de kullanıcı güveni, özellikle ödeme, kimlik doğrulama, izin ekranı ve veri saklama açıklamalarında çok hızlı kırılıyor. Apple da bunu fark ediyor.

Şu hatalar sık görülür:

• Evrensel ama yüzeysel tasarım dili. Arayüz temizdir ama Türkçe metinler taşar, hata mesajları yarım kalır, tarih ve para birimi kullanımı doğal hissettirmez.

• KVKK’yı sonradan ekleme refleksi. Gizlilik politikası vardır ama veri toplama akışına ürün seviyesinde işlenmemiştir.

• İzin isteme sıralamasının yanlış kurgulanması. Uygulama daha değer göstermeden kamera, konum, rehber veya bildirim izni ister.

• Kültürel bağlamı kaçıran onboarding. Kullanıcı neye izin verdiğini ve karşılığında ne alacağını anlamaz.

İyi bir referans için kullanıcı dostu mobil arayüz tasarımı yaklaşımına bakmak faydalı olur. Özellikle arayüz kararlarını sadece estetik değil görev tamamlama mantığıyla ele almak gerekir.

Editörlük değeri taşıyan ürün nasıl kurulur

Apple editörleri teknik doğruluğa bakar ama sadece ona bakmaz. Uygulamanın karakteri olmalıdır. Bunun için üç şey aranır.

Net ürün odağı

Bir uygulama çok şey yapmaya çalıştığında, genelde hiçbir şeyi yeterince iyi yapamaz. Editörlük potansiyeli olan indie ürünlerde ana kullanım senaryosu ilk dakikada anlaşılır.

Örneğin görev yönetimi uygulaması yapıyorsanız, onu bir “hepsi bir arada yaşam platformu” gibi sunmak yerine tek bir davranışı mükemmelleştirmek daha etkili olur. Hızlı ekleme, temiz liste akışı, iyi widget mantığı, güçlü arama gibi.

Privacy by design

Gizlilik politikası bir PDF değil, ürün davranışıdır. Kullanıcı verisi toplanıyorsa neden toplandığı, ne zaman işlendiği ve kullanıcıya nasıl açıklandığı arayüzde görünmelidir.

Veri toplama kararını hukuk metnine bırakmak yerine ürün akışına yerleştirin. Apple bunu daha güvenilir bulur.

Marka dili ve görsel bütünlük

Editörün Seçimi adaylarında ekran ekran kopan bir deneyim olmaz. İkonografi, renk kullanımı, yazım tonu, onboarding dili ve ekran görüntülerinin mağaza anlatımı birbiriyle tutarlı olmalıdır.

Bu aşamada “çalışıyor” eşiği yeterli değil. “Derli toplu, niyetini açık anlatıyor ve güven veriyor” eşiğine çıkmanız gerekir.

App Store Gönderim Sürecinin Teknik İncelikleri

Gönderim aşaması, ürünün teknik kalite kontrolü kadar mağaza içi hikâye anlatımıdır. App Store Connect’e aceleyle girilen her alan sonradan ret, düşük dönüşüm veya görünürlük kaybı olarak geri dönebilir.

Burada en büyük hata şu: Ekipler gönderimi dağıtım işi sanıyor. Oysa gönderim, ürün pozisyonlamasının son ve çok görünür adımıdır.

App Store Connect ekranında hata yapılan yerler

Türkiye’deki indie geliştiricilerin yaklaşık %40’ı ilk başvurularında Guideline 2.1 App Completeness nedeniyle ret alıyor. Başarı için 4.8 ve üzeri kullanıcı puanı, 100.000’den fazla organik indirme ve %0.5’in altında çökme oranı gibi metrikler hedeflenmelidir.

Bu veri iki şeyi söylüyor. Birincisi, eksik ürün göndermek hâlâ en büyük problemlerden biri. İkincisi, Editörün Seçimi seviyesi için yayın almak yetmiyor, mağaza sonrası ürün kalitesi de sürekli güçlü kalmalı.

App Store gönderim akışında şu alanlar kritik:

Uygulama adı ve alt başlık

Anahtar kelime doldurmak yerine değer önerisini net yazın. Türkçe kullanıcı ne aradığını hızlı anlamalı. Belirsiz yaratıcı isimler marka için iyi olabilir ama keşfedilebilirlikte zayıf kalabilir.

Ekran görüntüleri

Ekran görüntüleri özellik listesi değil, kullanım vaadi sunmalıdır. İlk iki görsel özellikle güçlü olmalı. Çünkü kullanıcı çoğu zaman önce ekranlara bakar, açıklamayı sonra okur.

Açıklama metni

Apple inceleme ekibi ile son kullanıcı aynı metni okumaz ama ikisi de tutarsızlığı fark eder. Ürün açıklaması uygulamada olmayan vaatte bulunmamalı.

Detaylı gönderim süreci mantığını fikir aşamasından yayına mobil yazılım geliştirme akışı üzerinden düşünmek yararlı olur. Özellikle test, release hazırlığı ve mağaza metni birbirinden kopuk ilerlememeli.

Ret nedenlerini teknik açıdan okumak

Aşağıdaki tablo, pratikte en sık karşılaşılan ret başlıklarını ve düzeltilme yönünü özetler.

Teknik olarak çalışan uygulama neden yine de kaybeder

Çünkü Apple yalnızca hata avı yapmıyor. Ürünün tamamlanmış olup olmadığına bakıyor. Bir ekranın “teknik olarak açılması” ile “ürün olarak ikna edici olması” aynı şey değil.

İnceleme öncesinde şu kısa kontrol işe yarar:

• Gerçek cihaz testi yapıldı mı

• TestFlight senaryoları tamamlandı mı

• Review notları açık ve kısa mı

• Giriş gerektiren alanlar için test hesabı hazır mı

• Türkçe metin taşmaları kontrol edildi mi

• Mağaza görselleri ile gerçek ürün aynı vaat üzerinde mi

Reddedilme Duvarını Aşmak: İletişim ve İtiraz Yöntemleri

Ret almak kötü hissettirir ama asıl sorun ret değil, ret sonrasında ekibin verdiği tepkidir. Savunmaya geçen ekipler süreci uzatır. Soğukkanlı kalan ekipler ise aynı bildirimi bir düzeltme planına çevirir.

En pahalı hata, ret mesajını yüzeysel okumaktır. Apple çoğu zaman neyi sorun gördüğünü söyler. Ekipler bazen o cümleyi atlayıp doğrudan yeniden gönderim yapar. Sonuç, ikinci ret olur.

En çok takılan maddeleri doğru okumak

Türkiye’de indie geliştiriciler arasındaki reddedilme vakalarının %42’si, özellikle Guideline 4.2 Minimum İşlevsellik ve 5.1.1 Veri Toplama maddeleriyle ilişkilidir. Reddedilme sonrası Developer Support’a 72 saat içinde yapılan itirazların başarı oranı ise yaklaşık %25’tir (Yandex how-to özeti).

Bu oran şunu gösteriyor. İtirazın anlamı var ama sadece gerçekten hazırlanmışsa. “Bizi yanlış anlamışsınız” tonu işe yaramaz. “Sorunu şu şekilde anladık, şu şekilde düzelttik, şu adımla doğrulayabilirsiniz” tonu çalışır.

Resolution Center dilini profesyonelleştirin

İyi iletişim kısa, net ve doğrulanabilir olur. Şu yapı pratikte daha güvenilir görünür:

1. Sorunu kabul edin. Ret maddesini doğru anladığınızı gösterin.

2. Düzeltmeyi tanımlayın. Hangi ekranda neyi değiştirdiğinizi yazın.

3. Doğrulama yolu verin. İnceleme ekibinin hangi kullanıcı akışıyla bunu test edeceğini belirtin.

4. Gerekirse kanıt ekleyin. Kısa ekran kaydı veya adım listesi çok işe yarar.

Kötü örnek: “Sorun göremedik, lütfen tekrar inceleyin.”

İyi örnek mantığı: “Guideline 5.1.1 kapsamında veri toplama akışını güncelledik. Konum izni artık onboarding’in ilk ekranında değil, ilgili özelliğin kullanım anında isteniyor. Açıklama metni güncellendi. Test için şu hesapla şu adımı izleyebilirsiniz.”

İtiraz, duygusal savunma değil. İnceleme ekibinin işini kolaylaştıran teknik bir açıklamadır.

Ne zaman itiraz edilmeli, ne zaman ürün düzeltilmeli

Her ret itiraz edilmemeli. Bazen en hızlı yol kabul etmektir. Özellikle eksik onboarding, bozuk akış, belirsiz izin mantığı gibi alanlarda doğrudan düzeltme daha akıllıdır.

İtiraz şu durumda mantıklıdır:

• Ret gerekçesi uygulamanın gerçek davranışını yanlış yorumluyorsa

• İnceleme ekibi bir özelliği doğru test etmemiş görünüyorsa

• Uygulama işlevi, guideline ihlali gibi değil bağlam eksikliği gibi duruyorsa

Düzeltme ise şu durumda öne çıkar:

• Arayüz gerçekten tutarsızsa

• Veri toplama akışı açık değilse

• Minimum işlevsellik sorusu haklıysa

• Uygulama, mağaza metninde vaat ettiği şeyi yeterince göstermiyorsa

İyi ekipler ret e-postasına kızmaz. Ondan görev listesi çıkarır.

Kabul Sonrası Görünürlüğü Korumak ve Büyütmek

Kabul aldığınız gün işin kolay kısmı biter. Çünkü görünürlük, mağazaya girmenin değil mağazada kalmanın sonucudur. Editörün Seçimi hedefi olan ürünlerde bu daha da belirgindir.

İlk indirme dalgası değerlidir ama yanıltıcı olabilir. Uygulama aniden daha çok kullanıcıya ulaştığında yorumlar sertleşir, crash etkisi büyür ve ürün eksikleri daha görünür hâle gelir.

Kabul sonrası ilk haftalarda neye bakılır

Burada odak, sadece yeni kullanıcı kazanımı değil kaliteyi korumaktır. Özellikle üç sinyal önemlidir.

Kullanıcı yorumu tonu

Yorumların puanı kadar içeriği de önemlidir. Kullanıcılar aynı sorunu tekrar ediyorsa ürün ekibinin önceliği bellidir. Sessiz kalmak yerine mağaza yorumlarına yapıcı cevap vermek güven üretir.

Güncelleme ritmi

Apple, yaşayan ürünleri sever. Bu, rastgele sık sürüm çıkarmak anlamına gelmez. Hata düzeltmeleri, deneyim iyileştirmeleri ve iOS değişikliklerine hızlı uyum önemlidir.

ASO’nun canlı yönetimi

Kabul aldıktan sonra mağaza metni taşlaşmamalı. Hangi ekran görüntüsünün daha iyi anlattığı, hangi alt başlığın daha net olduğu ve hangi yerel ifadelerin dönüşüm yarattığı düzenli gözden geçirilmeli. Bu konuda ASO rehberi ve mağaza optimizasyonu yaklaşımı faydalı bir çalışma çerçevesi sunar.

Görünürlük neden kaybolur

Bunu genelde tek bir büyük hata değil, küçük ihmaller yapar.

• Stabilite sorunu kullanıcı güvenini hızlı aşındırır.

• Yanıtsız yorumlar mağaza sayfasını pasif gösterir.

• Eski ekran görüntüleri ürünün güncel kimliğini yansıtmaz.

• Yerel beklentilerin değişmesi yeni sürümlerde karşılıksız kalır.

Kabul sonrası büyüme, pazarlama ekibinin tek başına taşıyacağı bir iş değildir. Ürün, tasarım, destek ve yayın operasyonu birlikte çalışır.

Sürdürülebilirlik için pratik çerçeve

Kabulden sonra iyi çalışan ekipler şu düzeni kurar:

Editörün Seçimi bir etiket olabilir. Kalıcı değer ise ürünün kendisinde oluşur.

Sıkça Sorulan Sorular ve Eylem Kontrol Listesi

Bu sürece giren ekiplerin sorduğu sorular çoğunlukla aynı yere çıkıyor. “Önce neyi düzeltmeliyiz” sorusu, “nasıl öne çıkarız” sorusundan daha önemlidir.

Sık sorulan kısa sorular

Editörün Seçimi için ücretli reklam şart mı

Hayır. Editör kararı ürün kalitesi, deneyim ve mağaza sunumu ile ilgilidir. Reklam kampanyaları dikkat çekebilir ama zayıf ürünü güçlü göstermez.

Uygulama ilk seferde reddedildiyse umut biter mi

Bitmez. Birçok ekip için ret, gerçek kalite kontrolünün başladığı andır. Sorun doğru okunursa ikinci gönderim çok daha güçlü olabilir.

Türkçe lokalizasyon gerçekten bu kadar önemli mi

Evet. Türkiye pazarında dil, güven ve regülasyon aynı denklemde çalışır. Özellikle KVKK ile ilişkili veri toplama ekranlarında yarım çeviri ya da belirsiz ifade ciddi risk yaratır.

Apple editörlerine uygulamayı tanıtmak mümkün mü

Evet, tanıtım talebi mantıklıdır. Ama başvuru yapmadan önce ürünün gerçekten hikâyesi, görsel bütünlüğü ve teknik olgunluğu olmalıdır. Zayıf ürünün tanıtım formu güçlü sonuç üretmez.

Eylem kontrol listesi

Aşağıdaki listeyi gönderim öncesi son kontrol gibi kullanın:

• Developer hesabını erken açın. Enrollment sorunları takvimi kaydırabilir.

• Türkçe arayüzü gerçek cihazda test edin. Taşan metinleri simülatörde kaçırmak kolaydır.

• KVKK mantığını ürün akışına yerleştirin. Sadece politika sayfası eklemek yetmez.

• İzin ekranlarını bağlamsal kurun. Kullanıcı neden izin verdiğini anlamalı.

• TestFlight ile uçtan uca senaryo deneyin. Kayıt, giriş, ödeme, paylaşım, bildirim gibi tüm kritik akışlar doğrulanmalı.

• Mağaza görsellerini yeniden yazın. Görsel başlıklar özellik değil değer anlatmalı.

• Review notlarını hazırlayın. Gerekli test hesabı, özel adımlar ve açıklamalar kısa olmalı.

• Ret alırsanız aynı gün tepki vermeyin. Önce sorunu sınıflandırın, sonra net cevap verin.

• İtiraz edecekseniz kanıtla gidin. Ekran kaydı, test hesabı ve kısa açıklama birlikte daha ikna edicidir.

• Kabul sonrası güncelleme planını önceden oluşturun. Yayına çıkmak son adım değildir.

Bu sürece tek başına girmek zorunda değilsiniz. Ürününüzü App Store yayınına, ASO’ya, KVKK uyumuna ve kabul sonrası büyüme planına göre değerlendirmek isterseniz İpek Yazılım ile iletişime geçebilirsiniz. Yüzlerce projede biriken yayın deneyimi, özellikle Türkiye pazarına özgü hataları daha ürün mağazaya gitmeden görmenizi sağlar.