ANDROID UYGULAMA GELİŞTİRME

Android uygulama geliştirme süreci yeşil tonlu mimari diyagramı ve katmanlı proje yapısı

Üç ayda bitirilmesi planlanan bir Android projesi, sekizinci ayda hâlâ "neden bu kadar uzadı" toplantıları yaparken bulunur kendini. Sebep çoğu zaman kod yazmak değildir — modül sınırlarının baştan çizilmemiş olması, ViewModel'in Activity'ye sızdığı yerlerin sayılamayacak kadar çoğalması, ilk PR'da kabul edilen "geçici" çözümlerin yedinci sprintte kaldırılamaz hâle gelmesidir. Bir Android uygulamasını gerçekten üretime götüren şey Kotlin sözdizimi değil, projenin etrafına kurulan disiplindir.

Bu yazıda Android uygulama geliştirme sürecini bir proje yöneticisi gözüyle ele alıyoruz: gereksinim analizi, mimari kararı, UI katmanı seçimi, bağımlılık enjeksiyonu, test stratejisi, sürüm pipeline'ı ve Play Store yayını. Resmi araç dokümantasyonu için Jetpack hub birinci elden referans olarak yanınızda kalsın.

Geliştirme Süreci Nereden Başlar?

Kod yazmadan önce yapılması gereken iş, çoğu projede atlanan iştir: yazılacak ekranların listesi, her ekranın sorumluluğu, ekranlar arası geçiş haritası ve hangi verinin nereden geleceğinin sayfa sayfa belirlenmesi. Yirmi ekranlık bir uygulamanın ilk iki haftası, tek satır Kotlin yazılmadan harcanabilir — ve bu zaman, sonraki üç ayı kurtarır.

Gereksinim analizinde dört dosya yeterli: kullanıcı yolculuğu (onboarding'den ana akışa kadar), veri modeli (entity'ler ve aralarındaki ilişki), API kontratı (backend ile mutabakatlı endpoint listesi) ve cihaz/sürüm hedef matrisi (minSdk, targetSdk, desteklenecek OEM'ler). Bu dört dosya proje boyunca güncel tutulur; kararlar burada netleşmemişse kod katmanında sürekli geri dönülecek bir düğümdür.

Süreç tipik olarak şu aşamalardan oluşur:

Keşif (1-2 hafta): Hedef kullanıcı, rakip analizi, ana akış prototipi (Figma veya kağıt eskiz).
Mimari kararları (3-5 gün): Modül yapısı, mimari pattern, kütüphane seçimleri.
Iskelet kurulumu (1 hafta): Proje şablonu, DI, navigation, base sınıflar, CI pipeline taslağı.
Sprint geliştirme: 2 haftalık sprint'lerde özellik bazlı ilerleme, her sprint sonunda internal release.
Sertleştirme (2-3 hafta): Bug fix, performans, crash analytics, beta test.
Yayın ve gözetim: Staged rollout, kullanıcı geri bildirimi, hotfix süreci.

Hangi Mimari Seçilir?

Android tarafında üç ana mimari yaklaşımı konuşulur: MVVM, MVI ve Clean Architecture. Bunlar birbirinin alternatifi değil, farklı soyutlama seviyelerinde tamamlayıcı kavramlardır. Pratikte üretim uygulamalarının büyük çoğunluğu Clean Architecture'ın katman ayrımını MVVM veya MVI sunum kalıbıyla birleştirir.

Üç katmanlı standart düzen şöyle çalışır:

Data layer: Repository'ler, remote (Retrofit) ve local (Room) veri kaynakları, DTO-to-domain dönüşümleri. UI bilmez.
Domain layer: Use case'ler, saf Kotlin sınıfları, Android bağımlılığı içermez. En kolay test edilen katman.
Presentation layer: ViewModel'ler, UI state nesneleri, Compose ekranları veya Fragment'lar. Lifecycle burada yaşar.

MVVM ve MVI ayrımı sunum katmanında belirir. MVVM her UI değişimi için ayrı LiveData veya StateFlow yayar; MVI ise tek bir UiState sealed class'ı altında tüm ekran durumunu tutar ve Intent nesneleri ile değiştirir. MVI özellikle Compose ile çok iyi anlaşır: tek state akışı, tahmin edilebilir render. Karmaşık form ekranlarında MVI'nin getirdiği disiplin değerlidir; basit liste-detay ekranlarında MVVM yeterlidir.

Modülerleşme kararı da burada verilir. Tek modüllü bir uygulama 30-40 ekrana kadar yönetilebilir; ötesinde her özellik için ayrı feature modülü (:feature:auth, :feature:cart) ve ortak :core:network, :core:database modülleri ayrılır. Bu ayrım build süresini ciddi düşürür ve takım içi çakışmayı azaltır.

Android Clean Architecture katmanları data domain presentation yeşil tonlu modül diyagramı

Jetpack Compose mu, XML mi?

2025'ten itibaren yeni başlayan bir projede karar nettir: Jetpack Compose. Compose stable hâle geleli yıllar oldu; animasyon, navigation, accessibility ve Material 3 desteği üretim seviyesinde. XML hâlâ destekleniyor ama Google'ın yeni özellikleri öncelikle Compose tarafında geliştirmesi onu giderek bakım moduna itiyor.

Karar verilirken dört nokta tartılır:

Ekip deneyimi: Compose'a yeni geçen bir ekipte ilk iki ay verimlilik düşer. State hoisting, recomposition, side effect API'leri yeni paradigma getirir.
Mevcut kod tabanı: Brownfield projelerde tek seferde geçiş yerine yeni ekranların Compose ile yazılıp ComposeView ile XML ekranlara entegre edilmesi gerçekçidir.
Tasarım sistemi: Material 3 token tabanlı tema Compose ile çok daha temiz kurulur; özel tasarım dilleriyle de iyi anlaşır.
Performans: Çok uzun liste ve karmaşık animasyon senaryolarında Compose ölçülmeli; çoğu uygulamada bu sorun değil ama tek tip ekran içeren bir görüntüleyici uygulamada XML hâlâ daha tahmin edilebilir olabilir.

Pratikte yeni projede Compose, eski projede kademeli geçiş doğru yoldur. Geçişte Compose ekranlarını feature modülünde izole etmek, XML ve Compose karışımının yarattığı theme uyumsuzluklarını azaltır.

Bağımlılık Enjeksiyonu

İki üç ekranı geçen her Android projesinde DI bir lüks değil zorunluluktur. Repository'lerin manuel new ile her ekranda kurulması test edilemeyen, değiştirilemeyen bir kod tabanı doğurur. Android tarafında üç seçenek var: Hilt, Koin ve manuel servis locator. Çoğu profesyonel proje Hilt'i tercih eder çünkü compile-time doğrulama yapar ve Android lifecycle'larıyla (ViewModel, Activity, Fragment scope) doğrudan entegre çalışır.

Hilt modülü tipik olarak şöyle görünür:

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit = Retrofit.Builder()
        .baseUrl(BuildConfig.API_BASE_URL)
        .addConverterFactory(MoshiConverterFactory.create())
        .build()

    @Provides
    fun provideUserApi(retrofit: Retrofit): UserApi =
        retrofit.create(UserApi::class.java)
}

ViewModel tarafında @HiltViewModel ve constructor injection yeterli. Koin ise reflection tabanlı, çalışma zamanında hata verebilir ama Kotlin Multiplatform projelerinde Hilt'in olmaması nedeniyle tercih edilir. Karar projenin platform sayısına bağlı: tek Android ise Hilt, KMP varsa Koin.

Test Stratejisi

Android'de test piramidi çoğu projede tersine durur — üstte çok sayıda yavaş UI testi, altta birkaç unit test. Doğru piramit tersi: %70 unit, %20 integration, %10 UI testi. Use case'ler ve ViewModel'ler unit test ile, Repository'ler ve Room sorguları integration test ile, kritik kullanıcı akışları (login, ödeme) Espresso veya Compose UI test ile kaplanır.

Pratik bir kapsama hedefi katmana göre değişir:

Domain layer: %80+ kapsama. Saf Kotlin, hızlı test, en yüksek değer.
Data layer: %60-70. Mock web server ile API testi, in-memory Room ile veritabanı testi.
Presentation: %40-60. ViewModel'lerin state akışı, TestCoroutineDispatcher ile zaman kontrolü.
UI: Kritik akışlar için 10-15 senaryo yeter. Her ekran için UI testi yazmak bakım yüküdür.

Compose ile UI testi yazmak XML/Espresso günlerinden çok daha temiz. createComposeRule() ile izole ekran testi, onNodeWithText ile semantik sorgular yeterli. Snapshot testing (Paparazzi gibi araçlarla) tasarım regresyonlarını yakalamak için ek katman olarak kurulabilir.

CI/CD Pipeline Tasarımı

Pipeline yoksa Android uygulamasının kalitesi geliştiricinin son bir saatlik dikkatine kalır. Minimum pipeline'da her PR için lint, unit test, instrumented test (emülatör veya Firebase Test Lab) ve debug APK build aşamaları olmalı. Ana branch'e merge sonrası ise release variant build, signing, Play Store internal track upload otomatize edilir.

GitHub Actions ile basit bir akış şöyle kurgulanır:

Build matrix: API 24 ve API 34 emülatörlerinde paralel test.
Cache: Gradle ve Android SDK cache'i (build süresini yarıya indirir).
Lint ve Detekt: Kod kalitesi statik analizi, PR yorumlarına yazılır.
Test raporu: JUnit XML çıktısı PR'ye eklenir, başarısız test isimleri görünür.
Signing: Keystore base64 secret olarak saklanır, sadece protected branch'te çözülür.
Upload: Fastlane veya Gradle Play Publisher ile internal track'e otomatik yükleme.

Fastlane Android tarafında biraz eski moda kalmış olsa da hâlâ deploy adımları için en pratik araç. fastlane supply komutu AAB'yi yükler, changelog'u günceller, staged rollout yüzdesini ayarlar. Alternatif olarak Gradle Play Publisher plugin'i build script'ten doğrudan yükleme yapar — Fastlane bağımlılığını ortadan kaldırır.

Android CI/CD pipeline aşamaları lint test build sign Play Store upload yeşil tonlu akış şeması

Play Store'a Nasıl Yayınlanır?

Play Store yayın süreci ilk seferinde yapanı şaşırtacak kadar bürokratik. Sadece APK yükleyip "yayınla" demek değil; uyumluluk formları, hedef kitle beyanı, veri güvenliği bölümü, içerik derecelendirmesi, ücretsiz ve ücretli karar, lokalize store listing ve gizlilik politikası URL'i gerekir. İlk yayın iki haftaya kadar sürebilir.

Teknik tarafta önemli adımlar:

App Bundle (AAB): APK artık yayın için kabul edilmiyor; AAB zorunlu. Google Play her cihaz için optimize APK üretir.
Signing: Play App Signing'e geçiş şart. Upload key'i kaybetseniz bile Google'da saklanan signing key sayesinde uygulama erişilir kalır.
Track yapısı: internal → closed (alpha) → open (beta) → production. Her seviyede ayrı kullanıcı listesiyle test.
Staged rollout: Production'a %1, %5, %20, %50, %100 kademeli yükleme. Crash oranı yükselirse durdurma şansı.
Pre-launch report: Google bir grup cihazda otomatik test yapar, crash ve performans raporu çıkarır.

İlk versiyonun reddedilmesi sık karşılaşılan bir durum: çoğu zaman izin gerekçeleri eksiktir (özellikle READ_EXTERNAL_STORAGE ve ACCESS_BACKGROUND_LOCATION) veya veri güvenliği formu uygulamanın gerçek davranışıyla uyuşmaz. Gerekli izinlerin neden istendiği uygulamanın store listing'inde ve gizlilik politikasında net anlatılmalı.

Sürüm Sonrası Bakım

Yayın sonu bir kapanış değil, başka bir döngünün başlangıcı. İlk 72 saat crash analytics (Firebase Crashlytics veya Sentry) sürekli izlenir; crash-free user oranı %99.5'in altına düşüyorsa rollout durdurulur ve hotfix planlanır. Performance Monitoring start-up süresi, frame drop oranı ve network latency'yi izler.

Düzenli olarak takip edilecek metrikler:

Crash-free user oranı: Hedef %99.5+.
ANR (Application Not Responding): Play Console'da %0.47 üstünde uyarı.
Cold start süresi: 2 saniye altı ideal, 5 saniye üstü problemli.
Vitals raporu: Slow rendering, excessive wakeups, battery drain.
Kullanıcı yorumları: 1-2 yıldız yorumlar geliştirme backlog'una otomatik akıtılmalı.

Android tarafında Kotlin temellerini sağlamlaştırmak isteyenler için Android Kotlin eğitimi dil ve Android framework'ünü birlikte ele alır; mimari ve süreç tarafı kendi başına oturduğunda dil tarafının da sağlam olması projenin riskini ciddi düşürür. Resmi geliştirici dökümantasyonu için Android Developers ana sayfası her sürümle güncellenen yol haritasını ve örnek projeleri içerir.

Sık Sorulan Sorular

Android uygulama geliştirme projesi ortalama ne kadar sürer?

Karmaşıklığa bağlı. Tek ana akışlı bir MVP (5-8 ekran) tek geliştirici ile 8-12 haftada üretime gider. Orta ölçekli e-ticaret veya bankacılık uygulaması (40-60 ekran, ödeme entegrasyonu) iki kişilik bir ekiple 5-8 ay sürer. Kurumsal kapsamlı projelerde 12+ ay normaldir. Süreyi belirleyen kod miktarı değil, dış sistem entegrasyon sayısıdır.

MVVM ve MVI arasında hangisi tercih edilmeli?

Basit ekranlar için MVVM yeterli; karmaşık form ve durum yönetimi olan ekranlarda MVI daha öngörülebilir. Compose ile çalışılıyorsa MVI'nin tek state akışı recomposition mantığıyla doğal eşleşir. Aynı projede iki yaklaşımı karıştırmak da mümkün — kritik ekranlarda MVI, geri kalanında MVVM kullanılabilir.

Tek modüllü proje mi, çok modüllü proje mi?

20 ekrana kadar tek modül yönetilebilir. Üstüne çıkıldığında build süresi artar, takım içi merge çakışmaları başlar. Çok modüllü yapıya geçiş erken yapılırsa altyapı yükü, geç yapılırsa refactor maliyeti yüksek olur. Pratik kural: 3+ geliştirici çalışıyorsa veya 30+ ekran planı varsa baştan modüler başlanır.

Play Store'a yayın için minimum gereksinim nedir?

Google Play Developer hesabı (tek seferlik 25 USD), App Bundle formatında imzalanmış paket, store listing (icon, ekran görüntüleri, açıklama), gizlilik politikası URL'i, içerik derecelendirme anketi cevapları ve veri güvenliği formu. İlk inceleme 1-7 gün sürer; yeni hesaplarda 14 günlük test süresi de istenebilir.

Jetpack Compose performans açısından XML'den geride mi?

Tipik uygulama senaryolarında fark hissedilmez. Çok uzun listede (binlerce satır) Compose ilk sürümlerde XML'in RecyclerView performansının altındaydı; son sürümlerde LazyColumn optimizasyonları ile fark büyük ölçüde kapandı. Performans hassas senaryolarda profiling şart; varsayım yapılmamalı.

Hilt yerine Koin kullanmak ne zaman mantıklı?

Kotlin Multiplatform projesinde Hilt yok, Koin doğru tercih. Saf Android projesinde Hilt compile-time doğrulama avantajı sebebiyle önde. Çok küçük projelerde (3-4 ekran) Hilt'in annotation processor overhead'i sebebiyle Koin daha hafif kalabilir. Karar mimari değil ekosistem sorusu.

Crash oranı kabul edilebilir sınır nedir?

Google Play Console crash-free user oranı için %99.5'i sağlıklı, %99'un altını uyarı olarak işaretler. Production'da %98 altı kullanıcı terk oranını ciddi artırır. ANR oranı %0.47'nin altında tutulmalı; üstünde Play Store görünürlüğü düşer. İlk yayında ilk 48 saat saatlik izleme şart.

Android uygulama geliştirme süreci tek bir teknik karar değil, üst üste binen onlarca küçük kararın toplamıdır. Mimariyi doğru kurmak, test edilebilir bir yapı bırakmak, pipeline'ı ilk günden çalıştırmak ve yayın sonrası sinyalleri okumak — bu dört ekseni ihmal etmeyen ekipler aynı süre ve bütçeyle çok daha yüksek kaliteli ürün çıkarır. Geri kalanı detaydır ve detayların çoğu deneyimle oturur.