Uygulama Reddi Nedenleri Nelerdir? En Sık Görülen Red Sebepleri

Bu rehber tek bir kuralı anlatmaz; en sık rastlanan uygulama reddi nedenlerinin genel haritasını çizer. Şablon görünümlü başvurularla ilgili ayrıntıyı App Store şablon ve spam reddi yazımızda, Apple'ın zorunlu hesap silme kuralını ise ilgili yazımızda ayrıntılı bulursunuz. Burada ikisini tekrar anlatmak yerine tüm red kategorilerine kuşbakışı bakarız.

Ekibimiz uygulama geliştirme sürecinde bu kategorileri düzenli olarak takip eder. İşletme sahibi için önemli olan tek bir maddeyi ezberlemek değil, teslim öncesi hangi başlıkları kontrol etmesi gerektiğini bilmektir. Bu nedenle rehberi kısa, kontrol edilebilir bir harita gibi kurduk.

Apple ve Google Hangi Ortak Kritere Göre Karar Verir?

İki mağaza da benzer beş başlıkta inceleme yapar; ayrıntılarını aşağıda listeleriz. Apple bu başlıkları App Store İnceleme Yönergeleri içinde toplar. Google ise aynı mantığı Geliştirici Programı Politikaları içinde toplar.

Dolayısıyla aynı hata her iki mağazada da benzer bir sonuç doğurur. Eksik bir izin açıklaması hem App Store hem Google Play'de red riski taşır. Bu yüzden tek platforma göre değil, her iki listeyi birlikte düşünerek hazırlanmak daha güvenlidir.

• Güvenlik ve içerik: zararlı içerik, taciz, yanıltıcı sağlık iddiası.
• Teknik performans: çökme, eksik işlevsellik, hatalı bağlantı.
• İş modeli: ödeme akışı, abonelik şartları, komisyon kuralları.
• Tasarım: kopya arayüz, minimum işlevsellik, kullanıcı deneyimi.
• Gizlilik ve hukuk: veri toplama, fikri mülkiyet, yasal sorumluluk.

Her iki listenin güncel madde numarası zaman zaman değişir. Siz de teslimden önce resmi geliştirici sayfasını açıp güncel metni kontrol edersiniz. Böylece eski bir kurala göre hazırladığınız bir kontrol listesine değil, her zaman güncel kaynağa güvenirsiniz.

Teknik Hatalar Uygulama Reddi Nedenleri Arasında Neden İlk Sırada Durur?

Teknik hatalar listenin başında durur, çünkü inceleme ekibi cihazda gerçek bir test yapar. Uygulama açılışta çöküyorsa, bir ekran boş kalıyorsa veya bir düğme hiçbir şey yapmıyorsa inceleme ekibi başvuruyu genellikle doğrudan geri gönderir.

Ayrıca yarım kalmış özellikler de aynı kategoriye girer. Örnekler arasında "yakında" yazan bir sekme, çalışmayan bir arama kutusu ve test amaçlı unuttuğunuz sahte metin yer alır. İnceleme ekibi bu izleri hemen fark eder ve ürünün bitmediğini anlar. Siz yayına almadan önce her ekranı gerçek bir cihazda uçtan uca denersiniz.

Örnek bir senaryo kuralım: bir teslimat uygulaması, harita ekranını yalnızca test cihazında açılan sahte koordinatla gösterebilir. Bu durumda inceleme ekibi gerçek konum servisini çalışır bulamaz ve uygulamayı geri çevirir. Böylece hem kullanıcı deneyimi hem de ilk inceleme süreci daha sorunsuz ilerler. Teknik testi atlayan ekipler aynı hatayla ikinci kez de karşılaşır.

Ayrıca yavaş açılış süresi, donan bir yükleme ekranı veya sık tekrarlayan hata uyarısı da aynı başlığa girer. İnceleme ekibi bu tür tekrarlayan sorunları kısa bir kullanım sırasında kolayca fark eder.

Benzer bir risk, uygulamanın bazı cihazlarda veya işletim sistemi sürümlerinde farklı davranmasıdır. Küçük bir ekran boyutunda düğme dışarı taşabilir, eski bir sürümde bir özellik hiç açılmayabilir. Bu yüzden teslim öncesi en az iki farklı cihazda ve iki farklı sürümde kısa bir tur yaparsınız; bu tur, çoğu zaman tek cihazda görünmeyen bir sorunu ortaya çıkarır.

Eksik ya da Yarım İşlevsellik Mağazaları Nasıl Durdurur?

Mağazalar, sadece bir web sitesini pencereye sarıp mobil uygulama gibi sunan başvuruları kabul etmez. Gerçek bir fayda taşımayan bir başvuru da aynı kaderi paylaşır. Mağazalar, uygulamanın kendine özgü ve bağımsız bir değer taşımasını ister.

Bu nedenle ilk sürümü planlarken "minimum işlevsellik" sorusunu baştan sorarsınız. Uygulama tek başına, internetsiz bir web sayfası açmadan, anlamlı bir iş yapıyor mu? İlk sürümde hangi özelliklerin şart olduğunu mobil uygulama MVP yazımızda daha ayrıntılı ele alırız.

Bazı projelerde yalnızca bir web sayfasını saran yaklaşım yeterli gelmez; gerçek bir native ya da hibrit uygulama daha uygun durur. Hangisinin ne zaman daha uygun olduğunu PWA ile mobil uygulama karşılaştırma yazımızda karşılaştırırız. Her iki seçenek de doğru bağlamda işe yarar. Önemli olan, mağazanın beklediği bağımsız değeri sunmaktır.

Örneğin bir restoran zinciri, yalnızca menüyü ve adresi gösteren bir uygulama göndermek yerine masa rezervasyonu, sipariş takibi veya sadakat puanı gibi gerçek bir fayda ekler. Bu fayda, mağazanın aradığı "bağımsız değer" tanımına tam olarak karşılık gelir. Ekibimiz yeni bir proje tasarlarken önce bu soruyu sorar: kullanıcı bu uygulamayı neden tarayıcı yerine tercih eder?

Test Hesabı ve Demo Erişimi Sağlamazsanız Ne Olur?

Giriş gerektiren bir uygulamada çalışan bir test hesabı veya tam demo erişimi vermezseniz, inceleme ekibi başvurunuzu bu noktada durdurur. Apple bunu açıkça ister. Google Play de giriş gerektiren bölümler için benzer bilgi ister.

Üstelik inceleme sırasında sunucu tarafındaki servis kapalıysa aynı sonuç ortaya çıkar. Ekip canlı veriye bağlanamaz ve uygulamayı test edemez. Bu yüzden inceleme penceresi boyunca test ortamınızı aktif tutarsınız.

Bazı uygulamalar yalnızca belirli bir ülkede veya belirli bir donanımda (akıllı saat, tablet, özel bir sensör) çalışır. Bu durumda inceleme notuna kısa bir açıklama eklersiniz; hangi donanıma veya bölgeye ihtiyaç olduğunu, varsa alternatif bir test yöntemini ayrıntılı yazarsınız. Açık bir not, inceleme ekibinin sizinle tekrar iletişime geçme ihtiyacını azaltır.

1. Gerçek verilerle çalışan bir test kullanıcı adı ve şifre hazırlarsınız.
2. Özel donanım veya konum gerekiyorsa kısa bir not eklersiniz.
3. İnceleme notlarına giriş adımlarını sade bir dille yazarsınız.

Peki bu hazırlığı nasıl test edersiniz? Göndermeden önce kendi test hesabınızla uygulamayı sıfırdan kurarsınız. Giriş yapar ve ana akışı baştan sona bir kez daha yürütürsünüz. Küçük bir eksik bu adımda genellikle hemen ortaya çıkar.

Yetersiz veya Yanıltıcı Meta Veri Uygulama Reddi Nedenleri Listesinde Nerede Durur?

Meta veri, yani başlık, açıklama, kategori ve ekran görüntüleri, listenin üst sıralarında durur. Açıklama uygulamanın gerçekte yaptığından fazlasını vadediyorsa veya kategori seçimi yanlışsa inceleme ekibi bunu fark eder.

Örneğin bir fitness uygulaması tıbbi tedavi vadeden ifadeler kullanırsa, bu hem yanıltıcı durur hem de ayrı bir inceleme riski doğurur. Bu yüzden açıklamayı yazarken uygulamanın yaptığı işi net ve ölçülü bir dille anlatırsınız.

Mağaza görünürlüğünü doğru kurmak da aynı başlığın parçasıdır; başlık, anahtar kelime ve açıklama dengesini uygulama mağazası optimizasyonu (ASO) yazımızda işleriz. Doğru kurduğunuz bir ASO stratejisi red riskini düşürür. Aynı strateji, doğru kullanıcıyı da uygulamanıza yönlendirir.

Benzer bir dikkat, uygulama içindeki satın alınabilir ürün listesi için de geçerlidir. Mağaza formunda beyan ettiğiniz ürün sayısı ve fiyatı, uygulama içinde gördüğünüz ekranla uyuşmalıdır. Küçük bir tutarsızlık bile inceleme ekibinin dikkatini çeker ve ek bir açıklama istemesine yol açar.

Ekran Görüntüleri Gerçek Uygulamayla Uyuşmazsa Ne Olur?

Ekran görüntüleri gerçek arayüzden farklı durabilir, eski bir sürümden kalmış olabilir veya olmayan bir özelliği gösterebilir. Bu durumda inceleme ekibi bunu yanıltıcı meta veri sayar. Güncel ve doğru görsel kullanmak, hem red riskini azaltır hem de kullanıcı şikayetlerini önler.

Bununla birlikte, mağaza sayfanızı her güncellemeden sonra tekrar kontrol edersiniz. Küçük bir arayüz değişikliği bile ekran görüntülerini eskitir ve yeni sürümle uyumsuz hale getirir.

Gizlilik Politikası Eksikliği Neden Ciddi Bir Red Nedeni Olur?

Gizlilik politikası bağlantısı eksikse veya politika uygulamanın topladığı veriyi anlatmıyorsa, her iki mağaza da başvuruyu durdurur. Politika, hangi verinin toplandığını, nasıl kullanıldığını, kimlerle paylaşıldığını ve kullanıcının nasıl silme talep edebileceğini açıkça anlatır.

Ayrıca hesap oluşturma özelliği sunan uygulamalarda kullanıcı hesabını uygulama içinden kendisi siler. Bu konunun kendi kuralları ve istisnaları hesap silme kuralı yazımızda ayrıca yer alır, burada tekrar girmeyiz.

Gizlilik politikasını kullanıcı güvenine dayanan bir iletişim aracı olarak hazırlarsınız, sadece hukuki bir zorunluluk olarak görmezsiniz. Böylece hem mağaza incelemesini hem de kullanıcı beklentisini aynı anda karşılarsınız.

Politikanızı her büyük güncellemeden sonra yeniden okursunuz; yeni bir izin veya yeni bir ölçüm aracı eklediğinizde, bu değişikliği politika metnine de yansıtırsınız. Eski bir politika, inceleme ekibine uygulamanın gerçek davranışını yanlış anlatır ve ayrı bir tutarsızlık sorununa dönüşür.

İzin Açıklaması Yetersizse Hangi Sorun Çıkar?

Kamera, konum, bildirim veya kişi listesi gibi hassas bir izin istediğinizde bunu kullanıcıya açık biçimde anlatırsınız. Bu izni neden istediğinizi gösteren kısa bir metne (purpose string) ihtiyacınız olur. Açıklama boşsa, genel bir kalıp cümleyse veya gerçek amacı yansıtmıyorsa inceleme ekibi bunu eksik sayar.

Peki bu açıklamayı nasıl doğru kurarsınız? Kullanıcının o anda yaşadığı ihtiyacı birebir anlatırsınız. "Yakınınızdaki randevu noktalarını gösterebilmek için konumunuzu kullanırız" gibi somut bir cümle kurarsınız. Bu cümle, genel bir "uygulama düzgün çalışsın diye" ifadesinden çok daha ikna edici durur.

Bildirim izni özelinde doğru zamanlama da aynı güven ilişkisinin parçasıdır. İzni ne zaman istemeniz gerektiğini push bildirim izni yazımızda ele alırız. Doğru zamanda sorulan bir izin isteği, kullanıcıdan hem olumlu yanıt alır hem de inceleme ekibine amacınızı net anlatır.

Konum izninde de benzer bir mantık geçerlidir: uygulamanızı açar açmaz sürekli konum izni istemek yerine, kullanıcı o özelliğe gerçekten ihtiyaç duyduğu anda sorarsınız. Bu sıralama, hem kabul oranını yükseltir hem de inceleme ekibine isteğin amacını daha anlaşılır kılar.

Gereksiz İzin İstemek Red Riskini Nasıl Büyütür?

Uygulamanızın temel işlevi için gerekli olmayan bir izni istemek, hem red riskini hem de kullanıcı güvensizliğini büyütür. Bir not alma uygulamasının kişi listesine veya mikrofona erişim istemesi, kullanıcıya ve inceleme ekibine mantıksız gelir.

Bunun yerine her izin isteğini tek bir soruyla test edersiniz: bu izin olmadan bu ekran gerçekten çalışmaz mı? Cevap hayırsa, o izni kaldırırsınız veya isteğe bağlı bir seçenek haline getirirsiniz. Böylece hem kullanıcı güveni hem de inceleme sonucu olumlu etkilenir.

Ekibimiz yeni bir özellik eklerken izin listesini küçük bir tablo halinde tutar: izin adı, hangi ekranda kullanıldığı ve kaldırıldığında ne kaybedileceği. Bu basit tablo, hem geliştirme sırasında hem de mağaza incelemesi öncesinde gereksiz bir izni fark etmenizi kolaylaştırır.

Tasarım Yönergelerine Uymamak Hangi Sorunları Doğurur?

Tasarım yönergeleri, platformun kendi arayüz dilini (düğme, menü, geçiş animasyonu) bozan uygulamaları hedefler. Sistem bileşenlerini taklit eden sahte uyarı pencereleri veya kullanıcıyı yanıltan sahte düğmeler bu kategoriye girer.

Böylece tasarım yönergesi, sadece estetik bir tercih değil, kullanıcının platforma güvenini koruyan bir güvenlik katmanı olarak çalışır. Siz de arayüzü kurarken platformun kendi bileşenlerinden uzaklaşmazsınız. Ekibimiz yeni bir proje planlarken bu uyumu en baştan tasarım aşamasına koyar.

Örneğin sistem bildirimine benzeyen sahte bir pencereyle kullanıcıyı başka bir ekrana yönlendirebilirsiniz. Bu yöntem kısa vadede tıklama kazandırsa da uzun vadede hem kullanıcı güvenini hem de mağaza onayını kaybettirir.

Benzer bir örnek, gerçek bir kapatma düğmesi olmayan reklam pencereleridir. Kullanıcı reklamdan çıkamadığında hem şikayet oranı yükselir hem de inceleme ekibi bu davranışı kullanılabilirlik ihlali sayar. Siz de her reklam ve pop-up pencereye görünür bir kapatma yolu eklersiniz.

Özgün Olmayan ve Kopya Uygulamalara Mağaza Nasıl Tepki Verir?

Başka bir uygulamanın arayüzünü, isim stilini veya simgesini birebir taklit eden başvurular özgünlük kuralına aykırı durur. Mağazalar, kullanıcının hangi uygulamayı indirdiğini net biçimde ayırt etmesini ister.

Bu yüzden marka kimliğinizi (isim, simge, renk) erken aşamada netleştirmeniz, ileride bir benzerlik itirazıyla karşılaşma riskini düşürür. Ekibimiz yeni bir uygulama tasarlarken önce rakip mağaza sayfalarını tarar. Böylece isim ve simge çakışmasını geliştirme başlamadan fark eder.

Bu kontrol sadece isim ve simgeyle sınırlı kalmaz; açıklama metninizin bir başka markanın sloganını veya özel bir ifadesini birebir tekrar etmediğinden de emin olursunuz. Küçük bir benzerlik bile kullanıcıda yanlış bir çağrışım yaratabilir ve mağazanın özgünlük denetiminden geçmenizi zorlaştırabilir.

Şablon ve Spam İçerikli Başvurular İçin Ne Olur?

Aynı kalıptan çıkmış, sadece içeriği değişen çok sayıda benzer uygulamayı art arda göndermek spam sınıfına girer. İnceleme ekibi bunu hızla geri gönderir. Bu konunun somut kuralını ve kaçınma yollarını tekrar yazmak yerine App Store şablon ve spam reddi başlıklı yazımıza yönlendiririz. Orada tek bir maddeyi derinlemesine işleriz, burada ise bu yazının genel haritasındaki yerini gösteririz.

Hesap Silme Seçeneği Eksikse Apple Ne Yapar?

Kullanıcıya hesap oluşturma imkânı sunan ama hesabı uygulama içinden silme yolu vermeyen başvuruları Apple geri gönderir. Bu, uygulama reddi nedenleri haritasında tek bir satır olsa da, kendi başına geniş bir konudur.

Kuralın kapsamını, istisnalarını ve doğru uygulama şeklini Apple'ın zorunlu hesap silme kuralı yazımızda ayrıntılı işleriz. O yazı tek bir kuralı, şimdiki yazı ise tüm red haritasını kapsar.

İçerik ve Fikri Mülkiyet İhlalleri Hangi Durumlarda Red Getirir?

Başkasının logosunu, müziğini veya metnini izinsiz kullanan içerikler fikri mülkiyet ihlali oluşturur. İnceleme ekibi bunu şikayet üzerine ya da doğrudan inceleme sırasında fark eder ve başvuruyu geri çevirir. Aynı şekilde yasalara aykırı, nefret söylemi içeren veya şiddeti özendiren içeriği de mağaza kabul etmez.

Bu nedenle kullandığınız her görsel, ses ve metin için lisans ya da kullanım hakkınızın belgeli olması gerekir. Belgelenemeyen içeriği yayına almazsınız. Ücretsiz bir stok görseli kullanırken de lisans koşulunu dikkatlice okursunuz; bazı lisanslar ticari kullanımı kısıtlar ve bu ayrıntıyı gözden kaçırmak ileride ayrı ve beklenmedik bir hukuki sorun açar, hatta yayından kaldırma talebine kadar uzayabilir.

Ekibimiz bir proje teslim ederken kullanılan her dış kaynağın lisans belgesini ayrı bir klasörde saklar. Bu alışkanlık, yıllar sonra bir itiraz geldiğinde kaynağı hızlıca göstermenizi sağlar; aksi halde kanıt sunamadığınız bir iddia karşısında savunmasız kalırsınız.

Google Play'de İçerik Derecelendirmesi Atlanırsa Ne Olur?

Google Play, her uygulamadan bir içerik derecelendirme anketi doldurmasını ister. Bu anket eksikse veya yanlış doldurulmuşsa Google uygulamayı mağazadan kaldırır. Doğru yaş aralığı, hem yasal uyumu hem de doğru kitleye ulaşmayı sağlar.

Dolayısıyla uygulamanızın içeriği değiştiğinde, örneğin kullanıcı üretimi içerik eklediğinizde, derecelendirme anketini de güncellersiniz. Eski bir anket yeni içerikle uyuşmadığı anda Google bunu fark eder.

Çocuklara Yönelik Uygulamalarda Hangi Ek Kurallar Geçerli?

Çocuk kategorisinde bir uygulama yayınladığınızda Apple ve Google ek bir gizlilik ve içerik denetimi uygular. Hedefli reklam, üçüncü taraf izleme araçları ve gereksiz veri toplama konusunda kural çok daha katı bir çerçeve çizer.

Bu yüzden çocuk kategorisinde yayın yapmayı planlıyorsanız, davranışsal reklam yerine yaşa uygun ve veri toplamayan bir reklam modeli seçersiniz. Aksi halde mağaza başvurunuzu yayın öncesinde durdurur. Güncel yaş sınırı ve izin kuralını her zaman resmi geliştirici sayfasından kontrol edersiniz.

Ekibimiz çocuk kategorisinde bir proje planladığında önce reklam ortağının çocuk politikasına uygun bir seçenek sunup sunmadığını kontrol eder. Uygun bir seçenek yoksa, reklamsız bir gelir modeli veya yaşa uygun bir abonelik önerir; bu yaklaşım, yayın sonrası bir sürpriz redle karşılaşma riskini büyük ölçüde azaltır.

Yanıltıcı Reklam Beyanı Neden Risk Taşır?

Uygulamanızda reklam gösterdiğiniz halde mağaza formunda "reklam içermiyor" beyanı vermek ayrı bir politika ihlali oluşturur ve askıya alma riski taşır. Bu beyan, kullanıcının karşılaşacağı deneyimle birebir uyuşmalıdır.

Benzer bir dikkat, uygulama içi satın alma ile web üzerinden ödeme arasındaki komisyon farkını yanlış anlatan açıklamalar için de geçerlidir. Bu konuyu uygulama içi satın alma ve web ödeme karşılaştırma yazımızda ayrıca işleriz. Komisyon oranları zamanla değişir; güncel oranı her zaman resmi geliştirici sayfasından kontrol edersiniz.

Dijital İçerik İçin Doğru Ödeme Yöntemini Kullanmazsanız Ne Olur?

Uygulama içinde dijital içerik (ek özellik, sanal ürün, premium içerik) satarken Apple ve Google kendi onayladıkları ödeme altyapısını ister. Bu kuralı atlayıp yalnızca dış bir ödeme bağlantısı koymak ayrı bir iş modeli ihlali oluşturur. Mağaza bu durumda başvurunuzu geri çevirir.

Bu kuralın komisyon oranları ve istisnaları zamanla değişir. Güncel kuralı her zaman resmi geliştirici sayfasından kontrol edersiniz, burada kesin bir yüzde vermeyiz. Doğru ödeme yöntemini seçmenin ticari etkisini ödeme yöntemi karşılaştırmamızda ayrıca ele alırız. Burada yalnızca bu seçimi atlamanın red riski taşıdığını vurgularız.

Kullanıcı Yorumu ve Puan Manipülasyonu Neden Risk Taşır?

Kullanıcılara yorum veya beş yıldız karşılığında hediye, kredi ya da ayrıcalık teklif etmek puan manipülasyonu oluşturur. Mağaza bu davranışı ciddi bir ihlal olarak değerlendirir. Gerçek kullanıcı geri bildirimiyle teşvikli yorum arasındaki fark, inceleme ekibi için önemli bir sinyaldir.

Ekibimiz müşterilerinden yorum istediğinde her zaman nötr bir dil kullanır. Karşılığında maddi bir teşvik sunmaz. Bu yaklaşım hem güveni korur hem de hesabınızın askıya alınma riskini düşürür.

Reddedilen Bir Uygulama İçin İtiraz Süreci Nasıl İşler?

Red mesajı genellikle hangi başlığa aykırı davrandığınızı belirtir; ilk adımınız bu mesajı dikkatlice okumak ve işaret edilen sorunu düzeltmektir. Apple'da inceleme ekibiyle yazılı iletişim kurabilirsiniz. Google Play'de ise politika ihlali bildirimine itiraz formu üzerinden yanıt verirsiniz.

Ancak itiraz etmek kesin kabul garantisi vermez. Sorunu gerçekten düzeltmeden sadece aynı açıklamayla tekrar göndermek genelde ikinci bir red getirir. Google Play'de kaldırılan bir uygulama için hangi adımları atacağınızı politika ihlali ve itiraz yazımızda ayrıntılı anlatırız.

Son olarak, itiraz sürecinde sakin bir dille ilerlemek işe yarar. Ekran kaydı, yeni politika metni veya düzelttiğiniz kod gibi somut kanıtlar sunarsınız. Bu yaklaşım kararı daha hızlı ve olumlu sonuca taşır. Duygusal bir itiraz metni genellikle sonucu değiştirmez.

En Sık Tekrar Eden Uygulama Reddi Nedenleri Hangileri?

Saha tecrübemize göre dört başlık diğerlerinden daha sık tekrar eder. Bunlar teknik çökme, eksik gizlilik politikası, zayıf izin açıklaması ve gerçeği yansıtmayan meta veridir. Bu dört başlığı teslimden önce kontrol etmek, ilk incelemede red alma riskini belirgin şekilde azaltır.

Peki bu dört başlığı nasıl bir sırayla kontrol edersiniz? Önce teknik testi tamamlarsınız. Ardından gizlilik politikasını ve izin açıklamalarını gözden geçirirsiniz. Son olarak mağaza sayfasındaki her görseli ve metni güncel sürümle karşılaştırırsınız.

Güncel Bilgiyi Hangi Resmi Kaynaklardan Takip Edersiniz?

Bu yazıdaki kategoriler genel çerçeveyi gösterir, ama her kategorinin ayrıntısı zamanla değişir. Apple'ın güncel metnini App Store İnceleme Yönergeleri sayfasından okursunuz. Google'ın güncel metnini ise Geliştirici Programı Politikaları sayfasından takip edersiniz.

Siz de her yeni sürüm göndermeden önce bu iki sayfayı kısaca tararsınız. Bu küçük alışkanlık, eski bir kurala göre hazırladığınız bir listeye güvenip yeni bir kuraldan habersiz kalma riskini ortadan kaldırır. Ekibimiz her proje teslimatı öncesi bu taramayı sabit bir adım olarak sürece ekler.

Reddi Önlemek İçin Teslim Öncesi Hangi Kontrolleri Yaparsınız?

Göndermeden önce şu kısa kontrol listesini gözden geçirirsiniz. Her başlığı tek tek, aceleye getirmeden kontrol ettiğinizde aynı hatayı ikinci kez yaşama riskiniz önemli ölçüde düşer.

Uygulamanızın ilk sürümünü planlarken ekibimizin mobil uygulama geliştirme hizmetimizden destek alırsınız. Bu kontrol listesini geliştirme sürecine en baştan yerleştirmek, teslim aşamasında sürpriz yaşama riskini azaltır. Teknoloji seçimini (native ya da cross platform) nasıl yapacağınızı ise native mi cross platform mı yazımızda karşılaştırırız.

• Gerçek cihaz testi ve çökme kontrolü yaparsınız.
• Güncel gizlilik politikası bağlantısı eklersiniz.
• Her hassas izin için somut açıklama metni yazarsınız.
• Gerçek ekran görüntüleri kullanır ve doğru kategoriyi seçersiniz.
• Test hesabınızı aktif tutar, sunucu servisinizi canlı bırakırsınız.

Bu listeyi her sürüm öncesi tekrar gözden geçirmeniz, zamanla ekibinizin doğal bir alışkanlığı haline gelir. Böylece uygulama reddi nedenleri listesi size bir ceza değil, basit bir kontrol aracı gibi görünmeye başlar.

Küçük bir ekip için bile bu kontrolü atlamamak kolaydır: listeyi bir kağıda veya proje panonuza yapıştırırsınız, her teslimde maddeleri tek tek işaretlersiniz. Zamanla bu adım, ayrı bir eforu değil, geliştirme sürecinizin sıradan bir parçasını oluşturur; ekibimiz de her müşteri projesinde aynı mantığı kullanır.