Mobil uygulama yaptırmak — mağazaların geri çevirdiği 8 şey (2026)

Mobil uygulama yaptırma kararı genelde tek bir cümleyle başlar: "Bizim de bir uygulamamız olsun." Sonrasında konuşulan tek şey fiyat ve süre olur. Oysa projeleri geciktiren, bütçeyi şişiren ve bazen tamamen çöpe atan asıl şey ne fiyat ne süredir — mağaza kurallarıdır.

Uygulama yazılır, test edilir, "bitti" denir; ardından App Store ya da Google Play uygulamayı geri çevirir. Ret sebebi çoğu zaman kodla ilgili bile değildir: eksik bir ekran, doldurulmamış bir form, uygulamanın hiç düşünülmemiş bir yeteneği.

Bu yazı, bir tarif değil bir kontrol listesidir. Uygulama yaptıracaksan, geliştiriciye neyi sorman gerektiğini bilmen için yazıldı.

Mağazalar neyi geri çeviriyor?

Aşağıdaki sekiz başlık, uygulamaların ilk retlerini en sık yediği yerlerdir. Her biri kendi başına teknik ve hukuki iş kalemidir; hiçbiri "kodu yazınca gelir" değildir.

1. Uygulama içinden hesap silme

Kullanıcı hesabı açılabilen bir uygulamada, kullanıcının hesabını uygulamanın içinden silebilmesi gerekir. "Hesabı zaten yönetici açıyor" savunması güvenilir bir muafiyet değildir. Bu, tasarım aşamasında planlanmadıysa sonradan eklenmesi en can sıkıcı özelliklerden biridir; çünkü yalnızca bir düğme değil, verinin nasıl silineceğine dair bir karar zinciridir.

2. Web üzerinden hesap silme sayfası

Google Play, uygulamanın dışında — tarayıcıdan erişilebilen — ayrı bir hesap silme sayfası ister. Yani işin bir ayağı web sitene düşer. Sitesi olmayan ya da sitesine dokunulamayan bir işletmede bu tek başına projeyi durdurabilir.

3. Kullanıcılar birbirine içerik gönderiyorsa

Uygulamada mesajlaşma, yorum, fotoğraf paylaşımı gibi kullanıcıdan kullanıcıya giden herhangi bir içerik varsa, Apple dört şeyi birden arar: şikâyet etme, engelleme, moderasyon ve görünür bir iletişim adresi. Dördü de olmadan uygulama yayınlanmaz. "Sadece hoca öğrenciye mesaj atıyor" gibi masum görünen senaryolar da bu kapsamdadır.

4. Yeni Google Play hesabında zorunlu test dönemi

Yeni açılan bireysel geliştirici hesaplarında, üretim başvurusundan önce belirli sayıda testçiyle kesintisiz süren bir kapalı test dönemi tamamlanmalıdır. Bu, kodla ilgisi olmayan ama takvimi doğrudan uzatan bir şarttır.

Bu yüzden Play hesabı projenin ilk günü açılır. Sonunda açılırsa, uygulama hazır olduğu hâlde haftalarca bekler — ve bu bekleme genelde müşteriye sürpriz olarak gelir.

5. Güncel hedef API sürümü (Android)

Google Play, yeni uygulamaların güncel bir Android sürümünü hedeflemesini zorunlu tutar ve bu eşik her yıl yükselir. İlk derlemeden itibaren güncel sürüme göre yazılmayan bir uygulama, yayına hazır olduğu gün "eski" sayılabilir.

6. Gizlilik etiketleri ve veri güvenliği formu

Hangi veriyi topladığın, kiminle paylaştığın ve niçin — her ikisinin de mağaza formunda beyan edilmesi gerekir. Kritik nokta: bu form ile sitendeki gizlilik politikası birbirini tutmak zorundadır. Tutmadığında uygulama geri döner, üstelik bu hata düzeltilmesi en yavaş olanlardandır çünkü hukuki metnin de değişmesi gerekir.

7. Yaş sınıflandırması

Mağazalar, içeriği anlatan bir anket doldurtur. Anket cevapları uygulamanın gerçek içeriğiyle uyuşmazsa uygulama reddedilir. Özellikle oyunlarda, sohbet içeren uygulamalarda ve yapay zekânın içerik ürettiği uygulamalarda kritiktir — üçü de "zararsız" görünüp sınıflandırmayı yukarı çeken durumlardır.

8. Şifreleme beyanı

Uygulaman standart HTTPS kullanıyor olsa bile bir beyan doldurman gerekir. Doğru işaretlenmediğinde her sürümde aynı soru tekrar sorulur ve incelemeyi yavaşlatır.

Bu sekiz başlık 24 Ağustos 2026 itibarıyla geçerlidir. Apple ve Google kurallarını yıl içinde birkaç kez değiştirir; teklif aşamasında güncel hâlini kontrol ettirmek gerekir.

Fiyat teklifinde görmen gereken kalemler

Mobil uygulama tekliflerinin çoğu "tasarım + geliştirme" diye iki satırdan ibarettir. Bu iki satır işin yarısıdır. Sağlıklı bir teklifte şunların da adı geçmelidir:

• Uygulamanın verisini tutan veritabanı ve yetkilendirme
• İçeriği yöneteceğin web yönetim paneli
• Bildirim altyapısı (iOS ve Android ayrı sistemler kullanır)
• Uygulama ikonu, mağaza görselleri ve açıklama metni
• Gizlilik politikası, KVKK metni ve hesap silme akışı
• Mağaza başvurusu ve inceleme yazışması (ret gelirse cevabı kim yazacak?)
• Yayın sonrası bakım — uygulama yayınlandığı gün bitmez

Son madde en çok atlanandır. İşletim sistemleri güncellenir, mağaza kuralları değişir; bakımsız kalan bir uygulama bir-iki yıl içinde sessizce yayından düşebilir. "Uygulamayı yaptırdık, sonra kimse dokunmadı" hikâyesi Türkiye'de fazlasıyla yaygın.

Geliştiriciye sorulacak dört soru

1. 1Mağaza hesabı kimin adına açılacak? Doğru cevap: seninkine. Uygulama senin kimliğinle yayınlanmalı, hesabın sahibi sen olmalısın; geliştirici yalnızca erişim almalı. Aksi hâlde ayrılık anında uygulaman rehin kalır.
2. 2Kaynak kod bana ait mi, devir nasıl oluyor? Kod, veritabanı ve mağaza hesabı proje sonunda sende olmalı. Buna "evet" diyemeyen bir tedarikçi seni teknik olarak kilitliyor demektir.
3. 3Aylık altyapı maliyeti ne? Neredeyse her uygulamanın bir sunucu/veritabanı maliyeti vardır. Küçük uygulamalarda bu rakam çok düşüktür — ama teklifte yazılı olmalı, sonradan öğrenilmemeli.
4. 4iOS mu Android mi, neden? Bütçe sınırlıysa tek platformla başlayıp gerçek kullanıcıyla test etmek genelde daha akıllıcadır. "İkisini de yaparız" cevabı iyi bir cevap değil; niçin ikisi sorusunun cevabı iyi bir cevaptır.

Oyun yaptıracaksan durum biraz farklı

Oyunda kuralların üstüne bir de şu gelir: oyunun tutup tutmayacağı grafikte değil mekanikte belli olur. Kontrolün elde nasıl hissettirdiği, zorluk eğrisi, ses ve titreşim geri bildirimi — bunlar görselden önce çözülmesi gereken şeylerdir.

Pratik sonuç: oyun projesinde tasarıma bütçe ayırmadan önce oynanabilir bir prototip istemelisin. Prototipte eğlenmiyorsan, cilalanmış hâlinde de eğlenmezsin. Ayrıca oyunlarda yaş sınıflandırması ve reklam/satın alma modeli, yayın tarihini doğrudan etkileyen kararlardır; sona bırakılmamalıdır.

Bu işi Labyra yapıyor

Yukarıdaki sekiz başlığın hepsi teknik ve hukuki iş kalemidir; biz uçtan uca üstleniyoruz. Akış şöyle işliyor:

Kapsamı netleştiriyoruz → ekran akışını ve tıklanabilir tasarımı onaylatıyoruz → iki haftalık turlarla geliştiriyoruz (her turun sonunda telefonuna kurulabilen bir sürüm) → gerçek cihazlarda test ediyoruz → mağaza başvurusunu biz yapıyoruz (ikon, görseller, metin, gizlilik etiketleri, sınıflandırma, inceleme yazışması dahil) → yayından sonra bakımı sürdürüyoruz.

Bunu anlatmak yerine göstermeyi tercih ediyoruz: kendi uygulamamız Labyra Randevu, 21 Ağustos 2026'dan beri App Store'da yayında — iPhone ve Apple Watch için, anlık bildirimleriyle birlikte. Apple'ın inceleme sürecinden geçmiş, herkesin bakabileceği bir mağaza kaydı. Mobil uygulama geliştirdiğimizin kanıtı bir slayt değil, indirilebilir bir uygulama.

Kapsam: işletmeye özel iOS ve Android uygulamaları (ajanda/rezervasyon, saha ve operasyon, sadakat, personel, B2B sipariş, mevcut sisteminin mobil hâli) ve 2B/casual oyunlar. Büyük ölçekli 3B yapımları kapsamımızın dışında tuttuğumuzu baştan söylüyoruz.

Dürüst çerçeve

Mobil uygulama her işletmenin ihtiyacı değildir. Müşterinin yılda iki kez açacağı bir şey için uygulama yaptırmak, hem bütçe hem bakım açısından kötü bir karardır — o iş çoğu zaman iyi bir mobil web sayfasıyla çözülür. Nitekim kendi randevu sistemimizde müşteri tarafında uygulama yoktur: randevu tarayıcıdan alınır, uygulama yalnızca işletme sahibi içindir.

Fikri dinlediğimizde uygulamaya değmediğini düşünürsek bunu da söylüyoruz. Satmadığımız bir işin bakımını sürdürmek zorunda kalmak kimsenin işine yaramıyor.

Sık sorulan sorular

Mobil uygulama ne kadar sürede yayınlanır?

Sınırlı kapsamlı bir iş uygulamasında tipik aralık 5-8 haftadır; buna tasarım, geliştirme, gerçek cihazda test ve mağaza incelemesi dahildir. Android tarafında yeni bir geliştirici hesabı açılacaksa Google'ın zorunlu kapalı test dönemi takvime eklenir. Net süre, kapsam kesinleştikten sonra yazılır.

Mobil uygulama fiyatı nasıl belirleniyor?

Hazır paket yoktur: ekran sayısı, platform (iOS / Android / ikisi), bildirim ve yönetim paneli ihtiyacı bütçeyi belirler. Kapsam netleştikten sonra sabit fiyatlı bir teklif veriyoruz. Mağaza hesabı ücretleri (Apple yıllık, Google tek seferlik) doğrudan işletmeye aittir ve teklifte ayrıca gösterilir.

Mağaza hesabı kimin adına açılır?

İşletmenin adına. Uygulama sizin kimliğinizle yayınlanır ve hesabın sahibi sizsiniz; geliştirici olarak biz yalnızca erişim alırız. Böylece uygulama hiçbir zaman tedarikçiye bağlı kalmaz.

Uygulamanın kaynak kodu bana ait mi?

Evet. Proje bittiğinde kaynak kod, veritabanı ve mağaza hesabı işletmede olur; devir dosyasıyla birlikte teslim edilir. Bakımı biz sürdürebiliriz, istenmezse başka bir ekip kaldığı yerden devam edebilir.

Önce iOS mu Android mi yapılmalı?

Bütçe sınırlıysa tek platformla başlayıp gerçek kullanıcıyla test etmek genelde daha doğrudur; müşterilerinizin çoğu hangi telefondaysa oradan başlanır. Tek kod tabanı tercih edilirse ikisi birlikte çıkar. Biz de kendi uygulamamızda iOS ile başladık.

Oyun da geliştiriyor musunuz?

Evet — casual, ritim, bulmaca ve skor odaklı 2B oyunlar. Görsele geçmeden önce oynanabilir bir prototip çıkarıyoruz, çünkü oyunda işin özü mekaniktir. Büyük ölçekli 3B (AAA) yapımlar kapsamımızın dışındadır.

Mevcut sistemim uygulamaya bağlanır mı?

Bağlanır. API'si olan sistemlerle (randevu, ERP, e-ticaret, ön muhasebe, stok) konuşan uygulamalar yazıyoruz. Sistemin API'si yoksa gereken servisi biz yazıyoruz; bu durumda kapsam ve süre teklifte ayrı kalem olarak gösterilir.