Mobil uygulama projelerinin çoğu kod yüzünden değil, karar yüzünden gecikir. Hangi platform, hangi özellikler, hangi sırayla — bu sorular baştan cevaplanmadığında geliştirme süreci sürekli yeniden başlar.

Bir de yaygın bir yanılgı var: uygulamanın yayına çıkmasının bitiş çizgisi olduğu sanılıyor. Oysa yayın, işin ortası. Mağaza kuralları her yıl değişiyor ve güncellenmeyen uygulama sessizce görünmez hâle geliyor.

Heliosfer olarak yürüttüğümüz yazılım ve uygulama projelerinde kullandığımız çerçeveyi bu rehberde anlatıyoruz.

Öne Çıkanlar

• Native ve cross-platform tercihi teknik değil, ticari bir karardır; bütçe ve ürün hedefine göre belirlenir.

• Sağlıklı bir süreç sekiz aşamadan oluşur ve bunun yarısı kod yazılmadan önce tamamlanır.

• Google Play'de yeni uygulamalar ve güncellemeler 31 Ağustos 2026'dan itibaren Android 16 (API 36) hedeflemek zorunda.

• Yayın sonrası bakım bütçesi ayrılmayan uygulamalar bir-iki yıl içinde güncellenemez hâle geliyor.

Native mi, Cross-Platform mı?

Projenin ilk ve en belirleyici kararı bu. Yanlış seçim, ilerleyen aylarda yeniden yazma maliyeti olarak geri döner.

Pratik kural: uygulamanız donanımı yoğun kullanmıyorsa cross-platform çoğu zaman doğru tercih. Kamera işleme, artırılmış gerçeklik ya da ağır animasyon varsa native tarafa geçmek gerekir.

Bir de üçüncü seçenek var ve çoğu marka için doğru cevap odur: uygulamaya hiç gerek olmayabilir. Kullanıcı ayda bir kez giriyorsa, mobil uyumlu bir web sitesi ya da PWA hem daha ucuz hem daha hızlı sonuç verir. Uygulama, tekrar eden kullanımı olan işler için mantıklıdır.

Süreç Adım Adım

Sağlıklı bir uygulama projesi sekiz aşamada ilerler:

1. Keşif ve kapsam. Problem, kullanıcı ve iş hedefi netleştirilir. Özellik listesi burada değil, sonra çıkar.

2. Kullanıcı akışları. Ekranlar değil, yollar tasarlanır. Kullanıcı hedefe kaç adımda ulaşıyor?

3. Wireframe. Görsel tasarım yok, yalnızca yerleşim ve hiyerarşi.

4. UI tasarımı. Renk, tipografi, bileşen kütüphanesi. Marka kimliğiyle uyum burada kurulur.

5. Prototip ve test. Tıklanabilir prototiple gerçek kullanıcı üzerinde deneme. En ucuz hata düzeltme aşaması budur.

6. Geliştirme. Sprint bazlı ilerleyen kodlama ve entegrasyonlar.

7. Test ve QA. Farklı cihaz, ekran boyutu ve işletim sistemi sürümlerinde doğrulama.

8. Yayın ve bakım. Mağaza süreçleri, izleme, güncellemeler.

Dikkat edilmesi gereken nokta: ilk beş adım kod yazılmadan tamamlanır. Bu aşamaları hızlandırmak ucuz görünür, ama geliştirme sırasında yapılan her tasarım değişikliği tasarım aşamasındakinin kat kat üstünde maliyet çıkarır.

Sahadan bir not: Devraldığımız duran projelerde en sık gördüğümüz sebep, kapsamın yazılı olmaması. Özellikler sözlü konuşuluyor, herkes farklı bir şey anlıyor, geliştirme ortasında iş yeniden tanımlanıyor. Kapsam dokümanı hazırlamak birkaç gün sürüyor; kapsamsız yürüyen bir proje aylar kaybettiriyor. Heliosfer Media Agency olarak yazılım projelerine her zaman yazılı kapsamla başlıyoruz.

MVP: Az Özellikle Başlamak

Uygulama projelerinin klasik hatası, ilk sürüme her şeyi sığdırmaya çalışmak. Oysa amaç eksiksiz ürün çıkarmak değil, doğru varsayımı test etmek.

MVP mantığı üç soruyla kurulur:

• Kullanıcının bu uygulamayı açmasının tek sebebi ne?

• O sebebi karşılamak için gereken minimum ekran seti hangisi?

• Geri kalan her şey ikinci sürümü bekleyebilir mi?

Pratikte ilk sürüm genelde 8–12 ekranla çıkabilir. Otuz ekranla planlanan projelerin çoğu ise hiç yayına ulaşamıyor. Kullanıcı davranışını gördükten sonra özellik eklemek, tahminle özellik yazmaktan hem ucuz hem isabetli.

Maliyeti Ne Belirler?

Uygulama maliyeti "kaç ekran" sorusuyla ölçülmez. Asıl belirleyiciler şunlar:

• Kullanıcı hesabı ve yetkilendirme. Üyelik, rol yönetimi, sosyal giriş.

• Backend ihtiyacı. Veri nerede duracak, kim yönetecek?

• Üçüncü taraf entegrasyonlar. Ödeme, harita, bildirim, CRM, ERP.

• Yönetim paneli. Çoğu projede unutulan ama şart olan katman.

• Ödeme altyapısı. Uygulama içi satın alma varsa mağaza komisyonları da işin içine girer.

• Tasarım özgünlüğü. Hazır bileşen kütüphanesi mi, markaya özel arayüz mü?

Bu kalemlerden hangilerine ihtiyacınız olduğunu baştan netleştirmek, alacağınız tekliflerin karşılaştırılabilir olmasını sağlar. Kapsamı belirsiz bir talebe gelen fiyatlar arasında birkaç kat fark çıkması normaldir — çünkü herkes farklı bir iş fiyatlıyordur.

Mağaza Kuralları: 2026'da Ne Değişti?

Bu bölüm, uygulaması olan her markayı doğrudan ilgilendiriyor.

Google Play target API kuralı. 31 Ağustos 2026 itibarıyla yeni uygulamalar ve güncellemeler Android 16 (API seviyesi 36) hedeflemek zorunda. Bu tarihten sonra daha düşük seviyeyi hedefleyen yüklemeler Play Console tarafından reddediliyor. İhtiyaç halinde 1 Kasım 2026'ya kadar uzatma talep edilebiliyor, ancak otomatik verilmiyor.

Kritik ayrıntı şu: kural yüklemeleri değil güncellemeleri engelliyor. Uygulamanız yayında kalır ama güncelleme gönderemezsiniz. Yani bir güvenlik açığı çıktığında yama yollayacak yolunuz olmaz. Güncellenmeyen uygulamaların ayrıca yeni kullanıcılara görünürlüğü de düşüyor.

Geliştirici doğrulaması. Google, yayınlanan uygulamaların arkasındaki geliştirici kimliğinin doğrulanmasını zorunlu hâle getirdi.

Apple tarafında DSA tüccar doğrulaması. Avrupa Birliği'nde yayın yapan uygulamalarda doğrulanmış tüccar statüsü olmayan uygulamalar mağazadan kaldırılıyor.

Bu üç başlık, "uygulamayı yaptırdık, bitti" yaklaşımının neden işlemediğini özetliyor.

Yayın Sonrası: Asıl İş Burada

Uygulama canlıya alındığında bakım bütçesi devreye girer. Yıllık olarak hesaplanması gereken kalemler:

• İşletim sistemi sürüm güncellemeleri ve API uyumu

• Mağaza politika değişikliklerine uyum

• Sunucu, sertifika ve geliştirici hesabı yenilemeleri

• Hata takibi ve performans izleme

• Kullanıcı geri bildirimine göre iyileştirmeler

Sektörde yaygın kabul, yıllık bakım için geliştirme bütçesinin bir bölümünü ayırmaktır. Bu kalemi planlamayan projelerde uygulama iki yıl içinde güncellenemez hâle geliyor ve baştan yazılması gerekiyor.

Uygulama mağazası sayfası da ihmal edilmemeli: ikon, ekran görüntüleri ve açıklama metni, indirme oranını doğrudan etkiliyor. Bu sayfa aslında bir açılış sayfası — web tasarımında dönüşüm için geçerli olan kurallar burada da işliyor.

En Sık Yapılan Hatalar

• Kapsamı yazıya dökmemek. Sözlü mutabakat, projenin ortasında anlaşmazlığa dönüşür.

• Tasarımı atlayıp kodla başlamak. En pahalı düzeltmeler geliştirme aşamasında yapılır.

• Her şeyi ilk sürüme sıkıştırmak. Yayına hiç çıkamayan projelerin ana sebebi.

• Yönetim panelini unutmak. İçeriği kim, nasıl güncelleyecek?

• Marka dilinden kopuk arayüz. Uygulama da bir marka temas noktası; kurumsal kimlikle uyumlu olmalı.

• Bakım bütçesi ayırmamak. Uygulamanın sessizce ölmesinin en yaygın sebebi.

Sık Sorulan Sorular

Mobil uygulama geliştirme ne kadar sürer? Orta ölçekli bir MVP için tasarım dahil ortalama 3–5 ay. Backend ve entegrasyon ihtiyacı arttıkça süre uzar. Yayın onay süreçleri buna ek birkaç gün ekler.

Önce iOS mu, önce Android mi? Hedef kitleye bağlı. Türkiye'de kullanıcı hacmi Android tarafında daha yüksek; gelir odaklı uygulamalarda ise iOS kullanıcısının ortalama harcaması genellikle daha yüksek. Cross-platform seçildiğinde bu soru büyük ölçüde ortadan kalkar.

Uygulama mı, mobil uyumlu site mi? Kullanım sıklığı belirleyici. Haftada birden az açılan bir hizmet için uygulama yatırımı çoğu zaman geri dönmez.

Kaynak kodu kimin olacak? Sözleşmede net yazmalı. Kaynak kodun ve mağaza hesaplarının markaya ait olması, ajans değişikliğinde yaşanabilecek en büyük riski baştan ortadan kaldırır.

Sonuç

Mobil uygulama, tek seferlik bir üretim değil; sürdürülmesi gereken bir ürün. Doğru başlangıç ise şu üçünde: yazılı kapsam, dar tutulmuş ilk sürüm ve ayrılmış bakım bütçesi. Bunlar hazırsa geliştirme aşaması sürecin en öngörülebilir kısmına dönüşür.

Heliosfer, İstanbul merkezli (Londra ofisiyle birlikte) bağımsız bir kreatif ve dijital ajanstır. 12 yılı aşkın deneyimimizle mobil uygulama tasarımı ve geliştirme, web ve e-ticaret yazılımları, arayüz tasarımı, kurumsal kimlik ve dijital pazarlama hizmetleri sunuyoruz.

Uygulama fikrinizi kapsam ve bütçe düzeyinde netleştirmek isterseniz bize ulaşın — Heliosfer Media Agency ekibiyle önce neyi yapmayacağınıza birlikte karar verelim.