Bir ürünü Google Play’e çıkarırken gerçekten gerekenler

Web ürünü geliştirirken deploy ile release arasındaki mesafe küçük olabilir. Build geçer, production'a çıkarsınız, hata varsa birkaç dakika sonra yeni deploy atabilirsiniz. Mobil mağaza dünyasında aynı zihinsel model çalışmıyor.

Ordovia'yı Android'e ve Google Play'e taşırken en net öğrendiğim şey buydu: mobil release'in zor kısmı APK veya AAB üretmek değil. Uygulamanın kimliği, sürüm numarası, mağaza beyanları, test kanalı, billing, deep link, asset'ler ve gerçek cihaz davranışı birbirine bağlı tek bir yayın sistemi oluşturuyor.

Android build almak bir mühendislik görevi. Google Play'e güvenilir biçimde yayın yapmak ise operasyon sistemi.

1. Önce uygulamanın kimliği sabitlenmeli

Mobilde package identifier basit bir config satırı gibi görünüyor. Değil. Mağaza, deep link, billing, signing ve platform entegrasyonları bu kimliğin etrafında büyüyor. Ordovia için uygulama kimliğini sabitledikten sonra onu rastgele değiştirmek artık bir refactor değil, release problemi olurdu.

1const mobileIdentity = {2  appName: "Ordovia",3  appId: "com.ordovia.app",4  sourceOfTruth: "GitHub",5};

İlk günden şu üç şeyi tek kaynakta tutmak önemli: uygulama adı, package/bundle kimliği ve canonical domain. Bunlar farklı panellerde farklı yazıldığında hata ayıklamak gereksiz yere zorlaşıyor.

2. Version name ile version code aynı şey değil

Kullanıcının gördüğü sürüm numarası ile mağazanın build'i ayırt etmek için kullandığı monoton artan build kodu farklı sorumluluklar taşıyor. Bu ayrım release otomasyonu kurulmadan önce netleştirilmeli.

1type AndroidRelease = {2  versionName: string; // kullanıcıya görünen sürüm3  versionCode: number; // her yeni mağaza build'inde artar4};

İki build arka arkaya üretildiğinde “neden mağazada yeni sürüm görünmedi?” sorusunun cevabı bazen UI kodunda değil, release kimliğinde olur. Bu yüzden version bump işini manuel hafızaya bırakmamak gerekiyor.

3. Build başarılı olması uygulamanın çalıştığını kanıtlamıyor

CI'da build geçebilir. Android projesi compile olabilir. Mağaza paketi kabul edebilir. Bunların hiçbiri auth'un, klavyenin, safe area'nın, deep link'in, offline davranışın veya ödeme akışının gerçek telefonda doğru çalıştığını garanti etmiyor.

1type ReleaseVerification =2  | "web_build_passed"3  | "android_build_passed"4  | "installed_on_device"5  | "critical_flows_verified"6  | "store_track_verified";

Ben artık agent veya CI raporunda “build passed” gördüğümde bunu completion değil, verification zincirinin bir aşaması olarak okuyorum.

4. Test kanalları formalite değil

Play Console'daki test ve yayın kanallarını yalnızca mağazanın istediği bürokratik basamaklar olarak görmek hata. Bunlar production riskini katmanlandırmak için kullanılmalı. Önce küçük bir dağıtım yüzeyi, sonra daha geniş test, en sonunda production.

Özellikle auth, subscription, push, deep link veya cloud sync kullanan bir uygulamada release öncesi gerçek mağaza build'ini test etmek önem taşıyor. Local debug build ile mağazadan kurulan signed build aynı çevresel koşullara sahip olmayabilir.

1const rollout = [2  "local device",3  "store test track",4  "production",5] as const;

5. Mağaza açıklaması pazarlama metninden fazlası

Store listing hazırlarken ilk refleks ürünü mümkün olduğunca büyük göstermek oluyor. Fakat iyi mağaza metni kullanıcının birkaç saniye içinde üç şeyi anlamasını sağlamalı: ürün nedir, kim içindir ve açınca ne yapabilecektir.

Ordovia için en kritik konulardan biri ürünü “her şeyi yapan AI productivity app” gibi anlatmamak oldu. Asıl kimlik daha net: görev, not ve alışkanlıkları günlük komuta merkezinde birleştiren kişisel sistem. AI bunun içinde bir katman, ürünün tamamı değil.

Store listing'de vaat büyütmek yerine ürün kimliğini daraltmak çoğu zaman daha güçlüdür.

6. Ekran görüntüleri sahte UI olmamalı

Mağaza görselleri yalnızca reklam alanı değil, beklenti sözleşmesi. Kullanıcı görselde gördüğü uygulamayı kurduğunda bulabilmeli. Bu nedenle gerçek ürün ekranlarını kullanmayı ve üzerine gerektiği kadar açıklayıcı tipografi eklemeyi tercih ediyorum.

• Gerçek uygulama ekranı kullan.
• Bir görselde tek ana fayda anlat.
• Metni ekranın kendisini örtecek kadar büyütme.
• Mobil gerçekliğe uymayan sahte masaüstü mockup'ları üretme.
• Mağaza görseli ile uygulama içi dil arasında tutarlılık kur.

7. Veri beyanları son gün yapılacak işler değil

Auth, analytics, subscription, crash reporting, takvim veya başka entegrasyonlar kullandıkça mağazadaki veri ve gizlilik beyanlarının kapsamı büyüyor. Bunları release'in sonunda “form doldurma” olarak ele almak, kod ile beyan arasında çelişki yaratabiliyor.

Daha sağlıklı yaklaşım, uygulamaya yeni bir SDK veya veri akışı eklenirken bunun privacy yüzeyini de aynı anda değerlendirmek.

1interface IntegrationReview {2  sdk: string;3  dataCollected: string[];4  purpose: string[];5  storeDisclosureChecked: boolean;6}

8. Billing ayrı bir release sistemi

Subscription eklediğiniz anda yalnızca bir paywall yapmış olmuyorsunuz. Ürün kimlikleri, entitlement, restore, satın alma başarısızlığı, mağaza hesabı ve farklı platformlar arasında erişim gibi yeni bir state machine ekliyorsunuz.

Ordovia'da ücretli erişimi web ve mobil yüzeylerde tutarlı hale getirmek için entitlement'ı ürün isimlerinden daha üst seviyede düşünmek gerekti. Kullanıcının hangi mağazadan satın aldığı değil, hangi erişim hakkına sahip olduğu ürün mantığının merkezinde olmalı.

1type Access = {2  entitlement: "free" | "plus" | "pro" | "lifetime";3  source: "play" | "web" | "app_store" | "manual";4};

9. Deep link küçük config değil

Web uygulamasını mobile paketlediğinizde URL dünyası ile native app dünyası birbirine bağlanıyor. Auth callback, paywall dönüşü, paylaşılmış içerik veya portal linkleri native uygulamayı açacaksa domain association ve platform config'leri release öncesi gerçek ortamda test edilmeli.

Deep link dosyasının endpoint'te 200 dönmesi bile tek başına yeterli değil; içerik doğru mu, package kimliği doğru mu, production domain doğru mu, cihaz gerçekten linki app'e yönlendiriyor mu? Acceptance burada davranış seviyesinde olmalı.

10. Web'de tolere ettiğiniz UI hatası mobilde engelleyici olabilir

Desktop browser'da küçük görünen safe-area, viewport veya keyboard hataları telefonda temel akışı kullanılmaz hale getirebilir. Modalın klavyenin altında kalması bunun basit bir örneği. Kullanıcı görev ekleyemiyorsa uygulamanın geri kalanının ne kadar iyi olduğu önemli değil.

Bu yüzden mobil QA'yı “responsive CSS kontrolü” olarak değil, platform davranışı testi olarak görüyorum.

11. Release otomasyonu her şeyi otomatikleştirmek değildir

Bir süre sonra doğal istek şu oluyor: commit atayım, build çıksın, mağazaya gitsin. Teknik olarak mümkün. Ama bağımsız ürünlerde release maliyetinin bir kısmı yanlış build'i hızla production'a göndermektir.

Ben kritik store release adımlarında hâlâ bilinçli manuel kapıları seviyorum. Build otomatik hazırlanabilir; ama production release'i net bir insan kararı olarak tutmak bazı projelerde daha güvenli.

1const pipeline = {2  test: "automatic",3  build: "automatic-or-manual",4  productionRelease: "explicit-human-trigger",5};

12. Release checklist koddan önce başlamalı

• Package identity ve signing net mi?
• Version name ve version code doğru mu?
• Production env değişkenleri doğru mu?
• Auth ve deep link gerçek cihazda çalışıyor mu?
• Store listing güncel ürünle eşleşiyor mu?
• Privacy / data beyanları kullanılan SDK'larla uyumlu mu?
• Billing ürünleri ve entitlement doğrulandı mı?
• Crash veya kritik console error var mı?
• Mağaza test build'i gerçek cihazda kuruldu mu?
• Rollback veya hotfix planı biliniyor mu?

En büyük zihinsel değişiklik

Google Play'e ilk kez ürün çıkarırken mağazayı geliştirme sürecinin sonunda duran bir dağıtım butonu gibi düşünmek kolay. Ben artık öyle düşünmüyorum.

Store release, ürün mimarisinin son adımı değil; ürün operasyonunun ayrı bir katmanı.

Uygulama kimliği, billing, auth, deep link, veri beyanı ve test stratejisi kod yazılırken etkileniyor. Bunları son hafta düşünürseniz release yavaşlıyor; daha önemlisi, neyin nereden bozulduğunu anlamak zorlaşıyor.

Sonuç

Bir Android uygulamasını mağazaya koymak için elbette çalışan bir build gerekiyor. Ama güvenilir bir ürün yayınlamak için daha fazlası gerekiyor: kimlik disiplini, release numaralandırması, mağaza metni, gerçek ekran görüntüleri, privacy uyumu, billing modeli, deep link, test kanalları ve cihaz acceptance'ı.

1const shipped =2  codeWorks &&3  storeAccepts &&4  userCanInstall &&5  criticalFlowsWorkOnRealDevice;

Benim için “yayına çıktı” artık Play Console'da yeşil bir durum görmek değil. Kullanıcının mağazadan ürünü bulup kurabildiği ve temel işi gerçekten tamamlayabildiği nokta.