Google Play Uygulama Geliştirme Deneyimi: Kotlin + Jetpack Compose ile Öğrendiğim 5 Şey

Google Play uygulama geliştirme deneyimi, yalnızca Android Studio’da çalışan bir uygulama hazırlayıp AAB dosyasını Play Console’a yüklemekten ibaret değil. Kotlin ve Jetpack Compose ile geliştirdiğim Dolap Hafızası uygulamasını gerçek kullanıcılara ulaştırdıktan sonra bunu çok daha net gördüm.

Geliştirme sırasında kod, mimari ve kullanıcı arayüzü ön plandayken uygulama Google Play’e çıktığında işin içerisine gerçek cihazlar, Android sürümleri, cihaz uyumluluğu, bildirim izinleri, arka plan kısıtlamaları, Play Console politikaları, kullanıcı geri bildirimleri ve mağaza optimizasyonu giriyor.

Kısacası uygulamanın Android Studio’da sorunsuz çalışması ile gerçek kullanıcıların telefonlarında sorunsuz çalışması aynı şey değil.

Bu yazıda Kotlin, Jetpack Compose, MVVM, Room, Flow, WorkManager, DataStore ve Firebase gibi teknolojileri kullandığım Dolap Hafızası projesinde karşılaştığım gerçek durumları ve bu süreçten çıkardığım 5 önemli dersi paylaşacağım.

Amacım Dolap Hafızası’nı tanıtmaktan çok, gerçek bir Android uygulamasını geliştirme aşamasından Google Play’e ve oradan gerçek kullanıcılara ulaştırma sürecinde öğrendiklerimi aktarmak.

Google Play Uygulama Geliştirme Deneyimi Neden Android Studio’dan Daha Fazlası?

Bir mobil uygulama geliştirirken zamanın büyük bölümünü doğal olarak kod tarafında geçiriyoruz.

Ekranlar hazırlanıyor, ViewModel’ler oluşturuluyor, veriler kaydediliyor, kullanıcı akışı test ediliyor ve uygulama emülatörde başarılı şekilde çalışıyor.

Bu aşamada insanda şöyle bir düşünce oluşabiliyor:

“Uygulama çalışıyor. Artık Google Play’e yükleyebilirim.”

Teknik olarak doğru olsa da gerçek ürün geliştirme süreci aslında burada yeni başlıyor.

Dolap Hafızası’nı geliştirirken kullandığım temel yapı şu şekildeydi:

Kotlin
    ↓
Jetpack Compose
    ↓
MVVM
    ↓
ViewModel
    ↓
Flow / StateFlow
    ↓
Room
    ↓
WorkManager
    ↓
DataStore
    ↓
Firebase Cloud Messaging

Buna fotoğraf işlemleri, barkod, nesne tanıma, bildirimler, kullanıcı ayarları ve Google Play tarafındaki süreçler de eklendiğinde uygulama yalnızca birkaç Compose ekranından oluşan bir proje olmaktan çıkıyor.

Gerçek bir ürüne dönüşüyor.

Dolap Hafızası Nedir?

Dolap Hafızası, evde bulunan eşyaların nerede saklandığını hatırlamayı kolaylaştırmak için geliştirdiğim Android uygulaması.

Temel fikir oldukça basit:

“Bu eşyayı nereye koymuştum?”

sorusuna uygulama içerisinden hızlı şekilde cevap verebilmek.

Kullanıcı evdeki odaları ve saklama alanlarını oluşturabiliyor, eşyalarını kaydedebiliyor ve daha sonra arama yaparak eşyanın nerede olduğunu bulabiliyor.

Uygulamada kullandığım özelliklerden bazıları:

• Oda ve saklama alanı sistemi,
• eşya kaydı,
• fotoğraf ekleme,
• barkod bilgisi,
• not ekleme,
• son kullanma tarihi takibi,
• favoriler,
• yerel hatırlatıcılar,
• açık ve koyu tema,
• akıllı öneriler,
• ML Kit ile nesne tanıma,
• Firebase bildirimleri.

Uygulama ağırlıklı olarak local-first mantığıyla çalışıyor.

Bu karar projenin ilerleyen aşamalarında düşündüğümden çok daha önemli hale geldi.

1. Emülatörde Çalışması Gerçek Cihazda Çalışacağı Anlamına Gelmiyor

Android geliştirmede ilk öğrendiğim en önemli derslerden biri bu oldu.

Android Studio emülatörü geliştirme sırasında son derece kullanışlı. Farklı ekran boyutlarını ve Android sürümlerini hızlı şekilde test etmek mümkün.

Fakat emülatör kontrollü bir ortam.

Gerçek Android ekosistemi ise oldukça parçalı.

Karşınıza:

• farklı Android sürümleri,
• farklı üretici ROM’ları,
• farklı pil optimizasyonları,
• farklı ekran boyutları,
• üreticiye özel izin yönetimleri,
• Google Play sertifikasyon farklılıkları

çıkabiliyor.

Dolap Hafızası üzerinde bunun en somut örneklerinden birini cihaz uyumluluğu konusunda yaşadım.

Uygulama teknik olarak ilgili Android sürümünde çalışabilecek durumda olmasına rağmen Google Play tarafındaki cihaz bütünlüğü ve sertifikasyon filtreleri bazı cihazlarda uygulamanın mağazada uyumsuz görünmesine neden olabiliyordu.

Bu tip bir problem emülatörde kolay kolay karşınıza çıkmıyor.

Çünkü sorun doğrudan uygulamanın Kotlin kodundan kaynaklanmıyor.

Google Play dağıtım katmanında ortaya çıkıyor.

Gerçek Cihaz Testinde Nelere Bakıyorum?

Artık yalnızca uygulamanın açılıp açılmadığını kontrol etmiyorum.

Özellikle şunlara bakıyorum:

• Uygulama Google Play’den gerçekten indirilebiliyor mu?
• Farklı Android sürümlerinde izin ekranları doğru çalışıyor mu?
• Bildirimler ulaşıyor mu?
• WorkManager görevleri zamanında çalışıyor mu?
• Fotoğraf seçimi ve kamera işlemleri doğru mu?
• Karanlık tema tüm ekranlarda düzgün mü?
• Uygulama arka plana alındığında süreç nasıl davranıyor?
• Cihaz yeniden başladıktan sonra gerekli görevler devam ediyor mu?
• Pil optimizasyonları arka plan görevlerini etkiliyor mu?

Bu kontrollerin bir bölümü emülatörde yapılabilir.

Ancak üretime çıkmadan önce en az birkaç gerçek cihaz üzerinde test yapmak bana göre artık zorunlu.

2. Google Play Console da Geliştirmenin Bir Parçası

İkinci büyük dersim Play Console tarafında oldu.

Google Play Console’u başlangıçta yalnızca uygulamanın AAB dosyasını yüklediğimiz bir yönetim paneli gibi görmek kolay.

Gerçekte ise ürün geliştirme sürecinin önemli bir parçası.

Burada yalnızca yeni sürüm göndermiyorsunuz.

Aynı zamanda:

• cihaz uyumluluğunu,
• Android sürümlerini,
• test kanallarını,
• uygulama bütünlüğünü,
• politika bildirimlerini,
• ANR ve crash raporlarını,
• kullanıcı yorumlarını,
• mağaza performansını

takip ediyorsunuz.

API 36 Geçişi

Dolap Hafızası’nı geliştirirken Android’in güncel hedef API gereksinimlerine de uyum sağlamak gerekti.

Google’ın güncel gereksinimine göre 31 Ağustos 2026’dan itibaren Google Play’e gönderilen yeni Android uygulamaları ve uygulama güncellemelerinin Android 16, yani API düzeyi 36 veya üzerini hedeflemesi gerekiyor.

Bu nedenle target SDK yükseltmesini yalnızca Gradle içerisinde:

targetSdk = 36

yazmak olarak görmemek gerekiyor.

Yeni API seviyesini hedeflediğinizde Android’in davranış değişikliklerini de incelemek gerekiyor.

Google’ın resmi dokümantasyonuna göre hedef API seviyesi yükseldiğinde yeni güvenlik, gizlilik ve platform davranışları uygulamayı etkileyebiliyor.

Bu nedenle benim için doğru yaklaşım şu oldu:

1. SDK’yı yükselt.
2. Projeyi derle.
3. Davranış değişikliklerini incele.
4. Gerçek cihazda test et.
5. AAB oluştur.
6. Test kanalında kontrol et.
7. Sonra production’a geç.

Google’ın güncel hedef API gereksinimlerini Android Developers resmi dokümantasyonundan takip etmek mümkün.

AAB Oluşturmak İşin Sonu Değil

Google Play’e gönderilen Android uygulamalarında Android App Bundle, yani AAB kullanılıyor.

Ancak doğru şekilde imzalanmış AAB oluşturmak yayın sürecinin yalnızca teknik kısmı.

Sonrasında Play Console:

• uyumluluk,
• politika,
• cihaz erişimi,
• SDK gereksinimleri,
• uygulama bütünlüğü

gibi farklı kontroller gerçekleştiriyor.

Dolayısıyla Android geliştiricisinin yalnızca IDE tarafına değil Play Console tarafına da hakim olması gerektiğini düşünüyorum.

3. Local-First Mimari Gerçekten Değerli

Dolap Hafızası projesinde aldığım önemli mimari kararlardan biri, temel özellikleri internet bağlantısına bağımlı hale getirmemek oldu.

Uygulamada kullanıcıların oluşturduğu:

• odalar,
• saklama alanları,
• eşyalar,
• notlar,
• favoriler,
• son kullanma tarihi bilgileri

yerel veritabanında tutuluyor.

Burada Room kullanıyorum.

Google’ın Android mimari rehberinde offline-first uygulama, temel fonksiyonlarının tamamını veya kritik bölümünü internet erişimi olmadan gerçekleştirebilen uygulama olarak tanımlanıyor.

Dolap Hafızası’nın yapısıyla bu yaklaşım oldukça iyi örtüşüyor.

Kullanıcı dolabındaki bir eşyanın nerede olduğunu görmek için internet bağlantısını beklemek zorunda değil.

Veri zaten cihazda.

Neden Room?

Room, SQLite üzerinde Android Jetpack tarafından sağlanan bir abstraction layer.

Benim açımdan en önemli avantajları:

• SQL sorgularının compile-time kontrolü,
• Entity ve DAO yapısının okunabilir olması,
• Flow ile kolay entegrasyon,
• migration desteği,
• ViewModel ile rahat kullanılabilmesi.

Örneğin bir DAO tarafında:

@Query("SELECT * FROM items ORDER BY name ASC")
fun getAllItems(): Flow<List<ItemEntity>>

şeklindeki bir yapı ile veri değiştiğinde UI tarafına güncel liste aktarılabiliyor.

Room + Flow + StateFlow

Benim kullandığım akış genel olarak şu mantığa dayanıyor:

Room Database
      ↓
DAO
      ↓
Repository
      ↓
Flow
      ↓
ViewModel
      ↓
StateFlow
      ↓
Jetpack Compose UI

Veritabanında bir değişiklik olduğunda kullanıcı arayüzünü manuel şekilde tekrar yenilemek yerine reactive yapıdan yararlanıyorum.

Bu özellikle Compose ile oldukça doğal bir geliştirme deneyimi oluşturuyor.

Local-First Kullanıcı İçin Ne Sağlıyor?

Teknik mimariden daha önemli taraf kullanıcı deneyimi.

Kullanıcı uygulamayı açtığında:

• sunucu bağlantısı beklemiyor,
• login olmak zorunda değil,
• temel verileri görmek için internet gerekmiyor,
• eşya araması doğrudan cihaz üzerinde yapılabiliyor.

Ev içerisindeki eşya takip uygulaması için bunun doğru yaklaşım olduğunu düşünüyorum.

Google da offline-first mimarilerde yerel veri kaynağının uygulamanın temel okuma işlemleri için merkezi kaynak olarak kullanılmasını öneriyor.

Konuyla ilgili detaylar Android Developers offline-first mimari rehberinde bulunuyor.

4. WorkManager ve Bildirimler Tahmin Ettiğimden Daha Hassas

Android uygulamasında belirli bir zamanda kullanıcıya bir şey hatırlatmak ilk bakışta oldukça kolay görünüyor.

Bir tarih seçilir, zaman geldiğinde bildirim gösterilir.

Gerçek cihazlarda işler bu kadar basit değil.

Android:

• pil tüketimini,
• arka plan uygulamalarını,
• iş zamanlamasını,
• Doze Mode’u,
• uygulama standby durumunu

agresif şekilde yönetebiliyor.

Dolap Hafızası’nda son kullanma tarihi gibi özellikler bulunduğu için arka plan işlerinin güvenilir çalışması önemli.

Neden WorkManager?

Android’in resmi mimari önerilerinde kalıcı ve ertelenebilir arka plan işleri için WorkManager önemli araçlardan biri.

Örneğin kullanıcı bir ürün için hatırlatıcı oluşturduğunda uygulamanın o anda açık olup olmayacağını bilmiyoruz.

WorkManager burada işi Android sistemine zamanlamamızı sağlıyor.

Basitleştirilmiş bir örnek:

val request =
    OneTimeWorkRequestBuilder<ReminderWorker>()
        .setInitialDelay(delay, TimeUnit.MILLISECONDS)
        .build()

WorkManager
    .getInstance(context)
    .enqueue(request)

Ancak gerçek uygulamada yalnızca worker oluşturmak yeterli değil.

Şunların da test edilmesi gerekiyor:

• kullanıcının bildirim izni,
• cihazın pil optimizasyonu,
• Android sürümü,
• uygulamanın uzun süre açılmaması,
• cihaz yeniden başlatma senaryosu,
• hatırlatıcının iptal edilmesi veya güncellenmesi.

Firebase Bildirimleri Ayrı Bir Konu

Dolap Hafızası’nda yerel hatırlatıcıların yanında Firebase Cloud Messaging üzerinden genel bildirimler de kullanılabiliyor.

Burada iki farklı ihtiyaç ortaya çıkıyor:

Yerel bildirim:

Kullanıcının kendi oluşturduğu bir son kullanma tarihi hatırlatıcısı.

FCM bildirimi:

Uygulama kullanıcılarına genel bir duyuru veya dönemsel bilgilendirme gönderilmesi.

Bu ikisini mimari olarak birbirinden ayırmak uygulamanın ilerleyen aşamalarında yönetimi kolaylaştırıyor.

Bildirim Gönderebiliyor Olmak Her Bildirimi Göndermek Anlamına Gelmiyor

Burada teknik olmayan ama ürün tarafında önemli başka bir şey öğrendim.

Bir uygulamada push notification özelliğinin olması, kullanıcıya sürekli bildirim göndermek gerektiği anlamına gelmiyor.

Gereksiz bildirim:

• bildirim izninin kapatılmasına,
• uygulamanın rahatsız edici bulunmasına,
• hatta uygulamanın kaldırılmasına

neden olabilir.

Bu nedenle bildirim tarafında teknik olarak “gönderebilir miyim?” sorusundan önce:

“Bu bildirim gerçekten kullanıcıya değer sağlıyor mu?”

sorusunu sormak gerektiğini düşünüyorum.

5. Google Play’de “Yayınlandı” Aslında Başlangıç

Bir uygulamanın Google Play tarafından onaylanıp production’a çıkması geliştirici açısından oldukça güzel bir an.

Uzun süredir geliştirdiğiniz ürün artık herkes tarafından indirilebilir hale geliyor.

Fakat birkaç gün sonra fark ediyorsunuz ki geliştirme sürecinin finaline değil, başka bir aşamasının başlangıcına gelmişsiniz.

Çünkü artık gerçek kullanıcılar var.

Gerçek Kullanıcı Her Zaman Farklı Kullanıyor

Geliştirici olarak uygulamayı nasıl kullanacağınızı biliyorsunuz.

Hangi butonun ne yaptığını biliyorsunuz.

Hangi ekrandan hangi ekrana geçileceğini de biliyorsunuz.

Kullanıcı ise bunların hiçbirini bilmek zorunda değil.

Bu nedenle gerçek kullanıcı geri bildirimi:

• UI problemlerini,
• anlaşılmayan özellikleri,
• eksik açıklamaları,
• cihaz uyumsuzluklarını,
• beklenmeyen kullanım senaryolarını

çok daha hızlı ortaya çıkarabiliyor.

Play Console Verileri Önem Kazanıyor

Yayın sonrasında artık yalnızca Android Studio logcat’e bakmıyorsunuz.

Play Console içerisindeki veriler de geliştirme kararlarını etkiliyor.

Örneğin:

• hangi Android sürümlerinin kullanıldığı,
• hangi cihazların uygulamayı çalıştırdığı,
• crash oranları,
• ANR problemleri,
• kullanıcı yorumları,
• sürüm dağılımı

takip edilebiliyor.

Böylece geliştirme süreci tahminlere değil, gerçek kullanım verilerine daha fazla dayanıyor.

Cihaz Uyumluluğu Sorunu Bana Ne Öğretti?

Dolap Hafızası üzerinde yaşadığım en öğretici durumlardan biri cihaz uyumluluğu oldu.

Bir cihazın teknik olarak gerekli Android sürümüne sahip olması, Google Play’in o cihaza uygulamayı mutlaka sunacağı anlamına gelmeyebiliyor.

Play Console tarafında:

• cihaz kataloğu,
• uygulama manifest’i,
• minimum SDK,
• ABI desteği,
• cihaz sertifikasyonu,
• Play Integrity gibi mekanizmalar

da dağıtımı etkileyebiliyor.

Bu süreç bana Android geliştirmenin yalnızca uygulama kodundan ibaret olmadığını tekrar gösterdi.

Google’ın yeni Android geliştirici doğrulama sistemi de önümüzdeki dönemde uygulama dağıtımının daha önemli parçalarından biri olacak.

Bu konuda hazırladığım ayrıntılı yazıya Android Geliştirici Doğrulaması Nedir? 2027’de Neler Değişecek? bağlantısından ulaşabilirsiniz.

MVVM Yapısını Neden Kullandım?

Dolap Hafızası büyüdükçe UI içerisinde bütün iş mantığını tutmanın sürdürülebilir olmayacağı açıktı.

Bu nedenle projede MVVM yaklaşımını tercih ettim.

Basitleştirilmiş yapı:

Compose UI
    ↓
ViewModel
    ↓
Repository
    ↓
Room / DataStore / Services

Bu ayrım sayesinde:

• UI daha sade kalıyor,
• iş mantığı ViewModel tarafında yönetiliyor,
• veri erişimi repository üzerinden gerçekleştiriliyor,
• Compose ekranları state üzerinden güncelleniyor.

Örneğin UI tarafında doğrudan Room sorgusu yapmak yerine ViewModel tarafından sunulan StateFlow gözlemleniyor.

Jetpack Compose Gerçek Projede Nasıl Bir Deneyim Sundu?

Dolap Hafızası’nın kullanıcı arayüzünü Jetpack Compose ile hazırladım.

Compose’un bana göre en önemli avantajlarından biri UI’ın state ile doğal şekilde çalışması.

Örneğin:

val uiState by viewModel.uiState.collectAsState()

ile ViewModel tarafından sağlanan durumu gözlemleyip ekranın buna göre yeniden oluşturulması oldukça temiz bir yapı oluşturuyor.

XML tabanlı klasik Android geliştirmeden farklı olarak UI bileşenleri Kotlin içerisinde tanımlandığı için ekran ve iş mantığı arasındaki bağlantıları takip etmek de daha kolay hale geliyor.

Ancak Compose kullanmak bütün UI problemlerini otomatik olarak çözmüyor.

Gerçek projede yine:

• state yönetimi,
• navigation,
• recomposition,
• performans,
• ekran boyutları,
• tema yönetimi

konularına dikkat etmek gerekiyor.

DataStore Nerede Devreye Giriyor?

Room daha karmaşık ve ilişkisel kullanıcı verilerini saklarken küçük ayarlar için aynı yapıyı kullanmak her zaman gerekli değil.

Bu nedenle uygulama ayarlarında DataStore kullanıyorum.

Örneğin:

• tema tercihi,
• bazı kullanıcı ayarları,
• uygulama davranış tercihleri

gibi küçük veriler için DataStore daha uygun bir çözüm.

Böylece Room ile uygulamanın ana verileri, DataStore ile ayarlar birbirinden ayrılmış oluyor.

ML Kit Gibi Özellikler Sonradan Eklenince Mimari Neden Önemli?

İlk sürümde olmayan bir özellik daha sonra projeye eklendiğinde mimarinin ne kadar önemli olduğu ortaya çıkıyor.

Örneğin Dolap Hafızası’nda görüntü üzerinden nesne tanıma gibi akıllı özellikler eklendiğinde mevcut UI ve veri yapısını tamamen değiştirmek istemezsiniz.

Katmanlı yapı yeni servislerin sisteme daha kontrollü eklenmesini kolaylaştırıyor.

Bu nedenle proje küçükken:

“Buna gerek yok, zaten birkaç ekran.”

denilen mimari kararlar, uygulama büyüdüğünde ciddi zaman kazandırabiliyor.

Bir Android Uygulamasında Teknik Olmayan İşler de Çok Fazla

Mobil uygulama geliştirmeden önce zamanın çoğunun kod yazmaya ayrılacağını düşünebilirsiniz.

Üretim aşamasında ise yapılacak işler hızla artıyor.

Örneğin:

• uygulama açıklaması hazırlamak,
• Google Play ekran görüntüleri oluşturmak,
• feature graphic hazırlamak,
• tablet ekran görüntülerini düzenlemek,
• gizlilik politikası hazırlamak,
• veri güvenliği formunu doldurmak,
• test kullanıcılarını yönetmek,
• yorumlara cevap vermek,
• uygulama sürüm notlarını hazırlamak,
• mağaza dönüşümünü takip etmek.

Yani gerçek ürün geliştirme, kodun çok ötesinde bir süreç.

Google Play’e Uygulama Çıkarırken Bugün Farklı Yapacağım Şeyler

Aynı projeye bugün sıfırdan başlayacak olsaydım bazı konulara daha erken odaklanırdım.

1. Gerçek Cihaz Testine Daha Erken Başlardım

Emülatör testleri devam ederdi ancak ilk kullanılabilir sürüm oluştuğu anda farklı fiziksel cihazlarda test etmeye başlardım.

2. Play Console’u Projenin Son Aşamasına Bırakmazdım

Test kanalları, cihaz uyumluluğu ve mağaza gereksinimlerini geliştirme sırasında düzenli kontrol ederdim.

3. Analytics ve Ürün Metriklerini Daha Erken Planlardım

Bir özelliğin teknik olarak çalışması onun kullanıcı tarafından kullanıldığı anlamına gelmiyor.

Hangi özelliklerin gerçekten değer ürettiğini anlamak için ürün metriklerini erken planlamak önemli.

4. Mağaza Optimizasyonunu Koddan Ayrı Görmezdim

Google Play ekran görüntüsü, açıklama ve feature graphic kullanıcının uygulamayla ilk karşılaştığı alan.

Uygulama ne kadar iyi olursa olsun mağaza sayfası bunu anlatamıyorsa kullanıcı yüklemeyebilir.

5. Yayını Final Değil İlk Gerçek Test Olarak Görürdüm

Kapalı test ve internal test önemli fakat gerçek kullanıcı davranışı ancak production sonrasında tam anlamıyla görülebiliyor.

Dolap Hafızası’nın Teknik Yapısı

Projenin temel teknik yapısını özetlemek gerekirse:

Alan	Kullandığım Teknoloji
Programlama dili	Kotlin
Kullanıcı arayüzü	Jetpack Compose
Mimari	MVVM
Yerel veritabanı	Room
Reactive data	Flow / StateFlow
Ayar saklama	DataStore
Arka plan görevleri	WorkManager
Push bildirim	Firebase Cloud Messaging
Görsel yükleme	Coil
Nesne tanıma	ML Kit
Minimum Android	API 23
Target SDK	API 36

Bu Projeden Çıkardığım 5 Ana Ders

Bütün süreci beş maddede özetlemem gerekirse:

1. Emülatör başlangıçtır, gerçek cihaz testin kendisidir.

Emülatör geliştirmeyi hızlandırır ancak cihaz uyumluluğu ve gerçek Android davranışlarının tamamını temsil etmez.

2. Play Console da geliştirme ortamının bir parçasıdır.

Uygulama kodu kadar dağıtım, test, uyumluluk ve politika süreçlerini de takip etmek gerekir.

3. Local-first mimari kullanıcı deneyimini ciddi şekilde iyileştirir.

Özellikle uygulamanın temel işlevi internet bağlantısına ihtiyaç duymuyorsa Room gibi yerel veri kaynakları büyük avantaj sağlar.

4. Arka plan görevlerini mutlaka gerçek cihazda test etmek gerekir.

Android’in pil ve arka plan optimizasyonları masa başında yazılan teorik koddan daha karmaşık davranabilir.

5. Google Play’e çıkmak bitiş çizgisi değildir.

Asıl ürün geliştirme süreci kullanıcıların uygulamayı kullanmaya başlamasıyla devam eder.

Uygulamayı İncelemek İsteyenler İçin

Bu yazıda anlattığım yapının gerçek uygulamadaki sonucunu görmek isteyenler Dolap Hafızası’nı Google Play üzerinden inceleyebilir.

👉 Dolap Hafızası – Google Play

Uygulamanın özellikleri ve geliştirme süreci hakkında daha fazla bilgi için:

👉 Dolap Hafızası proje sayfası

Sonuç

Google Play uygulama geliştirme deneyimi bana bir mobil uygulamanın başarılı şekilde derlenmesinin yalnızca ilk aşama olduğunu gösterdi.

Kotlin, Jetpack Compose, MVVM, Room ve WorkManager gibi teknolojiler uygulamanın teknik temelini oluşturuyor. Ancak gerçek bir ürün ortaya çıkarmak için bunların yanında cihaz uyumluluğu, Play Console, kullanıcı geri bildirimleri, mağaza optimizasyonu ve yayın sonrası bakım süreçlerini de yönetmek gerekiyor.

Özellikle Dolap Hafızası gibi gerçek kullanıcıya ulaşan bir proje üzerinde çalışmak, eğitim projelerinden çok farklı sorunlarla karşılaşmamı sağladı.

Bazı sorunların çözümü birkaç satır Kotlin kodu olurken bazıları Play Console ayarlarında, bazıları Android’in arka plan davranışlarında, bazıları ise doğrudan kullanıcı deneyiminde ortaya çıktı.

Bugün geriye baktığımda en önemli çıkarımım şu:

Bir uygulamayı kodlamak ile bir ürünü üretime çıkarmak aynı şey değil.

Gerçek öğrenme çoğu zaman uygulama production’a çıktıktan sonra başlıyor.

İlerleyen yazılarda Dolap Hafızası’nın Jetpack Compose + MVVM + Room mimarisini, WorkManager ile hatırlatıcı sistemini ve Google Play tarafında karşılaştığım gerçek problemlerin teknik çözümlerini ayrı ayrı daha detaylı ele alacağım.

Sık Sorulan Sorular

Google Play’e Android uygulaması çıkarmak için hangi teknolojileri kullandım?

Dolap Hafızası uygulamasında Kotlin, Jetpack Compose, MVVM, Room, Flow/StateFlow, WorkManager, DataStore, Firebase Cloud Messaging, Coil ve ML Kit kullandım.

Jetpack Compose gerçek projelerde kullanılabilir mi?

Evet. Jetpack Compose modern Android uygulamalarında production ortamında kullanılabilecek olgun bir UI toolkit’i. State tabanlı yapısı özellikle ViewModel ve Flow ile birlikte oldukça doğal bir geliştirme modeli sağlıyor.

Room neden kullanılır?

Room, yapılandırılmış verilerin Android cihaz üzerinde saklanmasını kolaylaştıran Jetpack veritabanı kütüphanesidir. SQLite üzerinde abstraction layer sunar ve SQL sorgularını compile-time sırasında kontrol edebilir.

Offline-first uygulama nedir?

Offline-first uygulama, temel fonksiyonlarının tamamını veya kritik bölümünü aktif internet bağlantısı olmadan gerçekleştirebilen uygulamadır. Dolap Hafızası’nın temel eşya ve oda verileri cihaz üzerinde saklandığı için ana özellikler internet bağlantısına ihtiyaç duymaz.

WorkManager ne için kullanılır?

WorkManager, Android’de uygulama kapalı olsa bile tamamlanması gereken ertelenebilir ve kalıcı arka plan işlerini zamanlamak için kullanılan Jetpack bileşenlerinden biridir.

2026’da Google Play için target SDK kaç olmalı?

31 Ağustos 2026’dan itibaren Google Play’e gönderilen yeni standart Android uygulamaları ve uygulama güncellemelerinin Android 16, yani API düzeyi 36 veya daha yüksek bir API düzeyini hedeflemesi gerekiyor.

Emülatör testi yeterli mi?

Hayır. Emülatör geliştirme aşamasında çok kullanışlı olsa da farklı üretici cihazları, pil optimizasyonları, Google Play uyumluluğu ve gerçek kullanıcı davranışı gibi durumlar fiziksel cihazlarda ayrıca test edilmeli.

Google Play’e uygulama yükledikten sonra geliştirme biter mi?

Hayır. Yayın sonrasında kullanıcı geri bildirimleri, crash ve ANR raporları, cihaz uyumluluğu, yeni Android sürümleri, mağaza optimizasyonu ve uygulama güncellemeleri nedeniyle geliştirme süreci devam eder.

Resmi Kaynaklar

• Android Developers – Google Play Hedef API Düzeyi Gereksinimleri
• Android Developers – Offline-First Uygulama Mimarisi
• Android Developers – Room ile Yerel Veritabanı
• Android Developers – WorkManager
• Android Developers – Jetpack Compose