2026'da tek başıma Android uygulamalarını nasıl yayınlıyorum

2026’da tek başına bir Android uygulaması yayınlamanın en zor kısmı kod değil. Compose olgunlaştı, Play’in araçları iyi ve kimsenin okumaya vakti olmayacak kadar çok kütüphane var. Zor kısım bitirmek. Kapsam genişliyor, cila takvimi tüketiyor ve bir gün fark ediyorsun ki üç ay önce başladığın uygulama teknik olarak daha etkileyici ama hâlâ mağazada değil.

Ben bu yolla iki uygulama yayınladım, üçüncüsü de sırada, ve sonunda fikirden canlı ilana yaklaşık dört ila altı haftada götüren bir rehber üzerinde karar kıldım. Hiçbiri akıllıca değil. Hepsi şeylere hayır demekle ilgili.

1. Kapsamı acımasızca daralt — tek ekran, tek fiil

Herhangi bir Kotlin yazmadan önce tek bir alıştırma yapıyorum: uygulamayı tek fiille tek cümlede tarif et. Granyn — iki dokunuşta bir harcamayı kaydet. Hydrame — su içmeyi unutmadan önce sakin bir hatırlatma al. Subly — bir faturanın fotoğrafını çek, aboneliği cihazda çıkart. Cümlede bir “ve” varsa, uygulama iki uygulamadır.

Bu tek cümle, her özellik kararının kuralı hâline geliyor. Grafikler? Yalnızca fiili destekliyorlarsa. Bulut senkronizasyonu? Yalnızca olmaması fiili bozuyorsa. Ayarlar? Ne kadar az o kadar iyi. Tek kişilik geliştirmede en hafife alınan numara, bir şeyler yapmamak.

Tek cümlelik tanıtımında bir “ve” varsa, iki uygulama geliştiriyorsun demektir.

Bunu uygulamaya sokmanın gerçek bir yolu: herhangi bir kod yazmadan önce Play Store ilanını yaz — başlık, kısa açıklama, 80 karakterlik alt başlık. Uygulamayı 80 karakterde satamıyorsan, onu sekiz haftada da yapamazsın.

2. Küçük, sıkıcı bir teknoloji yığını seç

2026’da Android için tüm yığınım bilinçli olarak küçük:

• Kotlin + Jetpack Compose (XML düzenleri yok, fragment yok)
• androidx.navigation.compose ile tek activity
• Yerel her şey için Flow ve suspend fonksiyonlarıyla Room
• Ayarlar için DataStore (preferences türü)
• Arka plan için WorkManager, yalnızca kesinlik gerektiğinde AlarmManager
• Bileşenler için özel bir renk şemasıyla Material 3
• DI için Hilt — ama yalnızca uygulama buna ihtiyaç duyacak kadar büyükse (Granyn evet, minik bir yardımcı araç hayır)

Tüm liste bu. KSP ağırlıklı üreteçler yok, uygulama gerçekten bir sunucuyla konuşmadıkça ağ katmanı yok, üçüncü taraf UI kitleri yok. Kural: yeni bir bağımlılık, build.gradle.kts içindeki satırını yazmaya razı olacağım tek cümlelik bir gerekçeyle hak etmeli.

3. Önce sıkıcı ekranları geliştir

Sezgiye aykırı ama doğru: kahraman özellikten önce en heyecansız ekranları geliştiriyorum. Boş durumlar, ayarlar, ilk kullanım (onboarding), “henüz veri yok” yer tutucuları. Bunlar veri modelini ve gezinme grafiğini her şeyden daha hızlı ortaya çıkarır ve sona sakladığında korkacağın ekranlar da bunlardır.

Kahraman özellik üçüncü ya da dördüncü sırada gelir. Ona ulaştığımda, veri katmanı zaten ondan okumaya ihtiyaç duyan sıkıcı ekranlar tarafından tasarlanmış oluyor.

Her projede yeniden kullandığım minimal bir iskelet:

@Composable
fun App() {
    val navController = rememberNavController()
    Scaffold(
        bottomBar = { AppBottomBar(navController) },
    ) { inner ->
        NavHost(
            navController = navController,
            startDestination = Routes.Home,
            modifier = Modifier.padding(inner),
        ) {
            composable(Routes.Home) { HomeScreen() }
            composable(Routes.Stats) { StatsScreen() }
            composable(Routes.Settings) { SettingsScreen() }
        }
    }
}

Uygulamalarımın yarısının tüm “mimarisi” bu.

4. Veri modelini erken sabitle, sonsuza dek göç et

Şema göçleri, indie uygulamaların sessiz katilidir. Çözüm, veritabanını bir genel API gibi düşünmek — bir kez üretime girdiğinde her değişiklik, testi olan bir göçtür. Room bunu yönetilebilir kılıyor:

@Database(
    entities = [Expense::class, Category::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3, spec = MigrateNotesField::class),
        AutoMigration(from = 3, to = 4),
    ],
    exportSchema = true,
)
abstract class AppDatabase : RoomDatabase() { ... }

Yaptığım en yararlı tek şey: exportSchema = true ve o JSON dosyalarını git’e commit’lemek. Sonra Room tarafından yönetilen bir test, şema gerilemelerini bir kullanıcı cihazına ulaşmadan önce yakalıyor. Bunun bana kurtardığı kötü öğleden sonraların sayısını sayamıyorum.

5. Gerçek telefonlarda manuel test, yalnızca önemli olan yerde otomasyon

Tek kişilik geliştirici test piramidi: test etmesi kolay ama başka türlü hata ayıklaması imkânsız olan kısımlar için bir avuç saf birim testi (para birimi matematiği, tarih matematiği, Subly’deki OCR alan çıkarımı). Sıfır UI testi. Üç gerçek telefonda yoğun manuel duman testi: bir Pixel, bir Samsung orta segment ve gerçekten ucuz bir Xiaomi. Ucuz telefon pazarlık konusu değil — kullanıcılarının gerçekten sahip olduğu telefon o.

Samsung ve Xiaomi’nin ikisi de emülatörde görünmeyen gerçek sorunlar ortaya çıkaracak. Agresif pil optimizasyonuyla öldürülen bildirimler, sessizce yeniden zamanlanan kesin alarmlar, 200 ms geç tetiklenen titreşim desenleri. Uygulamanın güvenilir bildirimlere ihtiyacı varsa (Hydrame’in var), bir Samsung’da test et yoksa yayından sonra öğrenirsin.

6. Play Store ilanı uygulamanın yarısıdır

Mağaza ilanına bir hafta sonu ayır. Başlık ve kısa açıklama SEO’dur. Ekran görüntüleri dönüşümdür. Öne çıkan görsel (feature graphic), birinin markanla geçirdiği ilk 1,6 saniyedir.

Gerçekçi bir kontrol listesi:

• Birincil anahtar kelimeyle Başlık (şirin olmaya çalışma — “Granyn — Budget & Expense Tracker”, “Granyn”i yener)
• Fiil ve tek ayırt edici özellikle Kısa açıklama (80 karakter)
• Üç ila beş kısa paragraf, alt başlıklar ve idareli kullanılan emojilerle Uzun açıklama
• 1080×2400 veya daha yüksekte Ekran görüntüleri, ilk ekran görüntüsü kahraman görselin olacak şekilde. Çoğu kullanıcı asla kaydırmaz.
• Öne çıkan görsel (1024×500). Metni minimumda tut — bu bir afiş, reklam panosu değil.
• Gizlilik politikası URL’si — zorunlu. Kendin barındır (GitHub Pages işe yarar) ki bir sürüm çıkarmadan düzenleyebilesin.
• İçerik derecelendirmesi — anketi dürüstçe doldur. Düşündüğünden daha hızlı.
• Uygulama sınıflandırması — Veri Güvenliği (Data Safety) formu. Bunu ciddiye al; gizlilik politikanın halka açık versiyonu.

Veri Güvenliği formu, çoğu kişinin acele ettiği kısımdır. Bir avukata açıklıyormuş gibi doldur. “Veri toplanmıyor”u işaretleyemiyorsan, hangi üçüncü tarafın (Firebase, AdMob, Play Billing) hangi alanı işlediğini tam olarak açıkla. Google her yıl bunu çalışma zamanı davranışına karşı daha katı kontrol ediyor.

7. Sessizce yayınla, huniyi izle

Önce kendi ülkende yumuşak lansman yap. Duyurma. İlk 50 kurulum senin beta’n — çökme raporlarına, ANR’lere ve kurulum/kaldırma oranına dikkat et. 1. gün elde tutma %30’un altındaysa, herhangi bir pazarlama yapmadan önce ilk kullanımı (onboarding) düzelt.

İlk iki hafta boyunca her sabah Play Console’da ilk baktığım şey:

• Çökmesiz kullanıcı %
• ANR oranı
• Vitals (aşırı uyandırmalar, donmuş kareler)
• 1 yıldızlı yorumlar — her kelimeyi oku. Altın değerindedirler.

Sonra daha geniş yayarım — önce Avrupa’nın geri kalanına, sonra global. Aşamalı yayın (10% → 25% → 50% → 100%) ücretsiz; kullan.

8. Yayın sonrası sıkıcı işler

Lansmandan iki hafta sonra asıl iş başlıyor: yorumlara yanıt vermek, ilk 500 kullanıcının bulduğu küçük hataları düzeltmek ve bir sonraki uygulamaya başlama dürtüsüne direnmek. Haftada bir küçük, dürüst değişiklik günlükleriyle güncellemek, hiçbir akıllı pazarlamanın kıyaslayamayacağı bir tür güven inşa eder.

ASO’nun katlanarak biriktiği yer de burası. Başlık ve açıklamadaki anahtar kelimeler, istikrarlı bir küçük güncelleme akışı ve organik yorumların yavaş sızıntısı — hiçbiri gösterişli değil, hepsi işe yarıyor.

Bir dahaki sefere neyi farklı yapardım

Kısa bir liste, çünkü geç akıl en iyi öğretmendir:

1. Önce Play Store ilanını yaz. Onu spesifikasyon olarak ele al. Şaka yapmıyorum.
2. İlk günden daha büyük boş durumlar. Boş bir ekran ilk izlenimi öldürür; özenli bir boş durum sana ikinci bir açılış kazandırır.
3. İlk kullanım (onboarding) tek ekran alır. Belki iki. Üçe ihtiyacın varsa, uygulamada çözecek bir UX sorunun var, daha uzun bir ilk kullanım değil.
4. İlk gün Crashlytics’i kur. Evet, minik bir yardımcı araç için bile.
5. Kendi alan adında veya GitHub Pages’te barındırılan gizlilik politikası. Onu düşündüğünden daha sık güncelleyeceksin ve her küçük değişiklik için bir Play Console yeniden incelemesi istemezsin.

Tüm rehber bilinçli olarak romantik değil. Indie geliştirmenin romantizmi yayınlama özgürlüğüdür; rehber ise bu özgürlüğü kendi kapsam kaymandan koruyan şeydir.

Şu anda yarı bitmiş bir Android uygulamasının ortasında bir yerdeysen, bu hafta yapabileceğin en yararlı şey bir özelliği silmek. Sonra git Play Store açıklamasını yaz. Lansman düşündüğünden daha yakın — seni durduran şeyin çoğu ekranın senin tarafında.