MOBİL UYGULAMA NASIL YAPILIR?

"Bir mobil uygulama yapalım" cümlesinin arkasında çoğu zaman tek bir hayal vardır: parlak bir ikon, açılır açılmaz iş yapan ekranlar, mağazada dökülen yorumlar. Oysa bu ikona kadar gelen yol, kod yazmaktan çok karar vermekle ilgili. Fikrin gerçekten birinin işine yarayıp yaramadığına; hangi üç ekranın olmazsa başlamayacağına; ilk sürümde nelerin çıkarılacağına karar vermek.

Bu yazıda mobil uygulama yapımının uçtan uca aşamalarını sırayla ele alıyoruz. Platform tercihi (iOS, Android, cross-platform) ayrı bir tartışma; burada o seçimden bağımsız olarak her mobil uygulama projesinin geçtiği süreç akışına bakıyoruz: fikir doğrulamadan mağaza yayınına, oradan bakım dönemine kadar.

Nereden Başlanır?

Mobil uygulama yapımının ilk adımı kod yazmak değil, soruyu doğru kurmaktır. "Ne yapacağım?" sorusundan önce "Kim için yapıyorum?" ve "Bu kişi şu an bu işi nasıl yapıyor?" sorularına net cevaplar gerek. Hedef kullanıcının mevcut alışkanlığı belli olmadan tasarım kararları havada kalır.

Başlangıçta yazıya dökülmesi gereken üç şey vardır: problem cümlesi (tek satır), hedef kullanıcı profili (yaş, meslek, kullanım bağlamı) ve başarı kriteri (uygulamayı kullanan kişide ölçeceğiniz tek davranış). Bu üç maddeyi yarım sayfaya sığdıramayan bir fikir, sonraki aşamada hep dağılır. Tipik örnek: "Restoranlar için bir uygulama" cümlesi yetmez; "Mahalle restoranlarının akşam servisinde stok eksilmesini bildiren bir uygulama" yeter — kullanıcı, problem ve bağlam tek cümlede.

Fikir Nasıl Doğrulanır?

Çoğu uygulama doğrulama aşamasını atladığı için harcanan üç-dört ayın sonunda kimse indirmediği bir ürün ortaya çıkar. Doğrulama, kod yazmadan önce yapılan ve hızlıca cevap üreten bir keşif çalışmasıdır.

Pratik doğrulama yöntemleri:

• 5-10 kullanıcı görüşmesi: Hedef kitleden temsilcilerle yapılan 20-30 dakikalık konuşmalar. Sorular geleceğe değil, geçmişe yönelik olmalı: "Bunu son ne zaman yaşadın? Ne yaptın? Sonuç ne oldu?"
• Landing page testi: Tek sayfalık tanıtım sayfası, e-posta bırakma formu, küçük bir reklam bütçesi. Tıklama ve dönüşüm oranı talebi gösterir.
• Manuel prototip: Uygulamanın yapacağı işi insan olarak elle yapın. WhatsApp grupları, Google Forms, basit bir excel — kullanıcının ihtiyacı gerçekten varsa bu manuel akış bile değer üretir.
• Rakip analizi: Aynı veya benzer ihtiyacı çözen 3-5 uygulamanın mağaza yorumlarını okumak. Olumsuz yorumlar boşlukları, olumlu yorumlar ipuçlarını verir.

Doğrulama aşamasının çıktısı tek bir karardır: ilerle, döndür ya da bırak. Bu kararı 2-3 hafta içinde verememek projeyi baştan zarara sokar.

Wireframe ve Tasarım Aşaması

Fikir doğrulandıktan sonra ekranların kağıt üzerinde belirmesi gerekir. Bu aşama üç katmanda ilerler ve her katman kendinden öncekine göre daha somuttur.

1. Wireframe (tel kafes): Renksiz, görselsiz, sadece kutular ve etiketler. Hangi ekranda hangi içerik yer alacak, kullanıcı bir ekrandan diğerine nasıl geçecek — bu seviyede karar verilir. Figma, Balsamiq veya bir kağıt-kalem yeterli.
2. Mockup (yüksek sadakat görsel): Marka renkleri, tipografi, gerçek metin örnekleri. Burada uygulamanın "hissi" oluşur. Tasarımcı yoksa bu aşama dış destek alınacak ilk aşamadır.
3. İnteraktif prototip: Mockup'lar Figma veya benzeri bir araçta birbirine bağlanır; tıklanabilir bir akış elde edilir. Kullanıcı bu prototipi telefondan tutar ve gerçek bir akış üzerinden geri bildirim verir.

Tasarım aşamasında en sık yapılan hata her ekrana "fazladan bir özellik" eklemektir. Bir ekranda üçten fazla ana eylem varsa kullanıcı orada karar veremez. Mobil ekran küçük; karar yorgunluğu hızla gelir. iOS'a özel bir uygulama düşünüyorsanız iOS Swift eğitim sayfası üzerinden Apple'ın insan arayüz rehberine uyumlu tasarım kararlarını sıralı şekilde takip edebilirsiniz. Resmi yönergeler için Apple Human Interface Guidelines başvuru kaynağıdır.

MVP Nedir ve Nasıl Belirlenir?

MVP (Minimum Viable Product), uygulamanın ilk gerçek sürümüdür ama tüm hayalleri içermez. MVP, kullanıcıya değer üretmeye yetecek en küçük özellik setiyle yola çıkar. "Minimum" kelimesi yanıltıcı; düşük kaliteli değil, dar kapsamlı demek.

MVP belirlemenin pratik yolu: tüm fikir listesini bir tabloya yazıp her özelliği "kullanıcı bu olmadan değer alabilir mi?" sorusundan geçirmek. Cevap "evet" ise özellik ikinci sürüme aktarılır. Sonunda elde kalan 3-5 madde MVP'yi oluşturur. Tipik MVP boyutu 3-6 ana ekran ve 8-12 hafta geliştirme süresidir.

MVP'de olmaması gereken klasik tuzaklar:

• Birden fazla rol (kullanıcı + admin + moderatör) — tek rol ile başlayın
• Sosyal giriş çeşitliliği (Google, Apple, Facebook, e-posta hepsi birden) — tek seçenek yeter
• Bildirim sistemi tüm senaryolarla — sadece kritik bildirim
• Çoklu dil desteği — tek dil ile başlayın
• İçeriden mesajlaşma — gerçekten gerekiyor mu sorgulayın

MVP'nin amacı pazara çıkmak değil, varsayımları ölçmek. İlk 100 kullanıcının davranışı sonraki 6 ay için yol haritası olur.

Geliştirme Süreci

Geliştirme aşaması iki paralel akıştan oluşur: frontend (uygulamanın görsel yüzü, kullanıcının dokunduğu kısım) ve backend (sunucu, veritabanı, API'lar). Tek geliştirici bu ikisini birlikte yapabilir; ekip büyüdükçe bu roller ayrılır.

Modern mobil uygulama geliştirme süreçleri Agile metodoloji üzerine kurulur: 1-2 haftalık sprint'ler, her sprint sonunda çalışan bir sürüm, sürekli geri bildirim. Şelale modeli (önce tüm tasarım, sonra tüm kod, sonra tüm test) mobil dünyada nadiren işe yarar çünkü ekran sayısı ve etkileşim çeşitliliği erkenden test edilmek ister.

Bir sprint'in tipik akışı:

1. Sprint planlama: Backlog'tan önceliklendirilmiş bir grup özellik seçilir.
2. Günlük kısa toplantı (stand-up): Dün ne yapıldı, bugün ne yapılacak, engel var mı.
3. Geliştirme: Kod yazımı, code review, ara test.
4. Sprint review: Çalışan sürüm ekibe ve paydaşa gösterilir.
5. Retrospektif: Süreçte neyin iyi gittiği, neyin değişmesi gerektiği konuşulur.

Geliştirme aşamasında veritabanı tasarımı, API kontratları ve güvenlik kararları (kullanıcı verisi nasıl saklanacak, ne zaman şifrelenecek, KVKK/GDPR uyumu nasıl olacak) erkenden netleşmeli. Sonradan dönmek pahalı bir refactor üretir.

Test Aşaması

Test, geliştirmenin bittiği bir aşama değil, geliştirmeyle iç içe yürüyen bir süreç. "Yazılım bitti, şimdi test edilecek" yaklaşımı klasik hata; doğrusu her sprint sonunda test edilen ve düzeltilen küçük parçalar.

Mobil uygulamada beş ana test katmanı vardır:

• Birim testi (unit test): Fonksiyon seviyesinde, geliştirici tarafından yazılır. Bir fiyat hesaplama fonksiyonunun doğru çalıştığını kanıtlar.
• Entegrasyon testi: Birden fazla bileşenin bir arada çalışıp çalışmadığı. API isteği yapıldığında dönen verinin doğru ekrana yansıması.
• UI testi (otomatik): Belirlenmiş bir kullanıcı akışının (giriş yap, ürün ekle, satın al) her sürümde otomatik yürütülmesi.
• Cihaz uyumluluk testi: Farklı ekran boyutları, OS sürümleri, performans seviyeleri. Türkiye'de 4 yıllık bir Android telefon hâlâ aktif kullanılıyor olabilir.
• Kullanıcı kabul testi (UAT): Gerçek kullanıcının uygulamayı 10-20 dakika kullanması, gözlem yapılması. En değerli test bu — kullanıcı sizin düşünmediğiniz şekilde dokunur.

Test sırasında çıkan bug'lar şiddet ve öncelik üzerinden sınıflandırılır: critical (uygulamayı durduran), major (akışı bozan), minor (kozmetik), trivial (önemsiz). Yayına çıkmadan önce critical ve major sıfırlanmış olmalı.

Mağazada Nasıl Yayınlanır?

Uygulama hazır olsa bile mağaza yayını başlı başına bir süreçtir. Google Play Store ve Apple App Store farklı kurallar, farklı inceleme süreleri ve farklı sertifikasyon gereksinimleri ile gelir.

Yayın öncesi hazırlık kontrol listesi:

1. Developer hesabı: Apple yıllık 99 USD, Google tek seferlik 25 USD.
2. Uygulama ikonu ve ekran görüntüleri: Birden fazla cihaz boyutu için.
3. Açıklama metni: Kısa açıklama (ilk üç satır kritik), uzun açıklama, anahtar kelimeler.
4. Gizlilik politikası: Zorunlu, ayrı bir web sayfasında erişilebilir olmalı.
5. İçerik derecelendirmesi: Yaş kategorisi, içerik uyarısı.
6. Test kullanıcıları: Beta dağıtım için TestFlight (iOS) veya kapalı test kanalı (Android).

Apple'ın inceleme süresi tipik olarak 24-48 saat; reddedilme oranı yüksek, ilk denemede çoğunlukla geri döner. Google daha hızlı (birkaç saat - 1 gün) ve daha esnek ama 2026 itibarıyla güvenlik incelemeleri sıkılaşmaktadır. Android tarafında Kotlin ile native geliştirme yapıyorsanız Android Kotlin eğitim sayfası mağaza paketleme ve Play Console adımlarını sıralı şekilde işleyen pratik bir başlangıç olur. Mağaza politikalarının resmi kaynağı için developer.android.com ana hubı düzenli kontrol edilmelidir.

ASO (App Store Optimization), yayın sonrası organik indirme için kritik. Başlık, kısa açıklama ve ilk üç ekran görüntüsü mağazada bulunma oranını doğrudan etkiler.

Bakım ve Güncellemeler

Uygulamanın yayınlanması projenin bitişi değil, ikinci yarısının başlangıcı. Bakım dönemi geliştirme bütçesinin %15-25'i kadar sürekli bir maliyet üretir ve ihmal edilirse uygulama altı ay içinde "ölü" hâle gelir.

Bakım dönemi dört ana iş başlığını içerir:

• İşletim sistemi güncellemelerine uyum: Yılda bir kez iOS, yılda bir kez Android büyük sürüm çıkarır. Eski API'lar deprecate olur, yeni izin modelleri gelir. Güncelleme yapmazsanız uygulamanız bir noktada açılmamaya başlar.
• Bug düzeltmeleri: Üretim ortamında ortaya çıkan crash'ler. Firebase Crashlytics gibi araçlarla otomatik raporlanır; öncelik sıralamasıyla giderilir.
• Kullanıcı geri bildirimi: Mağaza yorumları, in-app feedback, destek talepleri. İyi yönetilirse ürün yol haritasının zenginleştiricisi.
• Yeni özellik geliştirme: İkinci, üçüncü, dördüncü sürümler. Her sürüm MVP'deki varsayımları test eden gerçek verilerle yönlendirilir.

Bakım döneminin disiplinli yönetildiği uygulamalar mağazada yıldız puanlarını korur; ihmal edilenler bir yıl içinde 4.5'ten 3.2'ye düşer. Bu düşüş indirme grafiğine doğrudan yansır.

Sık Sorulan Sorular

Mobil uygulama yapımı ne kadar sürer?

Basit bir MVP 8-12 hafta, orta karmaşıklıkta bir uygulama 4-6 ay, kapsamlı bir platform 9-12 ay civarında sürer. Tek geliştirici ile çalışıyorsanız bu süreleri 1.5-2 katı düşünün. Süreyi en çok etkileyen faktör özellik sayısı değil, dış sistemlerle entegrasyon yoğunluğudur.

Wireframe ve mockup arasındaki fark nedir?

Wireframe ekranların kutu-etiket düzeyinde iskeletidir; renk, tipografi, görsel yoktur. Mockup ise bu iskelete marka renkleri, gerçek metin ve görseller giydirilmiş yüksek sadakatli tasarımdır. Wireframe akışı, mockup hissi konuşur. İki aşamayı atlamak çoğu zaman geri dönüşü pahalı tasarım hatalarına yol açar.

MVP ile pilot uygulama aynı şey mi?

Hayır. MVP halka açık ilk sürümdür, gerçek kullanıcılarla varsayımları doğrulamak için. Pilot ise dar bir kitleyle (genelde kurumsal müşteri veya iç ekip) sınırlı kullanım üzerinden yapılan deneme sürümüdür. MVP pazara çıkar, pilot içeride döner.

Tek başına mobil uygulama yapmak mümkün mü?

Mümkün ama belli sınırlar içinde. Tasarımı, geliştirmesi, testi ve yayını bir kişi yürütebilir; ancak süre 2-3 katına çıkar ve bazı alanlarda (özellikle UI tasarımı ve güvenlik denetimi) dış destek gerekebilir. Hobi projelerinde tek kişilik akış normal; ticari hedefli projelerde en az 2-3 kişilik bir ekip pratiktir.

Geliştirme bittikten sonra test ne kadar sürer?

Geliştirmenin %20-30'u kadar bir süre. Yani 12 haftalık bir MVP için 3-4 hafta test ve düzeltme döngüsü olağan. Bu süre paralel ilerlerse (her sprint sonunda test) toplam takvim kısalır; sırayla ilerlerse uzar. Test bitti demek için critical ve major bug listesinin sıfır olması, UAT'nin tamamlanmış olması beklenir.

Uygulama yayınlandıktan sonra reddedilirse ne yapılır?

Apple ve Google reddetme gerekçesini detaylı şekilde bildirir. Çoğu red gizlilik politikası eksikliği, izin gerekçelerinin belirsizliği, in-app purchase kurallarının ihlali veya içerik yönergelerine uymama nedeniyle olur. Düzeltme sonrası tekrar gönderim mümkündür; ikinci başvuruda inceleme daha hızlı sonuçlanır genellikle.

Bakım için ne kadar bütçe ayrılmalı?

İlk yıl geliştirme bütçesinin %15-25'i tipik bir aralık. Bu pay kullanıcı sayısı arttıkça, sunucu maliyetleri ve destek yoğunluğu büyüdükçe artar. Bakımı hafife alan projeler bir yıl içinde ölü uygulama durumuna düşer; mağaza puanı erir, indirme grafiği yatay seyrederek aşağı kayar.

Mobil uygulama yapımı, dışarıdan tek bir teknik iş gibi görünse de birbirine zincirli yedi-sekiz farklı disiplinin sıralı yürütülmesi. Her aşamada verilen kararlar bir sonrakini şekillendiriyor; doğrulamayı atlayan tasarımı kötü besler, MVP'yi şişiren geliştirmeyi kilitler, test edilmeyeni mağaza geri yollar. Bu sıralı akışı bilen ve her aşamada doğru soruyu soran ekipler, uygulamanın ilk altı ayını "hayatta kalma" değil "büyüme" dönemi olarak yaşıyor.